Un gerente de proyecto de nuestra empresa proporcionó recientemente al equipo métricas para dos proyectos anteriores que son muy diferentes entre sí. Con base en estas métricas, al gerente del proyecto le gustaría crear una línea de base para proyectos futuros; sin embargo, me resulta difícil comprender cómo sería posible porque los proyectos futuros podrían tener diversos grados de dificultad, disponibilidad de recursos y otros problemas.
proyecto duro
Sprint 3.1 to 3.6 data - 6 sprints - 12 weeks
Total Design Hours 41
Total Development Hours 250
Number of PBIs 46
Number of bugs 45
Estimate hours fixing bugs 90
Estimated hours new development 160
Defect injection rate
(number of hours fixing bugs / number of hours developing functions) 0.56
Average team development hours completed per sprint 42
Proyecto fácil
Sprint 2.3 to 3.5 data - 7 sprints - 14 weeks
Total Design hours 12
Total Development Hours 124
Number of PBIs 20
Number of bugs 13
Estimate hours fixing bugs 26
Estimated hours new development 98
Defect injection rate
(number of hours fixing bugs / number of hours developing functions) 0.27
Average team development hours completed per sprint 18
La principal preocupación aquí parece ser que Average team development hours compeleted per sprintestá alrededor del 40-50 % de la capacidad real y que Defect injection ratees demasiado alta para el proyecto más difícil. Pero estos son los dos campos seleccionados para la línea de base para futuros proyectos. Pero, ¿qué significa esto exactamente? ¿Cómo puede seleccionar arbitrariamente las métricas de uno de estos proyectos y aplicarlas a un proyecto futuro? Después de analizar esta pregunta, ¿cuál es la mejor manera de desarrollar una línea de base del proyecto? parece que podríamos estar combinando diferentes ideas.
Depende significativamente de cuál sea el propósito de la línea base . Un enfoque, basado en el concepto del Teorema de Bayes (el sol salió ayer, y anteayer, y anteayer..., por lo que es muy probable que salga mañana), implicaría agregar todos los proyectos anteriores para obtener una línea de base que mejora continuamente.
En cuyo caso, dado que actualmente solo tiene dos puntos de datos, su línea de base original no será muy útil. Después de un tercer proyecto, actualiza la línea de base y se vuelve un poco más útil. Después del cuarto, quinto, etc., la línea de base continúa mejorando, eventualmente se convierte en un predictor decente para el éxito del proyecto 'promedio'. Si bien este es un método algo ingenuo (ya que ignora la variación en el tamaño y tipo del proyecto), es al menos de baja complejidad.
Sin embargo, si su gerente de proyecto solo quiere arrojarle estos dos puntos de datos y recibir a cambio un predictor exacto y preciso de los cronogramas del proyecto para todos los productos futuros... Es probable que se sienta muy decepcionado.
Primero trate de averiguar para qué se usará esta línea de base . Eso debería ayudarlo a descubrir cómo crearlo o descubrir que no debe crearse en primer lugar (en cuyo caso, su tarea se convierte en convencer a dicho PM de su hallazgo).
Todd A. Jacobs