Hoy quiero hablar sobre una práctica en el sector que no es algo por lo que a priori nos preocupamos cuando empezamos a trabajar como desarrolladores pero que es muy habitual y puede a llegar a ser muy estresante, estimar.

Descubrimiento del término “estimar”

Cuando comenzamos a trabajar como desarrolladores nos surgen mil miedos como por ejemplo:

• ¿Seremos capaces de estar a la altura?
• ¿Somos suficientemente buenos?
• ¿Sabremos resolver los problemas que nos lleguen?

Pero no es habitual que nos preocupemos de otras cosas igual de importantes en el dia a dia como puede ser tener que saber cuanto tiempo te va a llevar hacer una tarea.

Aún recuerdo la primera vez que de repente y sin verlo venir escuche:

• Pedro, ¿Cuánto crees que te llevaría hacer tarea?.

Un sudor frío me subió por la espalda como pocas veces me ha ocurrido y mil pensamientos me pasaron por la cabeza.

• ¿Qué cuánto me llevaría hacer esta tarea?
• Depende, no lo sé, aún no se muy bien ni cómo la haría.
• ¿Cómo voy a saber lo que me va a llevar así en frío?

Despues de casi un fundido a negro me repongo de la situacion y mas o menos sigo dignamente adelante con la reunión.

En este momento pueden ocurrir dos ocasiones:

• Estimas por abajo para agradar a el cliente pero luego cuando llega la hora de hacer la tarea no llegas porque evidentemente era poco tiempo.
• Estimas por encima para curarte en salud y no pillarte los dedos después pero al cliente le parece mucho tiempo y al final cedes porque ellos mandan.

Lo importante aquí, al menos para mi, es que en ambas situaciones la estimación no ha aportado ningún valor. Al final se ha decidido lo que el cliente cree que es razonable y para la próxima vez irás afinando tu instinto para que coincida con el suyo.

¡Estimemos en puntos!

Pasa el tiempo y las cosas cambian, entre ellas por ejemplo cambias de empresa y entras en un equipo de producto nuevo donde las estimaciones se realizan de forma distinta.

En mi caso pase de estimar en horas a estimar en puntos (1, 3, 5, 7, 9 y 11). Pasar de pensar en tiempo a pensar en el volumen que llevaría una tarea del total disponible para todas las pendientes durante un sprint fue un alivio.

Un alivio que duró poco la verdad ya que durante las estimaciones la mayoría de las veces no había consenso lo que hacía que la opinión de la gente con más experiencia y contexto influyera en los votos del resto del equipo que no lo tenía claro.

En estos momentos pueden ocurrir dos ocasiones:

• Estimas por abajo pensando que no debería llevar mucho tiempo pero la parte más senior del equipo piensa que la puntua
• Estimas por encima porque no sabes muy bien de que se está hablando y el resto del equipo piensa que la puntuación es

En ambas situaciones, nuevamente, ¿han servido realmente de algo las estimaciones? Yo personalmente no lo creo.

Estimemos en tallas de ropa, ¿Porque no??

El tiempo pasa y el equipo decide cambiar la forma de estimar (seguramente provocado por el poco éxito de los puntos).

Se decide que las estimaciones pasarán a ser tallas de ropa, en nuestro caso S, M y L. Esta medida simplifica mucho las opciones pero no aportaba mucho más ya que las estimaciones normalmente siguen influenciadas por lo que opinaba la gente más senior.

¡Y de repente se acabó eso de estimar!

Y cuando menos te lo esperas llegas a un equipo donde no se estima.

El equipo usa un Kanban donde las tareas se van completando de forma continua y entregándose al cliente de forma lo más rápida posible sin comprometer la calidad del producto.

En lugar de tener largas reuniones cada N semanas donde nos ponemos de acuerdo sobre la importancia de la tarea, el equipo solo se decida a analizar y desarrollar las tareas. Sin sprints, sin estimaciones, simplemente entregar valor.

Y puedo decir de primera mano que funciona, aunque no aplique a todos los equipos por supuesto.

Conclusiones

Durante mis años como desarrollador he tenido la suerte de trabajar con diferentes tipos de equipos en los cuales se trabaja de formas completamente distintas.

En mi opinión personal en lo que a estimar se refiere tengo que decir que no creo en ello, creo que no aporta una valor real y que se pierde mucho tiempo para acabar tomando siempre las mismas decisiones basadas en la gente con más experiencia en caso de empresa de producto o en lo que el cliente acepta en caso de empresas de consultoría.

Es evidente que muchas situaciones no permiten no estimar, hay que entenderlo y respetarlo pero siendo conscientes de que hay otras formas de trabajar igual de válidas donde los desarrolladores simplemente se pueden centrar en entregar valor sin preocuparse de estimaciones o sprints.