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.