¿Qué tan mítico es el Hombre-Monon? Modelo y datos de Boehm.
Etiqueta de texto: Gestión del cronograma A lo largo de los años, se han realizado una gran cantidad de estudios cuantitativos sobre la productividad del software y los factores que la afectan, especialmente en términos del equilibrio entre la dotación de personal del proyecto y el cronograma. Uno de los estudios más completos es el estudio de Barry Boehm de 63 proyectos, en su mayoría aeroespaciales y 25 proyectos de TRW. Su Economía de la ingeniería de software incluye no sólo muchos resultados, sino también una serie de modelos de costes progresivamente generalizados. Aunque los coeficientes en el modelo de costo de software comercial general y el modelo de costo de software de aviación desarrollado de acuerdo con los estándares gubernamentales son ciertamente diferentes, su modelo utiliza una gran cantidad de datos para respaldarlo. Creo que este libro será un clásico de ahora en adelante. Sus resultados son totalmente consistentes con la conclusión de "El mito del mes-hombre", es decir, el equilibrio entre mano de obra (personas) y tiempo (meses) está lejos de ser una relación lineal, y utilizando el mes-hombre como medida de productividad es en realidad un mito. En particular, encontró que el tiempo de programación óptimo en términos de costo para la primera versión es T = 2.5(MM)1/3. Es decir, el tiempo óptimo en meses es la raíz cúbica del esfuerzo estimado (persona-mes), que se deriva de la estimación del tamaño y otros factores del modelo. Se deriva la curva de dotación de personal óptima. Cuando el cronograma planificado es más largo que el cronograma óptimo, la curva de costos aumentará lentamente. Cuanto más tiempo tengas, más tiempo llevará. Cuando el cronograma planificado es más corto que el cronograma óptimo, la curva de costos aumenta bruscamente. No importa cuántas personas estén dispuestas, ¡casi ningún proyecto puede tener éxito en menos de 3/4 del tiempo óptimo! Cuando los altos directivos piden a los directores de proyectos garantías de progreso imposibles, esta conclusión puede servir plenamente como base teórica para los directores de proyectos. ¿Qué tan precisa es la regla de Brooks? Se han realizado muchos estudios cuidadosos para evaluar la validez de la regla de Brooks. En pocas palabras, agregar personas a un proyecto de software que está retrasado sólo hará que se retrase aún más. La mejor investigación está publicada en el valioso libro de Abdel-Hamid y Madnick de 1991, Software Project Dynamics: An Integrated Approach. El libro propone un modelo cuantitativo de las características dinámicas del proyecto. El capítulo sobre los criterios de Brooks proporciona un análisis más detallado, señalando lo que sucedería bajo diversos supuestos sobre cuándo y cuántas personas agregar. Para realizar el estudio, los autores ampliaron su propio modelo de proyecto de tamaño mediano, asumiendo que los nuevos miembros tienen una curva de aprendizaje y requieren esfuerzos adicionales de comunicación y capacitación. Llegaron a la conclusión de que agregar personas a un proyecto que estaba retrasado siempre aumentaría el costo del proyecto, pero no necesariamente haría que el proyecto se retrasara aún más. En particular, dado que los nuevos miembros siempre traen efectos negativos inmediatos que pueden tardar semanas en recuperarse, es más seguro agregar personas adicionales al principio del proyecto que más adelante. Para un estudio similar, Stutzke desarrolló un modelo más simple y obtuvo resultados similares17. Realizó un proceso detallado y un análisis de costos para incorporar nuevos miembros, incluido el alejamiento de sus mentores de sus asignaciones de proyectos originales. Probó su modelo en un proyecto real y, después de un desvío a mitad del proyecto, logró duplicar la plantilla y cumplir con el cronograma. En lugar de agregar más programadores, también experimentó con otros métodos, especialmente trabajando horas extras. Entre sus muchas sugerencias prácticas, las más valiosas son cómo agregar nuevos miembros, realizar capacitaciones, brindar apoyo con herramientas, etc. De particular interés es su sugerencia de que los desarrolladores agregados más adelante en el proyecto de desarrollo deben servir como miembros del equipo y estar dispuestos a invertir y trabajar duro en el proceso, en lugar de intentar cambiar o mejorar el proceso en sí. ¡Estos estudios meticulosos hacen que Brooks sea extremadamente simplificado! criterios aún más prácticos. Como equilibrio, me quedaré con esta simple afirmación como la mejor aproximación a la verdad y como regla general que advierte a los gerentes que eviten soluciones ciegas e instintivas a proyectos que están retrasados.