# Software Feature Delivery ## El Manifiesto — una doctrina para entregar software en la era de la IA *Versión 1.0 — por Elías Peralta* *Comprobada en laboratorio: 30 features entregadas en 5 productos en producción.* --- ## 1. El momento La inteligencia artificial cambió cómo se escribe código. Pero no cambió — todavía — cómo se *entrega* software. Y ahí está la oportunidad que casi nadie está mirando. La industria se llenó de cursos, herramientas y "expertos" de *agentic engineering*. Todos enseñan lo mismo: cómo un individuo puede promptear mejor. Pero entregar software no es un acto individual de prompteo. Es un **sistema de entrega**. Y ese sistema, en la era de la IA, todavía no existía de forma disciplinada. Esta doctrina propone uno. Ya no como teoría: como método probado. --- ## 2. El problema central: AI-TDA Llamo a este fenómeno **AI-TDA**: *Trastorno por Déficit de Atención inducido por Inteligencia Artificial.* La IA hizo que generar código sea casi gratis. Pero la abundancia trajo dispersión: - Equipos que saltan de prompt en prompt sin terminar nada. - Mucho output, poca entrega real. - Más personas involucradas, cada una con su propia ventana de IA, multiplicando el ruido. - La ilusión de velocidad — movimiento constante — confundida con progreso. La industria reaccionó añadiendo *más gente* al problema, cuando la gente con AI-TDA solo genera *más* AI-TDA. El cuello de botella ya no es escribir código. **El cuello de botella es el foco.** > La IA no nos hizo más rápidos. Nos hizo más dispersos. La disciplina es la nueva ventaja competitiva. --- ## 3. La tesis **El software se debe entregar como un servicio de delivery: rápido, claro, verificado y a la puerta del negocio — una feature funcional a la vez.** No sprints de tres semanas que se vuelven seis. No equipos inflados que diluyen la responsabilidad. No incertidumbre sobre qué se entrega y cuándo. Un incremento funcional. Cada semana. Probado. Trazable. Predecible. Como un servicio de delivery entrega a la puerta. --- ## 4. Los principios **Principio 1 — Foco sobre escala.** Un ingeniero senior enfocado, dirigiendo la IA con disciplina, entrega más que diez personas prompteando en paralelo. La respuesta a la IA no es más gente; es más foco. **Principio 2 — Claridad antes de código.** La IA solo es tan buena como el objetivo que recibe. Sin una definición clara de la feature — alcance, criterios de aceptación, criterio de "listo" — la IA produce ruido elegante. La claridad del requerimiento es el verdadero acelerador. **Principio 3 — El incremento es sagrado.** No entregamos código. Entregamos features funcionales, probadas, desplegables. Si no pasó por QA y no funciona, no se entregó. Punto. **Principio 4 — Ritmo predecible.** El negocio no necesita milagros; necesita previsibilidad. Una feature por semana, sostenida, vale más que un gran lanzamiento incierto cada trimestre. **Principio 5 — La IA ejecuta, el humano decide.** La IA hace el trabajo pesado: genera, refactoriza, prueba, documenta. Pero cada decisión — qué se construye, cómo se diseña, cuándo está listo — es humana, y queda registrada. La dirección, el criterio de ingeniería y la responsabilidad final no se delegan. Quitar al piloto es dejar el auto andando solo: eso es AI-TDA. **Principio 6 — Trazabilidad total.** Todo trabajo que toca código vive en el sistema de gestión antes, durante y después. Cada feature es un ticket; cada ticket refleja en tiempo real dónde está el trabajo; cada decisión relevante queda en la base de conocimiento. Hoy usamos Jira y Confluence; la doctrina es agnóstica a la herramienta — lo innegociable es que exista un solo lugar de verdad, migrable cuando el cliente lo requiera. **Principio 7 — El contexto del cliente es ley.** Cada cliente tiene políticas, patrones de diseño, arquitectura, marca e identidad propias — y se documentan antes de generar una sola línea. La IA no impone su estilo: hereda el del cliente. Un manual de marca, un design system, una convención de commits o un patrón de navegación existente valen más que cualquier preferencia del modelo. **Principio 8 — Los errores se documentan una vez y no se repiten.** Cada error encontrado en construcción o QA se convierte en una regla escrita en la base de conocimiento del producto. La IA lee esas reglas en cada sesión. Así el sistema aprende como organización, no como individuo: el conocimiento sobrevive a las personas y a las sesiones. --- ## 5. El framework de entrega Tomamos lo que funciona de Scrum y lo destilamos a su esencia, sobre un flujo Kanban de entrega continua. Menos ceremonia, más entrega. **Los roles (mínimos, claros):** - **Product Owner (PO).** Define qué es la feature y cuándo está "lista". Dueño del *qué* y del *por qué*. - **Master de Entrega (Delivery Master).** El ingeniero senior que dirige la generación de código con IA. Dueño del *cómo*. Un solo punto de responsabilidad técnica. - **QA.** Verifica que el incremento funcione de verdad. Guardián de la calidad. **El ciclo (una semana):** 1. **Definición** — El PO define la feature de la semana como ticket con alcance y criterios de aceptación. El criterio de "listo" se escribe antes de empezar, no se negocia a mitad de camino. 2. **Construcción** — El Delivery Master dirige la IA tarea por tarea, nunca desde la épica completa: cada tarea tiene su alcance preciso, se implementa solo ese alcance y se verifica contra su descripción antes de pasar a la siguiente. El estado del ticket refleja la realidad en cada momento — se mueve a "en curso" con la primera línea de código, no después. 3. **Verificación** — QA prueba el incremento contra el criterio definido. Nada llega a "listo" sin pasar por control de calidad. 4. **Entrega** — La feature funcional se despliega. Visible para el negocio, trazable en el tablero, documentada en la base de conocimiento. **Las reglas operativas que hacen que el ciclo no se rompa:** - **Una rama por ticket, un ticket por feature.** El historial de código y el tablero cuentan la misma historia. - **Trabajo tarea por tarea.** Implementar desde el análisis general de una épica — saltándose las tareas hijas — produce requerimientos perdidos, métricas falsas y dependencias rotas. La granularidad es disciplina. - **Base de conocimiento viva por producto.** Stack, arquitectura, patrones de diseño, identidad de marca, comandos operativos y errores conocidos: todo documentado donde la IA lo lee al iniciar cada sesión. El contexto no vive en la cabeza de nadie. - **Convenciones sobre preferencias.** Mensajes de commit, nombres de rama, estilos de código: los define el proyecto, los respeta la IA, los audita el humano. Sin reuniones de tres horas. Sin alcance que se infla a mitad de camino. Sin "casi listo". Entrega o no entrega. --- ## 6. La prueba: el laboratorio Una doctrina sin evidencia es una opinión. Esta ya no lo es. **30 features entregadas en 5 productos en producción**, con dominios, stacks y clientes distintos — desde plataformas empresariales hasta productos nativos en IA. En todos los casos, el mismo método: un ticket por feature, la IA dirigida por un solo responsable técnico, verificación contra criterios escritos, y la base de conocimiento del producto como fuente de verdad. Lo que el laboratorio confirmó: - **El método es portable.** Funciona igual en un monolito legado que en un producto nuevo, porque lo que se estandariza es la *entrega*, no la tecnología. - **El contexto documentado multiplica a la IA.** Los productos con base de conocimiento madura entregan más rápido y con menos retrabajos: la IA no redescubre el proyecto en cada sesión. - **Los errores documentados no vuelven.** Las reglas escritas a partir de fallos reales eliminaron categorías enteras de retrabajo. - **La trazabilidad genera confianza.** Cuando el tablero refleja la realidad, el negocio deja de preguntar "¿cómo vamos?" — lo ve. --- ## 7. Por qué esto importa para el negocio El negocio no compra código. Compra *certidumbre*: saber qué tendrá, cuándo, y que funcionará. AI-TDA destruye esa certidumbre con velocidad falsa. Esta doctrina la reconstruye con ritmo real. - Más rápido de lo que el negocio espera. - Más claro de lo que el negocio teme. - Trazable de punta a punta: cada feature tiene historia, responsable y evidencia. - Respetuoso de lo que el cliente ya construyó: su marca, sus patrones, sus políticas. --- ## 8. La visión: la Academia Un método que funciona se puede enseñar. Con el laboratorio completado — 30 features, 5 productos — la doctrina tiene lo que ninguna teoría tiene: casos de estudio reales. El siguiente paso es la **Academia**: formar a la industria — ingenieros, POs, líderes — en cómo entregar software con foco en la era de la IA, en lugar de ahogarse en AI-TDA. El orden importó: **primero se entregó, ahora se enseña.** La autoridad de la doctrina se ganó con features entregadas, no con teoría. Cada proyecto entregado es un caso de estudio. Cada caso de estudio es un ladrillo de la Academia. --- ## 9. Hacia dónde va esto 1. ~~Entregar la primera feature a un cliente real.~~ **Hecho — y 29 más.** 2. ~~Validar el método en múltiples productos y dominios.~~ **Hecho — 5 productos en producción.** 3. Sistematizar las bases de conocimiento como plantilla replicable para nuevos clientes. 4. Abrir la Academia y escalar la doctrina con la evidencia en mano. La idea era buena. Lo que la volvió real no fue el manifiesto — fueron las features entregadas. --- *Software Feature Delivery — entregamos software con foco, en un mundo con AI-TDA.*