Se que existen miles de artículos e incluso videos de esto en internet pero quise compartir mi visión del cómo se deben hacer las estimaciones en proyectos tratando de ser lo más dummy posible, así que aquí vamos:
Las estimaciones ágiles nacen para dar una visión del esfuerzo y más o menos tiempo que puede darnos realizar unas actividades; el cuando podríamos tener versiones para ser desplegadas en ambientes productivos y un más o menos cuando estamos acabando.
Quiero hacer énfasis en el más o menos, porque esta carrera quien diga que sus estimaciones son 100% acertadas, dejame decirte mi quiero amig@ te está mintiendo. Como su nombre lo indica son estimaciones y las usamos para darnos una visión, no para darnos una realidad absoluta.
Debemos empezar por entender que en las estimaciones ágiles es que no se hacen con base a tiempo, el tiempo no es la medida para dar los valores (puntuaciones) de la estimación. Para hacer estimaciones ágiles usamos una técnica de comparación en la que las actividades del backlog son comparadas unas con otras y así ir determinando su peso.
Para empezar a comparar lo primero que debemos definir es un pivote y ¿Que es un pivote? Un pivote es un item del backlog en el que todos los miembros del equipo se ponen de acuerdo y se da un peso, con este pivote definido se procede a comparar a otras actividades y determinar si es menor,mayor o igual que el pivote. Para definir el valor del pivote es criterio 100% del equipo y puede ser el valor que ellos deseen darle (Tip: no elegir una actividad muy grande que no exista algo más grande que ella, ni una actividad muy pequeña que luego no haya algo más pequeño, se debe elegir una actividad que sea entre mediana-pequeña para que el ejercicio funcione bien; veamos un ejemplo un poco tonto:
Tenemos las siguientes items en el backlog:
- Hervir agua
- Preparar arroz blanco
- Lavar el arroz
- Preparar arroz con pollo
- Preparar arroz con coco
- Preparar paella
Ahora lo que debemos hacer es elegir un item del backlog (recuerden: ni muy grande ni muy pequeño) para este ejemplo voy a elegir Preparar arroz blanco y le voy a dar una estimación de 3 (Las estimaciones se recomienda hacer con la técnica fibonacci, más adelante explico la razón). ¿Por qué 3? ¿Por qué no un 2? la respuesta: Porque SI.
Cuando tengamos ya cual es la actividad pivote podemos empezar hacer las comparaciones (estimar no es más sino un proceso de comparación), empecemos:
¿Cuánto puede ser la estimación para hervir agua? Si alguien piensa en un 5 o un 8, entonces no ha entendido el ejercicio. En este caso MI estimación es un 1 porque es mucho más fácil hervir agua qué hacer arroz.
¿Cuánto puede ser la estimación para hacer arroz con pollo?. En este caso MI estimación es un 8, ¿por qué? porque hacer arroz con pollo es más que solo hacer solo arroz.
Terminemos el ejercicio:
- Hervir agua : 1
- Preparar arroz blanco: 3
- Lavar el arroz: 2
- Preparar arroz con pollo: 8
- Preparar arroz con coco: 5
- Preparar paella: 21
Para hacer la estimación en equipos, se recomienda usar la técnica de planning poker.
Planning Poker
Esta técnica consiste en que todos los miembros ocultan su votación hasta el final y todos los miembros revelan al mismo tiempo su votación.
Se recomienda usar esta técnica debido a la influencia que se puede dar en las votaciones si una persona dice su votación antes que los otros miembros. Veamos el siguiente ejemplo:
Pepito es una programador junior que acaba de llegar al equipo y Sutanita es una programador Senior que lleva 1 año en el proyecto y llega el momento de votar, el PO (product owner) presenta la historia y Pepito está pensando que es un 3 o máximo un 5 por la razón X y Z, antes de que pueda decir su opinión Sutanita dice que es 13 y no da razones.
¿Creen ustedes que Pepito va a decir algo diferente a Sutanita? por supuesto que no, su opinión ya fue nublada por la votación de Sutanita y posiblemente Pepito tenía razón y callará su opinión por miedo a quedar mal.
Con esta técnica todos sacan su votación al mismo tiempo y en caso de haber divergencias (y las habrá) exponen sus argumentos de la votación mínima las dos personas que tuvieron las dos votaciones más diferentes. Una vez se exponen los argumentos de parte y parte se procede a votar nuevamente en caso de haber divergencias nuevamente se elige la votación con más votos. Es mejor parar en la segunda votación habrán casos donde sea imposible llegar a una votación unánime y para no quedarse votando infinitamente se para a la segunda vez de la segunda votación.
¿Por qué usar fibonacci?
La razón para usar fibonacci es para que las estimaciones entre mas grandes mas se alejan una de otra y evitar discusiones bizantinas, pongamos el caso de la comida nuevamente sin fibonacci Fulanito piensa que para hacer arroz con pollo es un 6 y Sutanita un 7, ambas puede tener un argumento válido para su votación pero eliminando el 6 y 7 de sus posibilidades tendrán que coincidir en un 5 o un 8. ¡Evitemos las tibiezas!
¿De qué se compone un punto?
Ya di mi visión de cómo generar las comparaciones de las historias del backlog, ahora explicare que es un punto de historia; Para dar el valor de un punto de historia debe tener en cuenta 3 variables:
- Complejidad
- Esfuerzo
- Incertidumbre
Imaginemos un par de historias para poder entender esto:
- Fulanito debe escribir una plana en 100 hojas, ¿cuanto incertidumbre tiene esta tarea? Para mí un cero, pero debe ser un esfuerzo terrible hacer esa tarea ¿no?.
- Sutanita debe conectarse con un microservicio X para consumir los datos Y y transformarlos en Z para luego ser enviados a través de email. Tremendo problema de tarea donde la incertidumbre es altísima, no sabemos el esfuerzo, pero sí que la incertidumbre es muy alta.
Con los ejemplos anteriores un poco irrisorios dan a entender que para dar el valor de un historia se debe tener en cuenta las 3 variables y no una ni dos de ellas, las 3.
Tips:
- Escoger una historia pivote que todos o la mayoría del equipo conozcan cómo realizar para facilitar las comparaciones posteriores.
- Es posible tener mas de un pivote, ejemplo un pivote para tareas front y uno para tareas backend
- Antes de comparar la velocidad de tu equipo debes verificar la historia pivote que se usa para usar las comparaciones, recuerdo una historia cuando un manager me dijo que un equipo hacia 400 puntos por sprint y el mio solo 40, que como era posible, cuando fui a validar la historia pivote para ellos era un 34 y para nosotros era un 3.
- Los marcos de trabajos ágiles son para darnos una idea de cómo hacer las cosas, no es una biblia o un mandato que se deba cumplir al pie de la letra. Recuerda que cada equipo/proyecto/empresa tiene particularidades diferentes, prueba y adaptate a lo que más te beneficie.
- No olvides contemplar cuanto te va a costar probar la historia, que el desarrollo no tarde no significa necesariamente que las pruebas lo serán.
- Si aún tienes dudas de la historia a votar, no votes, se valiente y pide una nueva explicación.
Si tienes algún otro te invito a comentar.