¿Estimar no sirve para nada?

"El Oráculo de Delfos dijo que yo era el más sabio de todos los griegos. Es porque solo yo, entre todos los griegos, sé que no sé nada."
                                                                       Sócrates.

Al McWhiggin: - Y cuánto tardará?
Geri: - Lo que tenga que tardar.
                                                Toy story 2.

Desde tiempos inmemoriales y en las más diversas disciplinas y situaciones, se ha abordado la predicción del futuro. Desde Nostradamus a Aschira. Desde el tarot a cualquier religión con un profeta entre sus páginas. Desde las runas vikingas al machine learning. Desde el Dr. Brown a Nadia Zyncenko en la TV pública. Todes predicen, todes profetizan, todes adelantan, todes tiran un "lo que viene lo que viene en Futbol de primera". Hay una necesidad de saber de antemano todo lo relacionado a acontecimientos tanto nimios, como el juicio final, hasta sobrecogedores, universales y trascendentales, como el tiempo que tardará en llegar a producción el cambio del nombre de un campo en la base de datos.

Pero, ¿De qué sirve ocupar el tiempo en toda esta predicción? ¿En qué mejora el resultado final? ¿Qué ganamos?

Bueno, depende. Ganamos si se cumple. Mmmmmm, a ver. Supongamos que Nadia en la TV pública dice que va a llover. Entonces, salgo con paraguas. Esto puede resultar de dos maneras (ahorremos los grises). Sale bien: Llueve, ¡menos mal que traje el paraguas! Sale mal: No llueve, tuve que andar todo el día en colectivo con éste a cuestas.

El valor depende del resultado. Pero entonces, repito mi pregunta, juez, ¿Son válidas, quiero decir, sirven para algo las predicciones del tiempo cuando no tenemos el diario del lunes?

Las estimaciones son algo así. Nos juntamos y decidimos que esto va a demorar tanto o tener tal complejidad. Y nos engañamos, permítanme el exceso argumentativo, diciendo que los puntos no están relacionados al tiempo absoluto. Que son relativos. Si estimamos usando Planning Poker, por ejemplo. Decimos un dos demora el doble que un uno, un tres demora un poco más que un dos pero no el doble. Ok, ¿cuánto duraba el uno entonces, compañere? Y, la mitad de un 2. Entiendo ¿Y el 2 cuánto dura? Y, el doble del uno. … Ok, Y el uno? La mitad de un 2... Y así hasta el infinito. Por supuesto, podemos establecer ejemplos, algo que resulta más sencillo con los números bajos, por ejemplo, cambiar el nombre de un campo en una db podría ser tomado como un ejemplo de 1. Pero aun así, como lúdicamente explico en mi post "Sinfín Cynefin. Le developer y el loop temporal", un exacto mismo problema puede presentar diferentes complejidades de acuerdo a la coyuntura.

Me huele a verso.

Por más que esquivemos con terminología atemporal, estamos hablando de tiempo.

Y cuando hablamos de tiempo hablamos de expectativas. Y cuando hay expectativa hay presión. Y trabajar presionade es trabajar limitade. Y trabajar limitade es un bajón. Por supuesto, no en todos los equipos es tan directa la relación. Esto no quiere decir que todos los equipos que estiman sean un bajón. De hecho, por experiencia personal puedo garantizar que no es así. Nosotres estimamos en el equipo del que actualmente formo parte y yo estoy feliz como una perdiz. Pero, de nuevo, en mi experiencia, esto me pasa porque yo (Y fijate el pedazo de frase que te mando) "subestimo la estimación". Aprendí a no darle tanta importancia al número y enfocarme en las características. Y si un 2 me lleva diez días, no es un problema. Al contrario, es una oportunidad de aprender.

Lamentablemente, he visto varies compañeres a les que el número les presiona, y este post apunta a evitar esta posibilidad. Bueno, ¿en qué estaba?

¿Pero entonche? ¿No estimamo má?

Wait. ¡Ya sé! ¿No lo estaremos haciendo mal? Por ahí el tema es que debemos mejorar en las estimaciones. Refactorizar nuestra forma de estimar.

A ver, ponele que una semana le jugás a la quiniela y, como suele suceder en ciertas ocasiones en este bendito planeta, perdés. ¿Te pasó alguna vez pensar que "tal vez el problema es que no estoy jugando bien a la quiniela, la solución podría ser mejorar en jugar a la quiniela"?

No te pasa, ¿no?

Ok, pienso entonces resignadísime: ¿Será que es verdad que no sirven?

