Estimar desde mi experiencia fue una actividad que me costó entender apenas empecé a trabajar como desarrollador. ¿Estimar por puntos? ¿Qué representan esos puntos? ¿Cómo le asignó puntos a algo que no conozco? ¿Por qué no usamos fechas?
Antes de comenzar, podemos decir que al momento de estimar buscamos poder expresarle a un cliente cuanto tiempo o esfuerzo nos va a llevar realizar una determinada tarea o proyecto.
Por otro lado voy a hacer dos distinciones en lo que serían tipos de estimación, la estimación absoluta y la estimación relativa. Ambas tendrán sus ventajas y desventajas según el tipo de tarea o proyecto a realizar pero en el caso de agile se recomienda la segunda y a continución veremos por qué.
Estimación absoluta
Este tipo de estimación es comúnmente utilizado en las metodologías tradicionales y los tiempos son definidos por el cliente o el gestor de proyectos a cargo. Esto presenta una serie de desventajas como por ejemplo la poca flexibilidad de qué tareas realizar, ausencia de feedback por parte del cliente, y a su vez no existe la oportunidad de adaptarse a distintas situaciones que puedan surgir durante el período de tiempo que el cliente especificó. Personalmente creo que cuando hay fechas de por medio, ésta forma de estimar se vuelve un compromiso.
Estimación relativa
En este tipo de estimación lo que hacemos es comparar tareas o historias de usuario (si usamos SCRUM) por puntos de esfuerzo o dificultad, por ejemplo supongamos que tenemos que escalar una montaña de 200mts, imaginemos que escalar esta montaña nos lleva 1 punto de esfuerzo. Entonces dado ese valor podemos decir que una montaña de 400mts, nos llevaría 2 puntos de esfuerzo, ya que es el doble.
Más allá de este simple ejemplo lo que me interesa destacar es que esta forma de estimar nos da la ventaja de no tener que comprometernos a una fecha, simplemente vamos a pronosticar cuantos puntos de esfuerzo podemos realizar. En segundo lugar, hace más precisas las estimaciones basándonos en la forma de trabajar que tenemos y a la vez estar atentos a distintas circunstancias que nos puedan complicar la entrega del producto.
¿Por qué no definir un cálculo de estimación basado en horas/días?
Una de las principales causas es porque no sabemos qué es lo que puede ocurrir durante ese tiempo determinado (por ejemplo un miembro de nuestro equipo se enfermó por lo que ahora tendremos un integrante menos así como tambien pueden surgir compromisos o reuniones no relacionadas con el proyecto en sí).
Es importante involucrar a todo el equipo de desarrollo en las estimaciones sin importar la experiencia o seniority de cada integrante, esto para poder generar un ambiente de confianza y buscar un consenso a la hora de tomar decisiones.
A continuación te comparto dos técnicas de estimación relativa para que puedas compartirlas con tu equipo.
Estimación por columnas
En esta técnica podemos usar una escala de talles como vemos en la imágen de arriba y de manera comparativa podemos decir que las tareas simples serían un XS. Otras que sean el doble de complejas serían S y así, siendo XL las más complejas.
¿Cómo darnos cuenta de a que talle corresponde una determinada tarea?
Para esto podemos elegir la tarea más pequeña en cuanto a esfuerzo y asignarle el valor XS. Una vez realizado esto podemos utilizarla como pivote y de manera comparativa le damos un orden jerárquico a las demás tareas de acuerdo al nivel de complejidad.
¿Cómo es el flujo de esta actividad?
Inicia un/a integrante del equipo tomando la primera tarea de una determinada lista de tareas a realizar, se encarga leerla en voz alta a los demás miembros y luego la ubica en la columna de talles que considere más adecuada para la complejidad que estima de esa tarea.
Luego continúa otra persona del equipo, siguiendo un orden preestablecido, el próximo integrante va a decidir si tomar una nueva tarea de la lista y repite el procedimiento anterior ó va a mover la tarea anterior a otra columna.
En caso de decidir mover una tarea o historia de columna es importante que la persona exprese su fundamentación para realizar este movimiento.
Un sitio útil para llevar a cabo ésta herramienta de estimación:
Planning poker
Para esta técnica no vamos a usar talles, vamos a usar la secuencia de Fibonacci.
¿En qué se diferencia de la estimación por talles?
En este caso cada integrante tiene la posibilidad de elegir una carta con un determinado valor, el scrum master o project manager sería el encargado de describir una determinada tarea a realizar, una vez hecha la descripción cada uno de los miembros del equipo de desarrollo muestran la carta que ellos consideren que corresponde con la dificultad o esfuerzo de dicha tarea, esto lo hacen todos los miembros del equipo a la vez.
¿Por qué se recomienda mostrar las cartas a la vez?
Esto es para evitar la influencia en la decisión de nuestros compañeros de equipo. Por ejemplo si somos un desarrollador que no tiene experiencia previa en el rubro y en nuestro equipo hay un compañero que tiene 8 años de experiencia en estimaciones y desarrollo de software, quizás para nuestro compañero una determinada tarea le lleve 3 puntos de esfuerzo.
Suponiendo este caso cuando el de vuelta primero su carta nosotros nos vemos influenciados por su experiencia, dado que si a nosotros desde la inexperiencia esa misma tarea nos requiere 8 puntos de esfuerzo (a nuestro parecer), al vernos influenciados por nuestro compañero podemos cambiar nuestra carta por 3 puntos como decidió nuestro compañero.
Esto causaría efectos negativos ya que si nos toca resolver esa tarea no lo vamos a resolver tan rápido como él y esto puede hacer que el equipo de trabajo se vea afectado, por eso en esta actividad se trata de mitigar la influencia votando todos a la vez.
¿Qué hacemos si cada miembro eligió una carta distinta?
Si los números de las cartas son secuenciales por ejemplo salió 1, 2, 3 y 3, lo que podemos hacer es realizar una suma de estos y calcular el promedio.
En cambio si no son secuenciales por ejemplo 1,2,5 y 8, la persona que escogió el número más bajo nos debe comentar por qué considera que la tarea es más fácil y la persona que escogió el número más alto nos debe comentar por qué considera que la tarea es más difícil. Acá pueden ocurrir dos cosas, la primera es que alguno de los dos decida bajar o subir el puntaje de esfuerzo (permitiendo calcular un promedio). Y la segunda es que ninguno cambie de opinión, lo que se recomienda en este último caso es realizar nuevamente la votación y a partir de esto buscar un promedio.
Un sitio útil para llevar a cabo ésta herramienta de estimación:
Conclusión
Al momento de desarrollar ésta actividad en un marco agile es mas productivo buscar un pronóstico y no un compromiso a una fecha futura a la cual definitivamente no sabemos que puede pasar en el medio, de esta forma evitamos el trabajo bajo presión en cuanto a tiempos y las consecuencias que esto genera en la salud de un equipo.