Típicos tópicos erroneos sobre estimación ágil
Hace algunos días que al hilo de algunos post que hemos publicado sobre estimación Lucas Ontivero y yo venimos manteniendo un debate interesante sobre técnicas de estimación. La estimación es un tema que he tratado de manera habitual en este blog. El defiende un enfoque más tradicional e 'ingenieril' y yo lo que creo que es un enfoque más ágil, posibilista y realista.
En mi último post sobre Planning Poker, una técnica que usan para estimar la dimensión de los proyectos una parte importante de los equipos que usan metodologías ágiles, Lucas Ontivero publica un comentario con ciertas críticas a esta técnica (que podrían ser extensivas a la estimación ágil en general) y que translucen, desde mi punto de vista bastante desconocimiento de porque funcionan las técnicas de estimación ágil. Este desconocimiento es generalizado y fruto de años de frustado enfoque 'ingenieril' y tradicional a la gestión de proyectos. Comentaré aquí porque esas críticas son infundadas y porque la estimación ágil funciona. Esto empezó siendo un comentario, pero creció hasta convertirse en un post. Pongo las críticas de Lucas, que son las de muchos otros, todo hay que decirlo, en cursiva y mi respuesta debajo.
"El Planning Poker es solo una única técnica de estimación y deberíamos usar varias. Usar Planning Poker con Wideband Delphi es comer pan con pan."
Planning Poker y Wideband Delphi casi siempre van de la mano. En el caso del Planning Poker, la clave es que al usar las cartas todas las estimaciones se desvelan de manera simultanea lo que evita que unas estimaciones sesguen otras. Además las cartas siguen una serie inspirada en la serie de Fibonnacci: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, la idea es que es posible diferencia un requisito de 1 de una de 2 pero difícilmente cuando estimamos un requisito en 13 lo podemos distinguir de uno de 14 debido a las incertidumbres inherentes a toda estimación. La incertidumbre de la estimación crece de manera no lineal con el tamaño del requisito a estimar. Usar valores no continuos, sino los valores discretos de la serie planteada, se ha demostrado como una manera efectiva de considerar la incertidumbres que supone estimar requisitos de magnitud creciente.
En lo que se refiere a Wideband Delphi simplemente es un proceso orientado a construir consenso entorno a la estimación a base de compartir información y detectar dispersión en las estimaciones. Sin duda se tratan de dos técnicas complementarias y diferentes. Planning Poker y Wideband Delphi no asumen nada sobre como cada uno llega a su estimación: uno lo hará por descomposición, otro por comparación, otro usando datos históricos, otro simplemente basándose en su intuición… cualquier técnica que permita obtener un resultado rápidamente sirve.
"Las técnicas de estimación ágil necesitan la participación de todos y esto no siempre es posible. Si somos 21, como en mi proyecto, se complica un poco. Aunque sigue siendo factible."
Esto no es cierto. Sobre todo cuando se trata de estimar requisitos que es cuando precisamente se usa Planning Poker. Sin duda es recomendable, pero no imprescindible, que todo el equipo participe en el proceso de estimación a nivel de requisitos, si que es imprescindible cuando estimamos tareas de desarrollo, pero no es este el nivel de granularidad que hoy me ocupa. En cualquier caso si seguimos una metodología ágil, nunca tendremos un equipo de 21 miembros, sino varios equipos con un menor número de miembros. Lógicamente en un proyecto de esta envergadura los requisitos se particionarán de alguna manera y cada equipo atacará un conjunto de requisitos. Se hace evidente que cada equipo podrá estimar el conjunto de requisitos que va a atacar. No hay nada que impida que todos participen.
"Se tiende a eliminar las opiniones extremas y la gente se cansa por lo que empieza una convergencia forzada hacia un valor que no siempre es compartido (en un proyecto de training perdimos 2 días discutiendo hasta que cuando nos cansamos convergimos mágicamente!)"
No se trata de 'llevarse al gato al agua'. En un equipo ágil nadie va a defender sus estimaciones durante dos días. Simplemente es una cuestión de ego y el ego tiene poca cabida en los equipos ágiles. El objetivo es lograr una estimación compartida, consensuada y razonada, nunca tratar de imponer tu estimación sobre la de los demás. Todos asumimos que nuestra estimación puede ser errónea y que solo compartiendo y desvelando información la estimación mejorará. No hay margen para discutir dos días porque todos en un equipo ágil deben conocer que a partir de cierto punto dedicar más tiempo a realizar la estimación solo la mejora marginalmente. Hay una asíntota clara. A partir de cierto punto por más tiempo que pases estimando tu estimación solo será mínimamente más acertada, el esfuerzo no merece la pena.
"Consume más tiempo que los métodos paramétricos, que los que usan analogía y que los "ingenieriles""
No comparto está afirmación. Múltiples estudios (me remito a la bibliografía de Steve McConnell) cita que uno de los motivos porque los métodos tradicionales de estimación no se llevan a cabo es porque se percibe que consumen demasiado tiempo. Las sesiones de estimación ágiles siempre están limitadas en el tiempo, no hay margen para la divagación. Es una práctica habitual en las metodologías ágiles establecer límites temporales claros e inviolables a toda reunión o proceso.
"Hace falta un buen moderador para llegar a buen puerto."
No se suele necesitar un moderador. En equipos que tienden a divagar o a dispersarse, generalmente por no estar entrenados en la estimación, un simple reloj de arena es suficiente. Una vez consumido el tiempo se estima si o si. Insisto, no por más comentar un requisito o discutir una estimación vamos a obtener una mejor estimación. Si hay dispersión, se produce otra ronda. No he vivido nunca más de tres rondas de estimación y ayudo a estimar a muchos equipos a lo largo del año. En cualquier caso, creo que ser un buen moderador es una característica que todo gestor de proyectos eficiente debe poseer y un buen gestor de proyectos es algo que todo proyecto necesita, luego la estimación ágil, aunque la proposición que abre esta sección fuese cierta, no introduce ninguna exigencia nueva en nuestros proyecto: siempre necesitamos un buen moderador, a ser posible varios.
"Arroja mejores resultados mientras más expertos "verdaderos" sean sus participantes. Si no son expertos…"
No es cierto que la estimación de solo expertos sea mejor. Esto sería cierto si los expertos fuesen quienes realizasen luego la implementación . Es evidente que quien va a implementar una requisito es quien debe estimarlo. Esto es una máxima en estimación. La motivación es evidente, solo quien va a realizar algo puede estimarlo. Seguro que Miguel Induráin estimaría, como ciclista experto que es, que puede subir el Tourmalet en un determinado tiempo y seguro obtendría una buena estimación. Pero si él estima y soy yo quien sube sin duda se va a equivocar, por experto que sea.
En los proyectos de software, rara vez se conoce con certeza quien finalmente implementará un requisito, por eso tenemos que tender a dar voz a cuantos más implicados mejor, idealmente a todo el equipo. A menudo la gente más inexperta vislumbra incertidumbres o dificultades que los expertos tendemos a olvidar. Introducir gente menos experta en el proceso de estimación es una manera de asegurarte de que las estimaciones son validas en un espectro más amplio de situaciones no solo cuando contamos con desarrolladores expertos.
En cualquier caso, es necesario que todos los desarrolladores, expertos o no, puedan asumir las estimaciones como suyas. Es una cuestión de motivación. Si un desarrollador no asume una estimación como realista no trata de cumplirla. Steve McConnell habla de las estimaciones percibidas como no realistas como uno de los principales factores que dañan la motivación. La manera de asegurarte que las estimaciones se perciben como realista es basarlas en el consenso y construir las estimaciones con la participación de todos los implicados. Mi motivación para cumplir una estimación que yo acepte, en la que participe y a la que me comprometí es alta, mi motivación para cumplir una estimación que mi jefe acepto, en la que yo no participé y para la que él se comprometió seguro no va a ser tanta. En Peopleware, biblia de la gestión de proyectos con más de 25 años, se describe como la motivación es el principal factor impulsor de los proyectos de software.
En cualquier caso, desde un punto de vista de gestión de equipos de trabajo, es sano que todo el mundo tenga voz en algo tan importante como la estimación.