La falacia de planificación aparece con especial frecuencia en la estimación de tareas en el desarrollo de software. Sin embargo, los métodos de estimación ágiles, como la planificación del póquer , etc., no parecen estar diseñados para evitar este problema.
Entonces, ¿qué haces para evitar la falacia de planificación al estimar tareas o tickets en proyectos de TI? ¿Existen metodologías de gestión de productos o mejores prácticas diseñadas para evitar esta falacia común?
Planning Poker está diseñado para usar (o al menos puede usarse para que involucre) una forma de Pronóstico de Clase de Referencia.
Al estimar con el póquer de planificación, puede elegir una especie de boleto de "línea de base" que represente aproximadamente 1 punto de trabajo y luego estimar todos los demás boletos como "aproximadamente el doble de difícil" para 2 puntos de historia, o "probablemente 10 veces más difícil". " para 13 puntos de historia, o "mucho más fácil" para 1/2 punto de historia.
Al estimar a partir de un ticket de referencia y solo planificar en base a la comparación con ese, todas las estimaciones se vuelven relativas. Esto debería eliminar una cantidad bastante grande de sesgo; no estás pensando en el tiempo sino en el tamaño comparativo , que es algo en lo que los humanos son mucho mejores.
Luego, para decidir qué tan lejos puedes llegar, miras el historial del equipo en cuanto a "puntos de historia por sprint" y lo llenas hasta algo comparable. Si el equipo mejora, siguen estimando de la misma manera, pero los "puntos de historia por sprint" aumentan, por lo que la cantidad de trabajo que realizan también crece, sin tener que volver a calibrar.
Este método funciona siempre y cuando siga recordando a las personas que los puntos de la historia no son medidas de tiempo, sino de complejidad a un punto de referencia, y que no pueden realizar la conversión entre los dos en ningún momento. Deja de funcionar en el momento en que decide que un punto de la historia es una hora, un día o cualquier otra medida de tiempo, ya que inmediatamente volverá a caer en todas las trampas de estimación que usted (y el artículo) mencionaron.
No se puede "evitar" el sesgo. Siempre está ahí. Solo puede minimizarlo estimando una tarea utilizando múltiples métodos diferentes y enfocándose en estimaciones probabilísticas versus estimaciones deterministas. E, incluso entonces, solo sabrá qué tan bien resolvió los sesgos cuando pueda comparar sus valores reales con sus valores planificados y tenga una cantidad razonablemente grande de observaciones de comparación. Esto supone que tiene un método altamente confiable para rastrear y controlar sus valores reales, y esa es una gran suposición que probablemente no sea muy cierta.
Como ocurre con todos los sesgos humanos, cuanto más crees que lo tienes bajo control, más sesgado eres.
Según la entrada de Wikipedia de "falacia de planificación" :
La falacia de planificación... es un fenómeno en el que las predicciones sobre cuánto tiempo se necesitará para completar una tarea futura muestran un sesgo de optimismo y subestiman el tiempo necesario.
Diferentes marcos ágiles usan diferentes métricas, pero las métricas de velocidad y flujo acumulativo comúnmente utilizadas son las barandillas típicas para mitigar el sesgo de planificación. Ciertamente hay otras métricas, pero hablaré brevemente sobre la velocidad porque creo que aborda más de cerca la preocupación.
La velocidad es una métrica que analiza las tasas históricas de entrega y utiliza un promedio móvil u otras funciones estadísticas para suavizar las perturbaciones. La métrica de velocidad es probabilística y, aunque a menudo funciona mejor con una clase de referencia de referencia para anclar la métrica, en el uso pragmático es menos sensible a eso de lo que uno podría pensar. El verdadero determinante de cuán confiable es la velocidad como métrica predictiva es la consistencia del proceso de estimación.
La clave del éxito ampliamente aceptado de la velocidad en la planificación ágil es un proceso de estimación consistente . En realidad, importa muy poco si el proceso de estimación es optimista, pesimista o ignora por completo la clase de referencia, siempre que el proceso de estimación se aplique de manera similar en todas las iteraciones. Durante una ventana de tiempo suficiente, un proceso de estimación consistente tenderá hacia la tasa de entrega sostenible.
Si bien un proceso de estimación consistente es esencial para un pronóstico confiable, eso no significa que el proceso de estimación de su proyecto no pueda cambiar o mejorar. La advertencia notable aquí es que las mejoras iterativas o incrementales en el proceso de estimación crearán pequeñas perturbaciones en las tasas de entrega, pero generalmente serán lo suficientemente pequeñas como para ser absorbidas por la función de suavizado.
Como advertencia relacionada, también es posible realizar cambios radicales (¡con suerte, mejoras!) en el proceso de estimación. Cuando eso sucede, debe descartar los datos históricos o aplicar un "factor de elusión" para tener en cuenta los cambios en la metodología. Esto puede dar lugar a una menor fiabilidad de la previsión de la métrica a corto plazo, pero a menudo puede valer la pena si conduce a una mayor fiabilidad sostenida en el cumplimiento de las previsiones.
No es la parte de estimar juntos de la planificación del póquer lo que ayuda mucho (aunque eso puede reducir los sesgos individuales). Es la parte de seguimiento de la velocidad la que le permite aplicar datos históricos para ayudar con las estimaciones futuras.
Por ejemplo, si en el sprint anterior intentamos completar 50 puntos de trabajo, pero solo terminamos 40, entonces nuestra tasa probablemente esté más cerca de 40 que de 50.
Aquí hay otro ejemplo del uso de datos históricos para mejorar la precisión de las estimaciones (más complejo en términos de recopilación de datos; también usa distribuciones de probabilidad).
Otros métodos que he visto funcionar:
No se olvide de la idea de la convergencia de estimaciones (las primeras estimaciones están muy lejos y mejorarán cada vez más a medida que avance el trabajo).
erik
Asmaier