El problema con las estimaciones no son las estimaciones
“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto, determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman incertidumbres.” — Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)
Hola! Por favor permítame expresar mi opinión con respecto al tema de las estimaciones, y #NoEstimaciones. El problema con las estimaciones no son las estimaciones. Las estimaciones son sólo eso, aproximaciones sobre la magnitud de algo. No son valores determinísticos que buscan exactitud sobre el sujeto de la estimación. Bajo este contexto, no existen “estimaciones equivocadas”.
El problema con las estimaciones (Estimates) -sobre todo en el ámbito del desarrollo de software- es que se usan como fechas de finalización de los proyectos (deadlines), sobre las cuales se asocian costos y se asignan equipos para lograr cumplir un alcance que por naturaleza es variable, en un entorno complejo completamente alterable en función de los cientos de factores que provienen de la misma naturaleza del desarrollo de software y de la naturaleza de lo que queremos construir. Complejidad.
Sin embargo, el proceso de estimación (Estimating) desde mi punto de vista es útil. Y aquí hago una pequeña pausa para resaltar la diferencia entre Estimating (la dinámica de estimación) y Estimates (los valores resultantes de la dinámica de estimación). Quizás tengamos un problema en castellano, ya que ambas tienden a traducirse como lo mismo: “estimación” o “estimaciones”.
Desde mi punto de vista, el proceso de estimación es un ejercicio de entendimiento compartido durante el cual los participantes descubren y discuten aspectos que les permite comprender en mayor medida los desafíos de la construcción de lo que estén estimando. Por ejemplo -muy popular dentro del contexto Scrum-, cuando Usted observa a los equipos en una dinámica de Planning Poker, lo valioso es la discusión que se genera frente a la percepción de la complejidad de la cosa a construir y no por el número en sí mismo. Las estimaciones (estimates) pueden ser útiles o no, más el proceso de estimación es valioso.
“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. — Steve McConnell, Software Estimation: Demystifying the Black Art
Las estimaciones (Estimates) pueden ser expresadas en la unidad que el equipo acuerde: pueden ser horas, pueden ser puntos de historia o pueden ser bananas. Más adelante veremos cuántas bananas nos comimos en una unidad de tiempo. Son simplemente etiquetas de equipo que nos facilitan el proceso mental de comprender qué significa una banana.
El verdadero problema es enfrentar la necesidad de “predictibilidad”
Imagine que Usted llega a la cola en una oficina de su banco (a veces es necesario ir allí hasta que tengamos una banca totalmente digital). Entonces Usted llega a la cola y puede apreciar que hay varias personas antes que Usted. En ese momento le llama su esposa y le pregunta: “¿En qué tiempo te desocupas? Mira que tenemos que ir a donde mi mamá.”; Usted responde: “Okay amor, en esto momento no puedo hablar porque estoy en el Banco, pero ya te escribo por Whatsapp o algo.”
Cuelga y se dice a así mismo: “Vamos; soy ingeniero, trabajo en proyectos, también sé algo de ágil…esto no debería ser un reto para mí…” y comienza. Recordará sus años de Teoría de Colas y dirá: “Ley de Little!!…claro”. El tiempo promedio de espera en la cola es igual al número promedio de personas en la cola dividido para el tiempo promedio de atención. Ya está! Cuenta: hay 20 personas antes que Usted, toma el tiempo desde que una persona llega a la caja hasta que sale (digamos 3 minutos) y listo, matemática simple: 20 personas + Usted (21 personas) / (1 persona cada 3 minutos) = 63 minutos, aproximadamente.
Pero espere, antes de que escriba a su esposa por la respuesta recuerde algo; el señor Little decía antes: “En un sistema estable el tiempo promedio de espera es….blah, blah.”. Un sistema estable, ¿qué significa? Serían 63 minutos si todas las personas realizarían el mismo tipo de transacción exactamente, y que la persona en la caja se demore exactamente ese tiempo de atención por cada transacción sin cansarse. Además, pasan cosas: “se fue el sistema!” (muy típico al menos en mi país), es el descanso de la persona en la caja, lo reemplaza otra persona que está aprendiendo a usar el sistema, una persona se cuela por la parte de adelante, se va la energía eléctrica, habilitan una nueva caja, etcétera.
En otras palabras: Variabilidad. Variabilidad interna y externa al sistema. Estos y otros posibles cientos de factores que influyen en el comportamiento general del sistema. Con los equipos ágiles es muy similar, la diferencia es que estos factores pueden ser muchos pero en verdad muchos más.
Imagine que el siguiente gráfico representa la Velocidad de un equipo ágil en el tiempo:
Fíjese que en los primeros sprints la distancia entre su mejor velocidad histórica (la línea superior del rango) y su peor velocidad histórica (la línea inferior del rango) es más ancha; y a medida que el equipo corre sprints, esta distancia tiende a estrecharse. Esto es gracias a varios motivos, pero obviemos eso por ahora. Estamos tranquilos allí en la oficina y nos hacen la pregunta típica: ¿y en cuánto tiempo estará la feature X si trabajamos con el Equipo 1? Vale, hagamos el ejercicio de proyección:
En función de su desempeño histórico, podemos deducir un rango de fechas en el que equipo puede entregar la feature: entre la fecha X y Z; y podemos contemplar escenarios: en un mejor escenario la fecha X, en un escenario esperado la fecha Y, y en un escenario pesimista la fecha Z. El rango de fechas será más grande mientras más temprano en el tiempo tome su desempeño para proyectar (más alta es la varianza). Entre más estrecho el rango, la probabilidad de entrega es mejor.
Pero no se olvide, complejidad y variabilidad: ¿este equipo conoce el dominio y las tecnologías de implementación?, ¿ha trabajado antes sobre esto?, te comento que la mitad del equipo se va de vacaciones por esa época, etcétera. Variabilidad externa e interna. No hay ciencia exacta.
Entonces, ¿qué le decimos a la esposa?: “Amor, ve avanzando…allá te veo.” :)
¿Quiere ser predecible? Reduzca la variabilidad
Hay que reconocerlo: no se puede ser predecible en contextos complejos y sujetos a variabilidad como el desarrollo de software; entre más complejo el sistema y más elementos que añadan variabilidad menos preciso seremos. Es la realidad.
Si queremos lograr un mejor nivel de predictibilidad debemos trabajar sobre la variabilidad. La variabilidad interna (al alcance del equipo):
- Reducir el batch size (reduzca el tamaño de los ítems de trabajo o Historias)
- Revise el tamaño de la cola (ítems en el backlog)
- Clasifique el trabajo (tipos de ítems de trabajo)
- Establezca restricciones WIP (en cuántos ítems podemos trabajar en función de nuestra capacidad)
- Enfocarse en generar flujo
- Identificar cuellos de botella y supeditar el flujo a las restricciones
- Equipo cohesionado trabajando junto durante un tiempo, no lo desarme
- Otros.
La variabilidad externa (más difícil y a veces fuera del alcance del equipo):
- Evitar distracciones organizacionales
- Evitar multi-tasking o trabajar en varios proyectos al mismo tiempo
- Contar con ceremonias de sincronización y alineamiento
- Mucho feedback con Clientes y Stakeholders, entre otros.
Y nada, las cosas pasan…no se puede contener todo y no sabemos lo que sucederá hasta que pasa.
Con respecto a #NoEstimates
#NoEstimates es una perspectiva -y movimiento- que se enfoca en medir la entrega real de valor, por sobre obtener “medidas” a piori para saber cuánto trabajo se puede realizar y en qué tiempo. Es decir, en lugar de ponernos a obtener estas medidas (estimates), mejor hagamos el trabajo, entreguemos y luego sabremos realmente cuánto hicimos. En este contexto, las estimaciones (estimates) son desperdicio (“waste” desde el punto de vista Lean). De acuerdo, como mencioné: el número en sí mismo no es lo importante; más no así el proceso de estimación. Para #NoEstimates tanto el proceso y el resultados son desperdicio; yo simplemente discrepo con respecto al proceso. El proceso de estimación -independientemente del número obtenido- puede ser valioso para los equipos.
Pensamientos finales
A modo de resumen:
- Las estimaciones (Estimates) pueden ser útiles, pero es mucho más útil contar con la información histórica de entrega real.
- El proceso de estimación es un proceso de entendimiento compartido, ayuda a comprender la magnitud del problema, identificar riesgos y llegar a consensos.
- El problema no son las estimaciones, es problema es enfrentar la necesidad de predictibilidad.
- Los sistemas complejos poseen variabilidad, a mayor variabilidad peor predictibilidad. Nunca será 100% predecible, abrace la variabilidad.
- Si desea ser predecible -en la medida de lo que eso signifique- entienda y trabaje con la variabilidad interna y externa.
- #NoEstimates en un enfoque hacia medir el valor real logrado en lugar de obtener cosas medidas a priori, no podría estar más de acuerdo.
- Nunca deje esperando a su esposa…o a su suegra :)
Gracias por leer y por sus comentarios.
Johnny
