Programación basada en evidencia de Fogbugz

No usé FogBugz, aunque adopté el método en un equipo con el que trabajé, ya que tenía todos los datos necesarios en mi herramienta de seguimiento de tareas.

Primero, la historia

Estábamos dividiendo nuestras historias y funciones posteriores en las llamadas tareas de desarrollo. Para cada una de esas tareas, hacíamos estimaciones en horas reales, lo que significa que intentábamos tener en cuenta todo el tiempo dedicado a las distracciones, el cambio de contexto, etc. Luego, cuando finalizaba una tarea, anotamos el tiempo real dedicado. en eso. Ahora, cada vez que necesitábamos estimar algo en detalle, podíamos hacer WBS para hacer nuestras estimaciones y, basándonos en datos históricos, hacer un análisis de Monte Carlo (en una hoja de Excel) y obtener un resultado.

En segundo lugar, los problemas

Tuve dos problemas con tal enfoque. Primero, para obtener resultados razonables, debe mantener la misma granularidad de las tareas tanto cuando recopila datos como cuando realiza estimaciones. Si bien lo primero es fácil, ya que lo hicimos de todos modos, dividir un proyecto de varios meses y varias personas en tareas que toman 8 horas en promedio es un gran esfuerzo. Además, requiere un gran esfuerzo diseñar todo por adelantado.

Otro problema es contabilizar todo el tiempo dedicado a la tarea durante las etapas posteriores, por ejemplo, corrección de errores, a la tarea original. Es complicado ya que piensas no solo en las pruebas regulares, sino también en los problemas que obtienes de la producción, etc. Eventualmente, terminamos teniendo otra tarea, una por función, dedicada exclusivamente a las pruebas. Su estimación original era 0 y el tiempo real era lo que se gastaba en tareas no planificadas, como la corrección de errores. Teóricamente se adaptaba al modelo, aunque en realidad no decía nada sobre la calidad de las habilidades de estimación de alguien.

En tercer lugar, las conclusiones

Si bien el método produjo resultados bastante buenos, cada vez que lo usé, no fue aplicable con demasiada frecuencia. Como usamos un enfoque ágil para el desarrollo, no queríamos diseñar con muchos detalles por adelantado, especialmente porque trabajábamos en un entorno donde las prioridades cambiaban bastante rápido.

Por otro lado, podría obtener estimaciones de grano grueso bastante decentes utilizando datos más genéricos ( lea más sobre el enfoque ). También me di cuenta de que la mayoría de las veces no necesitaba estimaciones tan exactas como las que podía obtener utilizando la programación basada en evidencia, por lo que en su mayoría abandonamos el método.