Las estimaciones pueden hacer más daño que solucionar problemas, en realidad, si se analizan como compromisos, o incluso como datos con algún grado de certeza. Lo que sí (sí sí claro que sí!) presenta ventajas y provecho es el proceso en que las realizamos. Esto es, los números no importan, pero el trayecto hacia ellos, el debate previo y posterior, el acuerdo tácito o explícito, si sirve al promover un entendimiento del concepto y las posibles vicisitudes a enfrentar o resolver.

El proceso de estimar es lo que sirve. Si se hace bien, con calma, con osadía (Animate a decirle al pm cuando te discute un 1 a un refactor en una api con 350 endpoints, mirándolo de reojo: You talkin' to me? Then who the heck you talkin' to? You talkin' to me?), con conciencia y que tome todo lo que tenga que tomar para que queden bien en claro las metas y el contexto de cada historia. Los números deberían ser más un tema lúdico y mero disparador de lo que nos debe importar. Y que al final a nadie debería importarle. Es importante desligarnos de la noción de que los números definen una complejidad que a su vez define un tiempo, ya que nos falta una variable bastante relevante que mencionaré en los próximos párrafos (Suspensoooo…!!!.)

Planning

Una planning suele desarrollarse de la siguiente manera:

Primero el PO presenta una serie de tickets a relevar. El equipo escucha atentamente la descripción de los mismos y se toma unos segundos para procesar cada uno de ellos. Luego, todes les integrantes del equipo de desarrollo estiman, al mismo tiempo, para evitar que su juicio se vea influenciado por los demás. De nuevo, los números no importan, lo que importa es que esos números sean expresados sinceramente y que la puesta en común de las diferencias sirva para evaluar posibles imprevistos no tenidos en cuenta por descuido o ignorancia.

El proceso podría terminar allí. Sin reducir las opciones ni acordar un número final que no significa nada. ¿Por qué?

Supongamos que yo le pongo un 5 a una historia y otre dev le pone un 2. Puestos en común, explico que "No conozco ese código, jamás he visto ese código ni he tenido contacto con él pero… perdón no puedo seguir". Y mi compañere me dice que elle, sí, que no es tan complicado, que lo puedo aproximar de tal o cual manera. Lo hace subjetivamente, porque nadie puede escapar a su subjetividad. Pero entonces, ¿Cuál es el puntaje? Si le ponemos el 2 de mi compañere, y yo hago ownership del ticket, nunca podré terminarlo en el tiempo que un 2 implica. Y si le ponemos un 5, por las dudas, porque mi compañera es ownership… ¿lo terminará antes? Bueno, lo dudo. Entra aquí una maravillosa leycecillia llamada Ley de Parkinson, que dice: "el trabajo se expande hasta llenar el tiempo disponible para que se termine" (Parkinson - The economist - 1955). O sea que si lo estimamos con un 5, incluso la persona que en un principio lo estimó en menos, demorará el tiempo relacionado a 5 puntos.

También ya que estamos con leycecillias, cabe mencionar la Ley de Hofstader: "(Una historia) siempre nos lleva más tiempo de lo esperado, incluso teniendo en cuenta la ley de Hofstadter" (Hofstadter - Gödel, Escher, Bach: un Eterno y Grácil Bucle - 1979).

Amé.

No solo porque seamos malos estimando, no solo porque no consideremos cuestiones relacionadas a la complejidad o conocimiento del dominio a estimar, sino porque suele pasar en la mayoría de los casos que tenemos todo controlado, super reconocido y recontra analizado y suele meterse en el medio esa maldita cosa que no hay caso, no nos deja en paz e interviene en todo aunque no la queramos y la odiemos con todo nuestro corazón. Esa cosa llamada: Vida.

La vida junto con todas sus vicisitudes y su desparpajo, y su aleatoriedad y desvergüenza, se mete cuando nadie la invita y nos tira abajo los planes y los esquemas.

Conclusión

Estimar no solo es innecesario en la mayoría de las ocasiones, sino que suele ser contraproducente para la tranquilidad y el trabajo libre de quien desarrolla. Resultan infinitamente provechosas las descripciones previas de las historias y el debate que se da, dentro del equipo, sobre los posibles obstáculos a enfrentar, así como el punto de complejidad de cada una de ellas.

Si bien es utópico, teniendo en cuenta la penetración que tiene esta práctica en los procesos ágiles actuales, pensar en eliminarlas por completo; es buena idea trabajar, no en mejorar en la estimación que, de nuevo, es como querer mejorar en el quini 6, sino en aprovechar y profundizar en lo que las rodea, que es lo que finalmente resultará más provechoso para les participantes y el proyecto en general.

Además, nunca lo olviden: "Un 1 es la mitad de un 2, y un 2 es el doble de un 1".