Estimando.

En Comunica... ¿QUÉ? me planteaba que debería, como programador, leer más blogs de líderes de proyectos y analistas, para tener una mirada diferente del proceso de desarrollo.

Pues manos a la obra y ya tengo en mi reader un par de blogs más que interesantes. Poniéndome al día en ellos, encontré este intercambio de ideas (discusión, bah) que comienza con Planning Poker distribuido por Rodrigo Corral, sigue en los comentarios de esa entrada, segundo round en la entrada Estimaciones Agiles, no Extremas de Lucas Ontivero y final (ya un poco salida de sus cauces) en los comentarios.

Antes que nada aclaro que es mi idea dar una opinión más desde la experiencia que desde lo académico, ya que considero que he leído lo mínimo y ni siquiera me atrevo a citar por miedo a quedar en ridículo. Pero bueno, he estimado bastante solo y en grupo y obtenido una amplia gama de resultados.

Definitivamente el método de estimación debe ajustarse para cada equipo y situación en particular. Eso no impide pensar en algunas generalizaciones:

Los argumentos derivados de la "participación de todo el equipo en la estimación" que vuelve al proceso "más democrático" en general me hacen un poco de ruido.

En principio porque adhiero al concepto general de "la solución más simple es la mejor". En este caso, para decirlo crudamente, "cuantos menos monos y navajas haya en la fiesta mejor". Esto no implica ignorar diferentes voces ni desechar aquellas con las que no se está de acuerdo, pero de todo el equipo deberían participar en las reuniones la menor cantidad de integrantes que permita llegar una estimación razonable. A mayor cantidad de participantes los tiempos de reunión y discusión crecerán exponencialmente. La estimación mejorará, es cierto, pero a partir de cierto número sólo en forma ínfima.

Y está el tema de la "democracia" y la "participación". Un equipo de desarrollo no es una democracia, el que crea estar en una vive engañado. El objetivo es estimar, no ponerse de acuerdo ni hacer que el personal se sienta motivado (hay mejores formas de lograr esos objetivos que levantar tarjetas numeradas). La participación real se acota a las personas que el líder juzgue relevantes (esto anula lo de la democracia), y en definitiva él tendrá la última palabra. Pueden haber 10 personas en la reunión, pero tal vez él presta verdadera atención a dos o tres (imaginemos en qué planeta puede terminar su cabeza si se discuten detalles técnicos), y en este caso ¿para qué están las otras?. Por algo lleva la responsabilidad (si no la tiene no es el líder, no importa lo que diga su tarjeta). En última instancia, estos juegos participativos multitudinarios le servirían más para diluir sus culpas (e incluso de eso dudo, de cara a un cliente) que para llegar a la estimación.

Deberíamos confiar en que los que participen en la elaboración de los tiempos consulten con algún otro integrante los temas puntuales cuando sea necesario. Deberían exponer luego los resultados al resto del equipo o se podría requerir una última revisión formal por parte de todos (pero cada uno revisando su copia de la planilla por separado y anotando sus dudas).

Una solución de ese estilo permite una reunión más parecida a una charla que a un complicado ejercicio rodeado de un sinfín de reglas, elementos medio ridículos, idas y vueltas: que te saco, que me quitás, que la tarjeta, que paso, aumento, doblo y cuánto me das por un par de pantalones (quisiera saber qué es lo que hace el jefe con las reglas cuando la cosa no avanza). No hay como la comunicación informal y entre 6 o 7 personas es imposible mantener una línea.

Un punto más: si haciendo una revisión de lo planificado un programador ve una zona oscura le será más fácil exponerla detenidamente al líder técnico (o al compañero que participe en la estimación) que al líder de proyecto. Y es el líder técnico, que tiene más aceitada la "práctica de la reunión" el que está en mejores condiciones de traducirlo en un número para el líder, que usualmente no tiene interés en los detalles.

Otro de los puntos debatidos es la participación de los juniors o los expertos. Bueno, aquí está el tema de cómo definimos "junior". Un junior es por definición alguien que, más allá de su nivel de programación, no tiene experiencia. Mal puede estimar si no sabe más o menos qué es lo que va a hacer (y esto implica 80% experiencia y 20% corazonada). Además el nivel de abstracción requerido para estimar supera en mucho el que puede alcanzar un junior (si no es así simplemente no es un junior). Por supuesto que si un punto de la estimación no es más que un agregado de tareas uniformes que el junior ha repetido varias veces se le puede preguntar. Pero es diferente "¿Cuánto tardás en hacer un ABM estándar?" y luego multiplicar por 10 pantallas que más o menos creemos que van a ser, más un 30% por las dudas que preguntar "¿Cuánto tardás en hacer las pantallas de parametrización del módulo de tesorería?".

Es decir, lo que define a una persona como "experto" es que cuando sabe dice y cuando no sabe, sabe a quién preguntar. Si tenemos uno o varios expertos estimando tendremos también estimando a todos los juniors necesarios sin necesidad de alquilar un teatro para la reunión.

Para terminar... una mea culpa sobre las estimaciones "siempre optimistas" de los programadores... ¡es así, absolutamente! Pero no lo hago a propósito, lo juro.

Y una última nota sobre teoría. La única que me ha llamado la atención desde siempre, por lo coherente del planteo, es la de XP. Primero se determina a quién se le asigna la tarea, luego se pide la estimación (si es una tarea amplia tal vez sea necesario dividirla: en XP se mezcla el diseño con la estimación y esto con la codificación, y la codificación con la prueba y todo con todo, es fabuloso). ¿Qué importa si es un junior, un experto o un monito con navaja? Si parece mucho, se puede preguntar a otro cuánto tardaría él y en todo caso reasignar. Luego se proporciona feedback individual para que cada uno vaya ajustando sus propias estimaciones futuras (era así, ¿no? En todo caso es una buena idea).

Me estoy alejando de la seguridad de las costas que conozco de memoria para adentrarme en un océano desconocido. Sean los expertos indulgentes y didácticos en los comentarios, más que hirientes y sarcásticos como son de costumbre.