Introducción
A todos nos ha pasado que cuando nos piden estimar le ponemos mucho empeño, ponemos todo de nuestra parte pero a la hora de la verdad nuestras estimaciones no dan en el clavo. Te duele estimar y lo sabes.
Lo que suele ocurrir después es que recibimos quejas del tipo: es que tú te comprometiste a tal fecha, es que tú me dijiste que tal y frases similares que no hacen más que perjudicar al equipo de desarrollo ya que además se tiende a culpabilizar, en lugar de buscar el origen raíz del problema.
De hecho, la siguiente imagen de https://www.monkeyuser.com/ refleja muy bien la situación que se suele dar con las estimaciones:
Y es que ni aún viajando atrás en el tiempo lograrás dar en el clavo con ella.
En mi día a día, he visto cómo la estimación puede llegar a ser una tarea bastante temida en el equipo. El mayor de los problemas está en la mala interpretación del concepto de estimar. En muchos casos, se entiende que la magnitud de la estimación es una fecha y encima que esta fecha es fija. Si nos vamos a la definición de la RAE, el tiempo no tiene cabida en la estimación como observamos:
Entonces, ¿por qué entendemos que una estimación se trata de dar una fecha fija? Pues porque a veces se está malinterpretando el concepto y normalmente, no se requiere una estimación sino un pronóstico.
Veamos ahora la definición de pronosticar según la RAE:
El tema de los pronósticos o forecasting es un tema amplio que abordaremos más profundamente en el próximo post.
Centrándonos en las estimaciones como tal, se nos solicita estimar porque estas permiten determinar el esfuerzo, la complejidad, el valor, el tamaño de un proyecto y en función de ello se hace una planificación para ejecutar ciertas acciones.
Vemos más en detalle cuáles son los motivos que suelen darse en las empresas y que nos inducen a proporcionar una estimación errónea.
Las principales causas por las que los equipos fallan al estimar son:
1.- Se dispone de una gran cantidad de trabajo en curso (Work In Progress – WIP)
El principal motivo por el que se produce esta situación es que no somos capaces de enfocarnos en terminar las tareas que ya están en curso. Incluso, muchas veces, he notado que algunos managers cuando se produce un bloqueo insisten en iniciar otra tarea por considerar que los desarrolladores están ociosos, en lugar de perseguir el bloqueo o dependencia.
Esto provoca pérdidas de tiempo por cambios de contexto entre tareas y esto impacta sobre todo en la calidad del producto final que ve afectada la calidad. Como podemos ver en la siguiente tabla, la pérdida de tiempo por cambios de contexto aumenta según el número de proyectos con los que estemos trabajando:
Fuente: Quality Software Management – Volume 1 Systems Thinking. Autor: Gerald M. Weinberg
Si quieres ampliar tu conocimiento sobre cómo afectan las interrupciones y cambios de contexto en los equipos de desarrollo, te recomiendo el artículo de Chris Parnin y Spencer Rugaber “Resumption Strategies for Interrupted Programming Tasks” y te sorprenderás de la cantidad de tiempo que se pierde (y los costes que ello supone) en aquellas empresas que tienen por cultura la interrupción constante en el entorno de trabajo.
Puedes descargar el artículo en PDF desde el siguiente enlace:
2.- Pasamos mucho tiempo esperando en colas entre actividades antes de llegar a DONE.
Veamos el siguiente ejemplo: estás en el Parque Warner y quieres subir a una atracción pero la cola que tienes que hacer antes de subir es de 30 minutos. No hablemos de cuando son fechas estivales que puede suponer esta cola una espera superior a 1 hora. ¿Crees que a los visitantes les hace gracia esperar una hora o más por cada atracción? Vas a un parque de atracción a divertirte no a pasarte el día esperando bajo el sol en una cola.
Hay que decir que en la actualidad, los parques disponen de una aplicación que te indica el tiempo de espera en cada atracción y tú decides a cuál ir. Desde que está implantada, la gente a lo sumo espera 15 minutos.
Ahora volvamos al entorno de desarrollo: ¿cuántas veces no has podido empezar o continuar una tarea porque el desarrollador no estaba disponible o bien, porque el entorno de pruebas no estaba listo?
Estos son ejemplos de colas que se nos dan en el día a día en las empresas y son similares a las del parque de atracciones. A la hora de estimar dichas colas tienen que ser visualizadas y tenemos que ser conscientes de ellas ya que la más mínima espera estará afectando nuestra estimación.
Por tanto, el trabajo que se queda en estado retenido, es un trabajo que no podemos gestionar ya que una vez que pasa a una de estas colas, pasa a ser totalmente impredecible. Su tratamiento es fundamental para el éxito del sprint.
Llegados a este punto te pregunto, ¿se están considerando estos tiempos en nuestras métricas? ¿Estás midiendo el Lead Time? ¿Conoces cuáles son las métricas que deberías utilizar?
Para conocer más sobre las métricas ágiles, te dejo el enlace al artículo de métricas ágiles:
https://www.autentia.com/2019/07/10/onceava-entrega-de-fichas-agiles-metricas-agiles/
3.- Son comunes los eventos inesperados o urgencias que se deben atender
Otro factor importante que afecta a los diferentes enfoques de estimación vienen siendo aquellos entornos de trabajo donde son comunes las situaciones que no estaban planificadas y se vuelven tareas de máxima urgencia a atender.
Ejemplos de estas situaciones son aquellas en las que:
- El equipo de desarrollo está al mismo tiempo manteniendo una aplicación y tiene que atender constantemente bugs.
- A un manager se le antoja una nueva funcionalidad o cambio de última hora sin haberlo tratado en la planificación del Sprint.
- El entorno de integración/pruebas/preproducción no funciona porque no se mantiene actualizado.
- Etc.
4.- No están claros los términos y condiciones de trabajo
Seamos claros, a muchos de los equipos de desarrollo a veces les ha caído el desarrollo de un producto agile, con unos términos y condiciones para algunos nuevos, a veces desconocidos, dando lugar a situaciones en las que no se tiene demasiada idea del impacto que ello conlleva por no tener claro cómo proceder.
Y si lo tenían, se toparon con el manager que lo conocía a medias tintas y no quedaban del todo claros los términos y condiciones bajo las que se debía generar el trabajo.
Por tanto, inician el desarrollo y se empiezan a usar términos desconocidos para el equipo tales como:
- El producto, el servicio que tiene sentido para el cliente.
- Las épicas, que vienen siendo esas historias de usuario tan grandes que un equipo no pueden abarcar en un sprint de digamos dos semanas.
- La historia de usuario, si hablamos de un sprint de dos semanas, sería la unidad de trabajo que puede ser terminada entre 2 y 9 días.
Lo que da lugar a grandes malentendidos y empieza a generar caos dentro del equipo.
Un ejemplo de la situación a la que se puede llegar, es la que se describe a continuación buscando la analogía con un conocido videojuego.
El videojuego en cuestión es Super PANG!. Este consiste en destrozar todas las pelotas que rebotan por la pantalla. Cada vez que se impacta en una pelota grande esta se divide en pelotas más pequeñas.
Pensemos en el Super PANG!, somos el Product Owner y varios productos que entregar, ¿qué ocurre si disparamos a los balones de tamaño producto?:
Como observamos en la imagen anterior, un producto se divide en varias épicas de tamaño inferior y a su vez estas se dividen en historias de usuario más pequeñas aún. Las historias de usuario pueden ser tratadas en un Sprint y en el juego si se impactan desaparecen.
Entendiendo el modus operandi del juego, tomemos la situación siguiente. Somos el product owner y tenemos ante nosotros dos productos que desarrollar:
Al tratar ambos, estos se dividen en 2 balones de tamaño Épica cada uno:
¿Y si disparamos a las Épicas?
Pues como vemos se nos llena todo de Historias de Usuario que debemos abarcar en el Sprint. Teniendo en cuenta que si en el juego nos impacta una pelota moriremos. ¿No crees que se está complicando la cosa?
Pero el asunto no acaba ahí, si ya se nos empieza a complicar el tema, resulta que en la vida real tenemos riesgos, urgencias, incertidumbres, etc. que pueden dar al traste con nuestros objetivos. Recordemos el punto 3 de la lista “Son comunes los eventos inesperados o urgencias que se deben atender”, en la imagen representados con los pájaros que nos lanzan objetos:
Nuestro Sprint se puede volver demencial. Por tanto, la consecuencia de desconocer los términos de trabajo puede llevarnos a tomar malas decisiones.
En la situación mostrada, ¿es esta una buena estrategia?
No, desglosar tu producto en decenas o centenas de historias de usuario por supuesto que no lo es. La estrategia correcta que te llevará al éxito será terminar todas las épicas que conforman uno de los productos de forma priorizada. De esta forma entregamos algo de valor en lugar de mostrar muchas cosas en progreso.
Conclusión
Las estimaciones son dolorosas y pueden poner en riesgo el desarrollo de tu producto. Por tanto, identificar las causas que producen estos dolores en el/los equipos/s se hace fundamental para la consecución de los objetivos.
Normalmente, más que el problema de no saber estimar, estos se dan por factores externos que rodean al equipo y que son necesarios monitorizar.
El listado aquí mencionado no muestra todos los casos pero sí son una muestra de los que más impactan en las organizaciones.
Existen varios factores psicológicos que además, se dan a la hora de estimar y según el método de estimación y que expliqué juntos a mis compañeros de Autentia en el MeetUp: ‘Hablando de estimaciones, ¿Y lo mío para cuándo?’ donde explicamos mediante gamificación diferentes tipos de estimación y los factores psicológicos tras ellos. Puedes ver la charla desde el siguiente enlace de Youtube:
https://www.youtube.com/watch?v=b1hf0lfPKfg&t=14s&ab_channel=Autentia
Llegados a este punto, estamos listos para conocer el Forecasting en el próximo post, como técnica para dar un pronóstico de nuestras estimaciones.
Cualquier consulta, por favor, no duden en comentar.