Una investigación comisionada por una consultora encuentra que los proyectos de software desarrollados mediante las llamadas metodologías ágiles tienen tasas de fallos un 268% mayores que los que no utilizan esas metodologías.
Si bien esta investigación en concreto podría ser etiquetada por algunos como una forma de «investigación de parte», de intentar vender las metodologías de desarrollo de esa consultora concreta, la realidad es que las metodologías ágiles han sido durante mucho tiempo objeto de fuertes críticas y que los estudios que intentaban probar su idoneidad han aportado muy pocas evidencias concluyentes sobre sus supuestas ventajas.
El llamado «Manifiesto por el desarrollo ágil de software«, traducido a más de setenta idiomas, es una declaración de principios generalista basada en doce principios sumamente grandilocuentes, que parte de una definición y un término eminentemente cargado de positivismo: ¿quién iba a oponerse a la idea de «ser ágil»? Sin embargo, y a pesar de los muchos apoyos que recibió el manifiesto en su momento y de la gran cantidad de compañías que lo abrazaron como verdad única, la realidad es que en muchos casos, la supuesta metodología tiende a convertirse en equipos que hablan demasiado del software sin llegar a escribir software, que se dedican a mantener simbólicas reuniones de pie que son en realidad una forma sutil de liderazgo unidireccional encubierto, y a gastar notitas adhesivas como si no hubiera un mañana o como si todos fuéramos accionistas de 3M.
Según uno de los firmantes originales del manifiesto ágil, Dave Thomas,
«La palabra ‘ágil’ se ha subvertido hasta el punto de que en la práctica ya no tiene sentido, y lo que pasa por una comunidad ágil parece ser en gran medida un ámbito para que consultores y proveedores se dediquen a pregonar sus productos y servicios»
El énfasis en cuestiones como los individuos y sus interacciones sobre los procesos y las herramientas parece que incide de manera clara en tasas de fallos superiores, como lo hace también el quitar relevancia a los procesos de documentación. Una cosa es odiar los procesos de documentación (algo además común a la práctica totalidad de los desarrolladores), y otra pretender que no documentar para priorizar que el software funcione sea, como tal, una práctica que genere resultados estables o sostenibles.
Por otro lado, está por ver que las metodologías ágiles, como su nombre debería implicar, generen en realidad proyectos con un desarrollo más rápido: el 65% de los proyectos que emplean este tipo de metodologías sufren retrasos en su fecha prevista de entrega. Según la investigación, lo que realmente importa en un proyecto de software opara poder entregarlo a tiempo y dentro del presupuesto establecido es un buen proceso de determinación de la ingeniería de requisitos, y que los desarrolladores tengan la seguridad psicológica para poder discutir libremente y resolver problemas cuando vayan surgiendo, además de tomar medidas que eviten el agotamiento de los desarrolladores. Fiar ese tipo de factores a unas metodologías ágiles enormemente vagas y genéricas es, simplemente, encomendarse a un supuesto atributo, la agilidad, con connotaciones positivas, pero que posiblemente ofrezca muy pocas herramientas concretas.
¿Es el agilismo en realidad una especie de moda o culto, que ha terminado teniendo implicaciones negativas en el desarrollo de software? ¿O simplemente un conjunto de buenos deseos que sufren cuando se encuentran con la realidad? Tras años predicando de forma grandilocuente la agilidad por todas partes y como supuesta solución a todos los males, ¿es momento de plantear otras formas de hacer las cosas?
This article is also available in English on my Medium page, «Why agile is not always a good thing«
¡Tengo la solución!
Para nada las reuniones son simbólicas ni encubren liderazgo unidireccional. Esas reuniones que se hacen de pie no deben tener una duración máxima de quince minutos y se realizan únicamente para que todo el equipo de desarrollo ponga en común como va el trabajo, los problemas surgidos y que se puede hacer para finalizar ese trabajo en el tiempo estimado. Y un buen Scrum Máster no decide nada en esas reuniones, es simplemente un facilitador.
Se hacen de pie por varias razones pero la principal es para agilizar la reunión y que todo el mundo esté centrado en dicha reunión.
Seguid vendiendo humo con el agile. Creo que cada vez engañáis a menos gente. Además ahora mismo hay una tormenta de arena que cubre todo lo demás llamada IA.
Yo siempre he pensado que el gran problema con estas metodologías (vamos a asumir que lo son) es que la gente las asume como dogmas. El solo hecho de que se hable de “evangelizadores” lo dice todo
Hay cosas básicas que tienes que llevar a cabo aunque hay otras que deben adaptarse a tu entorno de trabajo. Pero no me digas que en el desarrollo en cascada no hay cosas que se asumen como dogmas. Y si hablamos, por ejemplo de cmmi5 no te cuento.
«Scrum» pon tus barbas a remojar !!
El problema principal son las personas, no las metodologías.
“tiende a convertirse en equipos que hablan demasiado del software sin llegar a escribir software, que se dedican a mantener simbólicas reuniones de pie que son en realidad una forma sutil de liderazgo unidireccional encubierto, y a gastar notitas adhesivas como si no hubiera un mañana o como si todos fuéramos accionistas de 3M.”.
Qué gracia me ha hecho pensar que esto no solo se da en entornos tecnológicos, ni tampoco en empresas privadas como tal.
Siempre me disgustó Agile y amo los Cascade (con flexibilidad). Son estreseñantes y cuando tienes varios proyectos, muérete
Cuando leí esto ayer me dio un alivio abrumador. Espero que se distribuya
Para mí la principal ventaja del desarrollo ágil frente a cascada es la entrega continua que te evita esperar meses hasta que puedes comprobar si todo el mundo ha entendido lo que había que implementar.
Si estás en disposición de probarlo, pruébalo de verdad y ya me contarás
Hola JM,
Mi experiencia Agile es la siguiente
«Hay que entregar algo en 2 semanas. Ya sabéis, a trabajar».
– No están claros los requisitos, cada uno lo entiende como le parece. Incluso el cliente.
– El cliente no sabe cual es el producto final porque vamos «improvisando» sobre la marcha
– No se delinean claramente las pruebas para la entrega
– Las pruebas hay que repetirlas en cada ciclo de entregas, porque posteriores entregas modifican las anteriores
– Cuando terminas el producto tienes «spaguetti code» de cada programador que ha hecho lo que le ha parecido por su lado
– El equipo de soporte no tiene ni quien les entrene porque nadie tuvo ni tiene la visión completa
Benji. Tú frase «Hay que entregar algo en dos semanas … » ya lo define todo. Si trabajáis así olvidaros de la agilidad. Volver al cascada y que el cliente os firme un documento de requisitos. Así puede que reflexione y cambie su actitud en la definición de lo que quiere (si es ese el problema claro). Es muy complicado adivinar el problema que tenéis con este comentario aunque parece claro que uno de vuestros principales problemas es la definición del qué.
Tienes toda la razón Rodrigo, así es
Lo importante de las metodologías ágiles son la aplicación de sus principios, no las metodologías en sí. Y sobre todo ser consciente de para qué son los principios ágiles, que es para generar valor para las empresas.
Sería el equivalente de tener una buena Constitución y luego tener un poder judicial que no es independiente, con miembros que han terminado su mandato y que no se renuevan y están en una especie de «limbo» pero que se niegan a dimitir. Eso en lugar de generar valor para los ciudadanos.
Partes de una premisa, para mí equivocada. Ni en el manifiesto se menciona que el software desarrollado en metodologías ágiles vaya a tener menos errores que las metodologías en cascada ni en los doce principios se dice algo sobre los errores. Lo más que se dice es entregar software funcional, pero que sea funcional en los supuestos más prioritarios para el «product owner» no quiere decir que no pueda tener errores.
Hablando de errores, en un proyecto en cascada los periodos de entrega son generalmente muy largos y un error metido en este tipo de proyectos se acabará detectando muy tarde, y por supuesto el esfuerzo de corrección será muy elevado ya que la complejidad del software entregado será elevada. Se puede demostrar estadísticamente que ese esfuerzo se multiplica por varios factores a encontrarlo en fases tempranas. En cambio, en un proyecto ágil, con entregas funcionales cada dos semanas esos errores, probabilísticamente serán detectados antes y podrán ser resueltos con menos esfuerzo.
Abundando en el tema de las entregas tempranas versus entregas a largo plazo con todo o gran parte construido, en las entregas tempranas es mucho más sencillo hacer cambios en las necesidades del proyecto con lo cual también deberíamos entregar un producto más acorde al mercado cambiante que tenemos en los últimos tiempos ahorrando tiempo y dinero.
Por otra parte los principios ágiles si hablan de un tema muy importante, la excelencia técnica. Ese principio es fundamental para conseguir nuestro objetivo final: un buen producto que satisfaga al cliente. Pero en muchos lugares cuando empiezas a hablar de pruebas unitarias automáticas, excelencia en el código, integración continua … Ya te dicen que «eso quizás para otro día». Y así, evidentemente, no vamos a ninguna parte.
Y ya si entramos en el «código legacy» apaga y vámonos. Mucha gente quiere empezar a aplicar metodologías ágiles con «código legacy» que no hay desarrollador que pueda cambiar por su complejidad. En este código es imposible aplicar técnicas adecuadas para obtener un buen código que pueda seguir desarrollándose sin sufrir algún tipo de ataque al corazón.
Resumiendo una metodología ágil es superior si se sabe aplicar con cabeza y utilizando las herramientas adecuadas sino seguiremos anclados en el pasado entregando software que hay que tirar a la basura porque ya está desfasado o es imposible modificar.
Aporte acertado. Suscribo 100%. Para mi la grandilocuencia precisamente reside en el enfoque Waterfall (o cascada) donde se presume que alguien(es) tienen el conocimiento suficiente como para anticiparse a una realidad de producción a meses vista y con capacidad suficiente para eliminar desviaciones con costes inasumibles a futuro. Y nada más lejos de la realidad que la cultura del Project Management tradicional, con sus eternas actualizaciones de diagramas de GANTT.
Hecho en falta en el artículo de Enrique un análisis más equilibrado aportando también los «weakpoints» de la supuesta alternativa.
Idem
Estuve pensando en explicar lo mismo que tú pero consideré que siendo la mayoría de los comentaristas de fuera del ámbito del desarrollo sería perder el tiempo.
Quizás se tenga 268% más de fallos porque se atreven a experimentar más. Al igual que un fondo de venture capital con 1000 inversiones que tendrá 900 inversiones fallidas, no lo puedes comparar con un microfondo con 12 inversiones que tiene 10 inversiones fallidas. Como siempre, los porcentajes pueden engañar.
Profesor, si esta usted interesado en un verdadero estudio sobre el impacto del desarrollo ágil (con minúscula) de software, le recomiendo este: «Accelerate: Building and Scaling High Performing Technology Organizations» de Nicole Forsgren, Jez Humble y Gene Kim.
El estudio en el que basa su crítica es en realidad un publi-reportaje, hecho para vender otra metodología más. Solo el espacio muestral ya debería hacer saltar todas las alarmas (600 entrevistas hechas en 4 días).
Me temo que este «estudio» solo ha hecho que alimentar su sesgo de confirmación. Por favor, aunque sea solo por tener todas las perspectivas, échele usted un ojo a Accelerate, creo sinceramente que no se arrepentirá.
Esta la desconozco, pero he padecido demasiadas tecnologías de desarrollo que no aportaron nada positivo, pero si mucho trabajo adicional.
Sn embargo no pierdo la esperanza que un día se descubra el Santo Grial.
Te lo explico en pocas palabras y sin extenderme. Si quieres desarrollar un producto en la tecnología en cascada primero defines todos los requisitos, después haces un diseño completo y codificas tu producto haciendo las pruebas pertinentes. Cuando terminas entregas el producto entero, aunque pudiste hacer alguna entrega intermedia. Entre que creas los requisitos y entregas el producto final pasa una eternidad medido en tiempos de desarrollo software y si el cliente quiere cambiar algo rehacer el producto implica un gran coste en tiempo y esfuerzo.
En agilidad vas definiendo el producto mientras se desarrolla siempre empezando por las características que más aportan a tu negocio y cada dos semanas el equipo de desarrollo se compromete a entregarte eso que has pedido para desarrollar durante dos semanas y como cliente ves su funcionamiento y puedes mejorar esas características cada poco tiempo con menor esfuerzo de desarrollo. Evidentemente esto tiene ciertas implicaciones que es necesario poder controlar como por ejemplo que lo que estás pidiendo se pueda hacer en esas dos semanas. Espero haberte lo aclarado un poco.
Uno de los problemas de la agilidad es cuando no se implementa un sistema de pruebas automáticas con suficiente cobertura (a veces se presiona para eliminar pruebas porque no es algo que vea el cliente) y los cambios que pide el cliente provocan (naturalmente) que aumente el número de errores.
Probablemente este es el fenómeno al que se refiere @EDans del que es culpable a partes iguales el cliente y la empresa/departamento de desarrollo.
En los doce principios se habla de desarrollo sostenible, simplicidad, sostenibilidad o excelencia técnica. Eso es imposible de llevar a cabo sin unas buenas prueba unitarias automáticas. Y si no se hacen que no vengan diciendo «soy ágil». Eso es sólo postureo.
No debe tener mucho que ver, porque a uno la silicona desarrolladora le da una cierta alergia, pero estos días he disfrutado un montón viendo como funciona una tecnológica siliconada a tope y, como no, sus lecheros financieros habituales. Se trata de la historia de una tal E. Holmes… para dar clases en las facultades de lo que sea… hasta vale en la de E.F, por lo siliconadas que estaban sus «clases» de fitness con dieta vegana incluida… en fin, que me encanta lo de ponerle alitas al red bull y decir que es la esencia de la agilidad tecnológica… con Fórmula I incluida!!!
Para mí el otro gran problema de la teoría de las metodologías ágiles es pretender que cualquier miembro de un equipo ágil pueda hacerse cargo de cualquier tarea. Todos sabemos que en el desarrollo de software hay tareas complejas que deben ser llevadas a cabo por especialistas. Por mucho que estén de moda los llamados perfiles full stack, para hacer tuning de una base de datos o escribir consultas sql complejas necesitas un especialista
No es del todo cierto tu comentario. Siempre habrá, por poner ejemplos, especialistas en desarrollo del interfaz, especialistas en la lógica del negocio o especialistas en base de datos pero con dos consideraciones: es bueno que en todos los ámbitos exista un mínimo de dos personas que puedan afrontar el trabajo sin problemas y el resto pueden tener alguna idea por si en algún momento es necesario echar una mano con algo sencillo. Y como ves digo «es bueno» o «pueden tener» pero no es algo obligatorio que todo el mundo sea experto en todo. Aún así hay momentos dentro del proyecto en el que se pueda trabajar por pares (algunas veces muy efectivo) o que el menos experto afronte un trabajo de lo que no es experto, siempre con revisión del código ( otro tema muy denostado pero muy útil incluyendo la revisión del código de un experto).
Efectivamente es positivo que haya más de una persona capacitada para hacerse cargo de cualquier tipo de tarea, por razones obvias: vacaciones, carga de trabajo etc. Mi punto es que algunos pretenden que los roles sean intercambiables sin más, y para mí eso no es realista.
Saludos
Como en este post he puesto varios comentarios sobre agilidad quería aclarar un poco lo que hago: No soy consultor ni evangelizador ni nada que se le parezca. Llevo mucho tiempo trabajando para una empresa que desarrolla su propio software y a lo largo de estos diez últimos años he trabajado codo con codo tanto con equipos ágiles como con equipos que desarrollan en cascada. Tengo unos 30 años de experiencia y anteriormente había trabajado en proyectos grandes en cascada, los cuales terminaban siempre como el rosario de la aurora. En algunos casos llegó el cliente a ver el producto después de dos años de intenso desarrollo y a falta de un mes para su instalación eso no era lo que quería. Y se firmaban al principio unos documentos de requisitos que ni el Quijote. Eso me pasó en todas las empresas en las que estuve. O elijo mal donde trabajar o algo falla en esa metodología. Y ese tema fundamental es uno de los que se intenta mejorar con la agilidad pero para conseguirlo no vale sólo con decirlo, hay que hacerlo. Y creo que en muchas empresas se dice pero no se hace.
Comparto todos los comentarios que has hecho.
Coincido.
La agilidad sí que es buena. De hecho, me atrevo a decir que en el mundo del desarrollo de software, la falta de agilidad es una receta segura para el desastre.
Pero me refiero, como alguien ha dicho en otro comentario, a la «agilidad con minúsculas». A ser conscientes de que durante la vida del proyecto, los requisitos van a cambiar, las tecnologías van a cambiar, las regulaciones van a cambiar, el propio equipo de desarrollo puede cambiar… y hay que estar preparado, empezando por plantear un desarrollo iterativo y realimentación continua por parte del cliente. El enfoque «esto es lo que queremos, nos vemos dentro de N meses cuando lo terminéis» es un suicidio.
Pero, ser ágil no significa empezar a trabajar sin tener unos (¡mínimos!) requisitos claros, sin estándares de calidad, sin pruebas unitarias, y en suma sin una (¡mínima!) metodología. Ni tampoco seguir dogmáticamente una metodología concreta, puesto que ninguna es el santo grial.
En resúmen, que como viene siendo habitual, los extremos no son buenos. Y en el mundo del software, tan contraproducente es aferrarse al más estricto y trasnochado «cascadismo» como adoptar religiosamente la metodología Ágil (con mayúsculas esta vez) que esté de moda descuidando prácticas básicas que siempre deben estar presentes. Pero ¿»la agilidad no es tan buena»? No, nada de eso, al revés: la falta de agilidad es malísima. Pero hay que saber aplicarla bien.
Llego un poco tarde profesor Dans, pero habiendo trabajado con la agilidad en diversos estadios, y habiendo sido parte de la comunidad puedo aportar unas cosas:
– Desde hace unos años ya no se usa la palabra «metodologias» para referirnos a los «marcos y practicas agiles», debido a que per se una metodologia es una receta a seguir, siendo que la agilidad procura la experimentación
– La escena agil tuvo su mejor momento cuando los desarrolladores estuvieron moviendola, porque habia un interes genuino en buscar «mejores formas» de desarrollo, pero desde hace casi 10 años la escena ha sido copada por coaches y managers reciclados, que buscaron subirse al coche sin haber tocado una linea de codigo.
– Este fenomeno vino de la mano con la introduccion mainstream de la agilidad, y claro… las empresas querian recetas para «implementar la agilidad» «escalar», pero sin cambiar sus practicas inherentes.
– Y por otro lado, la escena perdio rumbo cuando la agilidad se volvio un cajon de sastre, donde entro PNL, hakas.
Lo curioso es que pese a todo ese desvario, queda claro que la realidad inherente del software hacer que un proceso o metodologia cascada, como en la construccion, no tiene sentido, cada ladrillo es diferente y la serializacion es imposible, pero ahi estan quienes quieren que 9 mujeres den a luz a un bebe en un mes.
No todo vale para todo, pero creo que estas metodologías son imprescindibles en proyectos con un alto nivel de incertidumbre. Cuando no hay algo claramente definido, sino que vamos desarrollando software a la vez que se va construyendo el negocio, Agile tiene todo el sentido (situación cada vez más común en un mundo que cambia a velocidades cada vez más altas).
En todo caso, en Agile, como en casi todo (por no ser maximalista), creo que aplica la máxima: ‘aléjate de los puristas‘, de los de Agile y de cualquier otro. Hazte un favor y quita a un purista de tu vida.
Un servidor con más de 15 años en el sector, decir que Agile es micro management. Es empezar el día con estrés sin aún haber empezado a currar. Y es que las reuniones, las distracciones, el exceso de control, la burocracia de las stories en el JIRA, le agotan a una persona, que lo único que quiere hacer es programar y estar tranquilo y concentrado. La programación requiere de mucho esfuerzo mental, Agile es un aparato para interrumpir y generar ruido.