Despidiéndome de Agile
(lewiscampbell.tech)- Una revisión crítica de la metodología Agile que ha dominado la industria del software, señalando que en la práctica no fue más que un conjunto de principios ambiguos y un reempaque de problemas ya resueltos
- La oposición con Waterfall es en gran parte una falsa dicotomía, y conceptos clave como el desarrollo iterativo y la participación del cliente ya habían sido planteados en investigaciones de la década de 1970
- Agile siempre se definió únicamente como lo opuesto al modelo Waterfall, aunque las limitaciones de Waterfall ya eran ampliamente conocidas desde los años 70
- Con la reciente aparición de los modelos de lenguaje de gran escala (LLM), el desarrollo guiado por especificaciones (Spec-Driven Development) vuelve a cobrar importancia y está resurgiendo un enfoque centrado en la documentación
- El lema ágil de “software funcionando por encima de documentación exhaustiva” ahora está cambiando hacia la idea de que “la documentación exhaustiva crea software que funciona”
- Más allá de la ambigüedad que dejó Agile, ha llegado el momento de volver a principios claros y a un enfoque ingenieril
RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, descansa en paz. Apenas llegamos a conocerte.
Y lo digo literalmente: porque nadie tuvo claro nunca qué era exactamente.
El problema de identidad de Agile
- Agile fue una gran corriente que arrasó con toda la industria del software, pero en realidad se difundió como un concepto cuyo significado nunca estuvo claro
- Cada vez que surgían dudas, la respuesta recurrente era: “eso no es verdadero Agile”
- Si se lee realmente el Manifiesto Ágil (2001), casi no hay guías concretas, sino más bien aforismos vagos como “la colaboración con el cliente está por encima de la negociación contractual”
- Principios como “dar la bienvenida a cambios en los requisitos incluso en etapas tardías del desarrollo” son comercialmente poco realistas
- Bajo el argumento de “True Agile”, se ha evitado reconocer que los problemas de la práctica también están ligados al propio manifiesto
- Si la industria Agile no practica bien Agile y el manifiesto en sí mismo dice tan poco, entonces vale la pena preguntarse qué era realmente Agile
“El fantasma de Waterfall recorre el software”
- Agile siempre se definió por lo que no era: Waterfall. La lógica era que, si no hacías Agile, entonces hacías Waterfall, y Waterfall no funciona
- Pero que Waterfall no funcionaba ya se sabía desde 1970, y Winston W. Royce explicó con precisión por qué
- Como alternativa, Royce recomendó empezar por el diseño del programa, crear un prototipo de software para refinar los requisitos y mantener una participación formal, profunda y continua del cliente
- Todo eso fue presentado después como si fuera la gran innovación de Agile, cuando en realidad ya estaba escrito en 1970, al año siguiente del alunizaje
- Nota 1: ¿Cómo habrán logrado semejante hazaña los programadores de la Apollo Guidance Computer sin story points ni conocer el principio de que “la atención continua a la excelencia técnica mejora la agilidad”?
El artículo de Bell-Thayer de 1976 y la historia del desarrollo iterativo
- El artículo de Bell y Thayer de 1976 es el documento que usó por primera vez el término “Waterfall”, y lo hizo precisamente como ejemplo de algo que no debía hacerse
- La conclusión empírica de ese trabajo fue que los defectos en los requisitos solo se descubren durante el desarrollo de software cuando se intenta satisfacerlos mediante el diseño
- El desarrollo iterativo no era nada nuevo y venía refinándose durante décadas antes de Agile
- Incluso antes de que el manifiesto “liberara” a la industria, Waterfall ya no era el estado del arte, y casi nadie dudaba seriamente de la utilidad de los requisitos y las especificaciones
El auge del desarrollo guiado por especificaciones y el después de Agile
- Con la expansión de los LLM, se está reforzando la tendencia de que los programadores vuelvan a escribir especificaciones
- Como los LLM son vulnerables a entradas ambiguas, describir con claridad el problema se está convirtiendo en la forma de obtener código correcto
- Si Agile enfatizaba “software funcionando por encima de documentación exhaustiva”, el desarrollo guiado por especificaciones propone la tesis contraria: “la documentación exhaustiva crea software que funciona”
- Royce ya señalaba en 1970 que “documentación, especificación y diseño son el mismo concepto hasta antes de escribir código, y si la documentación es mala, el diseño también lo será”
- También subrayó que si no existe documentación, tampoco existe diseño
- Al volver sobre los estudios de 1970 y 1976, queda claro que el Manifiesto Ágil de 2001 no aportó una idea realmente nueva
- Agile simplemente reemplazó enfoques de ingeniería ya existentes con definiciones ambiguas y empaquetado comercial, sin producir un progreso sustancial
- Aquellos artículos de ingenieros transmitían un significado mucho más claro
- Ahora que el desarrollo de software sigue cambiando y evolucionando, ha llegado el momento de dejar Agile en la historia y pasar a una nueva perspectiva
- Hay que volver a los principios claros y al pensamiento ingenieril que dejaron aquellos ingenieros serios
21 comentarios
No sé por qué tratan las metodologías como si fueran escrituras sagradas. Creo que el autor original también era igual de dogmático, solo que iba en otra dirección.
Creo que la conclusión es un poco exagerada. La comercialización o la excesiva formalización pueden ser el problema, pero eso no significa que herramientas como los sprints o el backlog hayan dejado de ser útiles. También ayudaron a que se estableciera una cultura de reuniones más horizontal y centrada en objetivos. Es cierto que SDD se ha vuelto más importante, pero como esa especificación puede redactarse rápido y de forma colaborativa con IA, sigue siendo ágil. Lo único es que el sprint de 2 semanas se acortó a unas cuantas horas; la esencia de iterar y pulir repetidamente me parece que sigue siendo la misma.
Coincido.
Tan solo con romper la toma de decisiones vertical y la mejora iterativa en ciclos cortos, el mensaje que nos deja es enorme (por supuesto, lo mismo aplica a las técnicas/herramientas de gestión de proyectos).
La conclusión de que 'el agile en sí no aportó nuevas perspectivas y se caricaturiza a todos los que lo defienden como fanáticos ciegos del agile' me parece excesiva.
Estoy de acuerdo. Agile sigue siendo vigente. Parece el tipo de cosas que dicen al aire quienes nunca han estado en el trabajo real.
Es un texto bastante tonto. La clave es que la
spec.misma debe escribirse de forma ágil... Agile se trata de adaptarse rápidamente a los cambios en los requisitos del cliente.Es por personas que tienen este tipo de malentendidos y fantasías superficiales sobre Agile que tanto Agile como la cultura de desarrollo terminan yéndose por mal camino.
¿Qué significa exactamente escribir la
specde forma ágil?specpor encima.spectal como la va dictando el cliente.specrápidamente.specde forma ágil.El punto central de ese texto es que, para empezar, ni siquiera queda claro qué es ágil. Se la pasan diciendo que ágil tiene estas características y que hay que hacerlo de tal o cual manera, pero hasta ahora no he visto un texto que realmente muestre: este es un producto hecho con una metodología ágil. Incluso viendo el manifiesto, sigue siendo confuso. ¿Qué tal si muestran un ejemplo?
Es algo que aparece básicamente en la mayoría de los libros sobre métodos ágiles, como Extreme Programming de Kent Beck y Scrum de Jeff Sutherland, entre otros. También pueden fijarse en las historias de usuario. Por lo visto, la mayoría de la gente no sabe bien que la base del ágil son los sprints cortos y las demos para adaptarse rápidamente a los requerimientos del cliente.
Es el 3 y 4. Escribir las especificaciones con mucho detalle tiene una profundidad infinita. Lo que quiero decir es que hay un nivel adecuado para cada organización. Si uno mira la historia de cómo se construyeron los servicios exitosos, entiendo que en el 99% de los casos uno de los factores principales fue justamente no poner demasiada energía en escribir las especificaciones con total precisión. No quedar atrapado en eso. Si ves cómo se hicieron cosas como Summoners War, Dungeon & Fighter, Zigbang y Lineage, se entiende.
¿Y si el ciclo en cascada diera una vuelta completa en un solo día?
Últimamente veo este tipo de casos con más frecuencia.
Terriblemente, parece ser lo que veo con más frecuencia...
En Corea, el agilismo no es más ni menos que una herramienta para presionar los plazos de los desarrolladores.
Según algunos criterios, hoy en día todos son ágiles. No sé si antes hubo una época en la que se desplegara tan rápido y se recibiera retroalimentación como ahora.
Fuera de las implementaciones en ciclos cortos, no me queda claro qué le queda a Agile.
El backlog y los sprints ya existían antes bajo otras formas, y mucha de la comunicación con el cliente no encaja con la realidad. Al final, creo que más que Agile, las mejoras en DevOps han traído más avances al desarrollo.
¡Este artículo en sí no es ágil!
Como no es que nunca haya que leer código, desde esa perspectiva parece válida la idea de que el código está por encima de la documentación; y como la documentación, en tanto conjunto de instrucciones, debe ser leída por el LLM que realiza la implementación, desde ese punto de vista también estoy de acuerdo. Por eso, mi conclusión es que al final ambos son importantes al mismo tiempo.
Ahora mismo, el problema de los productos creados con LLM es la deuda que se va acumulando en la etapa de operación. Para un funcionamiento continuo, los desarrolladores tienen que involucrarse con el código, y para que eso sea posible, creo que por ahora el código todavía debe poder sustituir a la documentación.
Si expreso mi objeción con cautela, yo creo que el código no puede sustituir a la documentación. Los lenguajes de programación todavía no tienen la riqueza expresiva ni la capacidad de transmisión del lenguaje natural y, en la práctica, ¿cuándo va uno a leer todo ese código?
Tener código que pueda sustituir a la documentación es una esperanza y un deseo, pero es una Torre de Babel a la que no se puede llegar.
Más bien, parece mejor dedicarse a fondo a OOAD.
Por otro lado, también veo difícil que el lenguaje natural reemplace al código. Aunque el lenguaje natural es más rápido que el código, es demasiado abstracto. Para la computación, al final hay que completar los detalles, y parece difícil que el lenguaje natural pueda cumplir ese papel.
Al escribir software, el problema no es tanto la abstracción, sino la ambigüedad. El lenguaje natural es inherentemente ambiguo. Incluso puede tener múltiples interpretaciones. Por eso quizá los intentos de programar con lenguaje natural no funcionan bien. Dadas estas circunstancias, ni soñar con que el lenguaje natural reemplace al código.
Sí, comparto la opinión que mencionaste.
Definitivamente hay partes que no se pueden reemplazar con código.
En ese sentido, si lo explico de una manera un poco distinta, quería decir que un código con alta legibilidad hace que no sea necesario producir documentación.
La documentación que se va acumulando a medida que el software se prolonga también genera carga cognitiva para los desarrolladores. La clave está en reducir el trabajo de estar alternando entre el código y la documentación.
No creo que sea posible dejar únicamente el código.
Creo que puede variar según el contexto y la situación en la que uno se encuentre.
Gracias por tu comentario.
Comentarios en Hacker News
Con Agile se observa un fenómeno interesante
Si falla, se interpreta como que “no se hizo lo suficiente”.
Vi el mismo patrón con la nube, los microservicios y las políticas de austeridad: la causa del fracaso siempre es la falta de ejecución, y nunca que el enfoque en sí esté equivocado.
Si un equipo intenta Agile y no funciona, aparece la defensa de que “eso no era Agile de verdad”. Al final, Agile se convierte en un concepto incapaz de fracasar.
El Agile Manifesto solo habla de valores y principios. El problema es la cultura organizacional que intenta forzarlo a convertirse en un proceso.
Que ante el fracaso uno mire hacia adentro no es necesariamente malo. En vez de culpar al exterior, puede ser un sistema sano que fomente la autoevaluación.
La hoja de ruta prometida a clientes y la capacidad de responder con flexibilidad son difíciles de conciliar. En la práctica, son organizaciones centradas en la planificación imitando Agile.
Si algo falla, la conclusión termina siendo “habría que haber usado más agentes”. Suena como el chiste de que “nunca hay suficientes tokens”.
Empecé a temerle a la formalización de Agile.
He dirigido con éxito un equipo de 40 personas, pero el Agile real se resume en solo cuatro frases: personas, software funcionando, colaboración con el cliente y respuesta al cambio.
El problema es que la “Agile” con mayúscula terminó deformándose en un proceso rígido.
A medida que crece la cantidad de gente, alinear objetivos se vuelve más difícil y al final hacen falta control y procedimientos.
Incluso restringían quién podía crear tickets, algo muy lejos de cualquier flexibilidad.
Sin documentación suficiente, el mantenimiento se vuelve imposible y al final todo deriva en desarrollo YOLO.
El Agile de las grandes empresas donde trabajé era una mentira.
Un colega decía: “si adelantas el trabajo del próximo sprint, siempre terminas a tiempo”.
O sea, Agile funcionaba más como un sistema para producir métricas que como trabajo real.
Los gerentes se conformaban con ver subir los números, y el producto quedaba reducido a un subproducto de la estadística.
Vale la pena volver a leer el texto original del Agile Manifesto.
Ese es el único punto de consenso. Hay que recordar lo terrible que era el waterfall antes de Agile.
Fue el arma que puso fin a la era en la que se imponían fechas y entregables fijos.
Si el equipo trabaja con autonomía, sienten que su puesto queda amenazado.
Como dijo Kent Beck en “Extreme Programming”, Agile era un intento de evitar la tiranía de una omnipotencia imaginada.
El waterfall de antes intentaba predecirlo todo en la etapa de diseño e ignoraba el aprendizaje y la retroalimentación.
Pero con el tiempo, los rituales y formas de Agile terminaron tapando lo esencial.
A mí todavía me gusta el Agentic programming, pero al final lo importante sigue siendo el papel humano de conectar el contexto.
El artículo original era confuso.
Primero decía que Agile no había creado nada nuevo, y luego afirmaba que si los LLM escriben código entonces Agile ha muerto.
Pero el núcleo de Agile es reconocer especificaciones incompletas y mejorar de forma iterativa.
Ese principio sigue vigente.
Agile es solo una variante de eso; lo que hubo fueron muchas implementaciones malas.
Los buenos productos al final salen del ciclo especificación → aprendizaje → corrección.
Procedimientos como Backlog Grooming o Sprint Review terminan más bien frenando los cambios.
No creo que el desarrollo basado en specs vaya a durar mucho.
Sigue siendo más rápido crear software funcionando e iterar: al final, es el regreso de Agile.
La calidad de las specs mejoró y revisar se volvió más fácil que revisar código.
Ver GitHub.
En el manifiesto no aparecen términos como Daily Standup ni Agile Coach.
La esencia es “no microgestiones a los programadores”.
En otras palabras, dale entorno y confianza a personas motivadas.
Los fundadores, como Kent Beck y Martin Fowler, originalmente pretendían lineamientos flexibles.
Pero con el tiempo se volvió un negocio y aparecieron seguidores dogmáticos, lo que aumentó la confusión.
Que funcione o no depende, al final, de la capacidad y la actitud de las personas.
La duración de los sprints también debería ajustarse al contexto, y si no hay especificación, el equipo tendría que crearla.
Incluso en la era de la IA, mientras haya gente que use Agile con criterio, sigue siendo válido.
Me preguntaba qué significa exactamente “escribir una spec”.
Todos los proyectos Agile en los que he trabajado tenían documentos de diseño, y los tickets se derivaban de esos documentos.
El desarrollo basado en tickets sin documentación debe ser un infierno.
Cada quien los interpreta como quiere.
Un enfoque centrado en tickets estaría más cerca del Agile puro.
En el Agile falso, los documentos creados por el PO o el PM fingen ser la verdad.
La forma que mencionaste es precisamente la más cercana a lo que yo quería decir con “escribir una especificación”.