En una reunión el otro día, se afirmó que ágil era solo un 60% tan eficiente en tiempo de desarrollo en comparación con la cascada. No estoy buscando validar o refutar este reclamo. Me interesa descubrir si ha habido algún estudio que compare las 2 metodologías.
¿Hay algún estudio por ahí que compare los dos?
project-management
agile
SoylentGray
fuente
fuente
I refuse to prove that Agile is more efficient,dice Dios,for proof denies faith, and without faith Agile is nothing.Respuestas:
El libro "Making Software: What Really Works and Why We Believe It" tiene algunos capítulos sobre métodos ágiles que incluyen XP, Scrum, Desarrollo dinámico de software y Lean, con un buen respaldo científico. Es de alta calidad, como es de esperar de O'Reilly. Uno de los editores fue el excelente Greg Wilson , un autor, editor y presentador confiable de informática.
El libro en sí resume múltiples estudios de investigación, incluidos muchos sobre ágil. Una sección resume la investigación que incluye "¿Son dos cabezas mejores que una? Sobre la efectividad de la programación de parejas" por Dybå, T .; Arisholm, E .; Sjøberg, DIK; Hannay, JE; Shull, F .; y " Estudios empíricos del desarrollo de software ágil: una revisión sistemática " por Tore Dybå y Torgeir Dingsøyr.
El sentido general es que la mayoría de las prácticas ágiles son beneficiosas, pero que los efectos de la programación de pares y TDD y otros inquilinos ágiles no son tan fuertes como uno podría esperar. Incluso hay una nota al pie inquietante de que TDD de hecho puede ser algo adictivo *.
El libro es una excelente manera de acceder a una gran cantidad de investigaciones que se han realizado, todo en un solo conjunto coherente. Hay algunos blogs y otros sitios en la web que revisan el libro.
* ¡Esta no es necesariamente mi opinión!
fuente
Por mucho que no me guste el título, creo que Balancing Agility and Discipline: A Guide for the Perplexed podría contener información relevante para usted. Este libro de dos expertos en procesos de ingeniería de software y gestión de proyectos de software: Barry Boehm y Richard Turner. Este libro analiza varios aspectos de las metodologías ágiles y basadas en planes, las compara y contrasta, y también analiza su integración para lograr una situación de "lo mejor de ambos mundos".
El Apéndice E de Equilibrio de Agilidad y Disciplina contiene una gran cantidad de información empírica sobre los costos y beneficios de varios métodos ágiles y basados en planes. Sin embargo, no parece haber datos sobre la efectividad del tiempo. Pero al revisar los datos, parece (como sospechaba) que esto no es una opción o una opción: algunos proyectos experimentaron un esfuerzo reducido, cronogramas más rápidos y defectos más bajos al aplicar métodos ágiles. Sin embargo, otros proyectos que utilizan. La sección discute una serie de proyectos diferentes en diferentes industrias, el tipo de proceso que usaron y lo que experimentaron en el transcurso del proyecto.
Hay muchos estudios de casos citados en el Apéndice E que arrojan estos datos. Hay demasiados para mí como para comenzar a nombrar al azar, ya que muchos se centran en una industria en particular o incluso dentro de una organización en particular. Si va a ver los casos, le sugiero que encuentre aquellos que sean de naturaleza similar a su equipo, proyecto, organización e industria para sacar conclusiones razonablemente válidas.
En Rapid Development: Taming Wild Software Schedules , Steve McConnell identifica una serie de factores a considerar al elegir una metodología de ciclo de vida: nivel de comprensión de los requisitos, nivel de comprensión de la arquitectura, confiabilidad deseada, gestión de riesgos, restricciones de programación, cantidad de proceso gastos generales, "correcciones del curso" a mitad del proyecto, capacidad de proporcionar visibilidad al cliente, capacidad de proporcionar visibilidad a la administración y sofisticación del equipo de desarrollo y la administración. También hay otros, como la cultura organizacional, por lo que probablemente no haya una lista exhaustiva en ningún lado.
Incluso dado el mismo proyecto, también existe el factor de equipo. Si toma un equipo que ha entregado software de manera consistente utilizando la metodología espiral impulsada por el plan y lo incluye en Scrum, experimentarán una disminución en la productividad, un aumento en la agitación y tendrán que superar un nuevo modelo de proceso antes de que puedan venir. a punto de tener éxito. Aunque otra metodología podría ser más adecuada, siempre existe la necesidad comercial de entregar el software. Es por eso que los esfuerzos de mejora de procesos son con frecuencia esfuerzos a largo plazo y no de la noche a la mañana: los cambios importantes son impactantes para un equipo e (incluso si la metodología puede ser más adecuada en el papel) puede causar una disminución en la productividad.
Hay mucho más que la simple eficacia o efectividad del proceso, y no puede simplemente mirar una instantánea del mismo equipo que trabaja en un entorno basado en planes y en un entorno ágil. Al tomar una decisión, debe tener en cuenta el contexto industrial y organizativo, los atributos del proyecto, el equipo, el cliente, etc.
Según lo que leí, tendré que estar en desacuerdo con la evaluación de sus compañeros de trabajo. Estoy seguro de que puede encontrar algún estudio de caso en algún lugar donde un proyecto ágil sea un 60% menos eficiente con respecto a alguna métrica de rendimiento que un proyecto similar impulsado por un plan. Sin embargo, también hay estudios que demuestran que el rendimiento ágil produce un 80% menos de esfuerzo, un 50% menos de tiempo y una alta satisfacción del cliente con el producto.
fuente
No tengo un estudio pero me gustaría comunicar mi experiencia.
La efectividad de cualquiera de las metodologías mencionadas depende en gran medida de los analistas.
Cuando tienes un excelente propietario de producto, SCRUM, por ejemplo, es ciertamente más rápido que un enfoque en cascada con una mala especificación.
Ágil con un mal propietario del producto es ciertamente más lento que una cascada con una gran especificación.
Sin embargo, la mayoría de las veces, no conocemos los requisitos exactos con suficiente antelación y las metodologías ágiles tienen ciclos de retroalimentación más rápidos. Esto significa que, en terrenos inciertos, ágil es un mejor método para entregar un producto de alta calidad a costos razonables. Existen numerosas otras ventajas, por ejemplo, los proyectos ágiles son más fáciles de cancelar cuando no funcionan y, por lo tanto, pueden reducir las pérdidas al mínimo.
Se podría decir que las metodologías ágiles reducen el riesgo, mientras que la cascada, incluso si a veces puede ser más rápida, puede ser una apuesta monetaria.
fuente
Cierto.
Pero, esa es una medida poco convincente.
Los métodos ágiles suelen ofrecer un valor real antes.
Waterfall simplemente se adhiere a un cronograma independientemente de lo que se entrega y, a menudo, no ofrece nada de valor hasta que haya pasado un gran lapso de tiempo.
Promover.
Puede medir el "tiempo de desarrollo" separado del "tiempo de desarrollo y prueba".
Ágil generalmente incluye pruebas. Entonces parece más lento.
El desarrollo de la cascada puede separarse limpiamente de las pruebas. Entonces el código está "listo para probar" antes. Pero no está "hecho" hasta mucho más tarde.
Asi que. Tienen toda la razón. Por lo que midieron.
fuente