viernes, 7 de septiembre de 2012

Estimación en un proyecto ágil, Parte II: Algunas diferencias respecto de estimación tradicional

¿Qué diferencias puede tener la estimación en un contexto ágil respecto de uno tradicional?. Las estimaciones son protagonistas al  evaluar la factibilidad de un proyecto, al establecer su planificación y para realizar su seguimiento. En un enfoque ágil dichas actividades también están presentes pero con características especiales que obligan a replantearse cómo hacer las estimaciones e incluso si vale la pena hacerlas. Este post es la continuación de "Estimación en un proyecto ágil: Parte I".

Un primer punto a destacar es que en un contexto ágil las unidades de trabajo deberían ser elementos de valor de cara al cliente. Es decir, son cambios en el producto o servicio que recibe el cliente, aunque el equipo pueda descomponer una unidad de trabajo en tareas técnicas, lo relevante en términos de satisfacción del cliente es la entrega de la unidad de trabajo como un todo y desde su perspectiva. Además, una unidad de trabajo debe tener una granuralidad consecuente con las entregas frecuentes que se esperan realizar. A modo orientativo si una unidad de trabajo es demasiado grande/compleja para terminarla en una semana (considerando la capacidad del equipo) habría que descomponerla en partes o incrementos que permitan hacer una entrega parcial, pero dichas partes o incrementos deberían ser establecidos desde la perspectiva del cliente, es decir, apreciables por él como una entrega parcial.

Otro punto destacable es que las estimaciones en sí mismas no aportan valor al cliente, con lo cual de entrada podrían ser prescindibles :-). No estimar es una opción válida en proyectos con circunstancias favorables para el agilismo. Por ejemplo, cuando existe una estrecha colaboración y complicidad con el cliente y él está satisfecho consiguiendo continuamente funcionalidad, o cuando la planificación es a corto plazo, lo que en extremo podría ser planificar solo el sprint actual y quizás el próximo, o simplemente no usar sprints y sólo  trabajar en términos de generación de flujo con entregas frecuentes pero no planificadas a priori. Es decir, en un contexto muy flexibile, con constante posibilidad de negociación del alcance y plazos, la estimación podría ser prescindible. Desgraciadamente, aunque dichas condiciones favorables serían ideales para una aplicación del agilismo, no es usual, especialmente por cuestiones contractuales, evitar adquirir compromisos a más largo plazo y bajo condiciones poco flexibles. Pero, de todas formas, aunque fuera posible prescindir de las estimaciones, siempre puede rentabilizarse el esfuerzo invertido en ellas, por el simple hecho de que una estimación conlleva la definición, al menos preliminar, del trabajo que se va a realizar, lo cual es importante en ciertas unidades de trabajo que por envergadura o complejidad requieren una evaluación preliminar que nos advierta del desafío que involucran. 

Otra dimensión de la estimación es su nivel de precisión (esperada) el cual está en correlación con el nivel de definición de la unidad de trabajo, el cual se va haciendo más detallado mientras más nos acercamos al término de su implantación :-). Ya en la identificación de una unidad de trabajo es interesante poder reconocer su tamaño. Aquí es donde usar Puntos (posiblemente con una escala de Fibonacci) es lo más adecuado por su sencillez. Según se requiera, esta estimación preliminar puede ser consensuada por el equipo, utilizando por ejemplo Planning Poker. Si el equipo mantiene un registro de su capacidad, también en Puntos, dispondría con ello de un mecanismo probablemente suficiente para una primera evaluación de factibilidad y/o planificación preliminar o global del proyecto, todo ello con muy poco esfuerzo y de forma temprana. Sin embargo, desde el punto de vista del seguimiento diario del trabajo restante (por ejemplo, en una gráfica Burndown) los Puntos deberían actualizarse según la pregunta ¿cuánto esfuerzo nos queda para terminar cada unidad de trabajo?, responder esto en Puntos ya no resulta tan directo, como tampoco el hacer un ajuste en la estimación cuando se detecta que se requerirá más o menos que el esfuerzo previsto. Si se trabaja con Puntos deberíamos esperar a que el trabajo termine para descontar los Puntos que se estimaron para él. Además, una estimación en Puntos normalmente se hace como una valoración global del esfuerzo de implementación de la unidad de trabajo, sin distinguir los esfuerzos particulares asociados a cada actividad que debe realizarse sobre ella, aunque podríamos tener una estimación para cada actividad que pensamos llevar a cabo en la unidad de trabajo, por ejemplo, estimar el esfuerzo de analizarla, de implementarla y de probarla, etc., pero no lo recomendaría. Así pues, al trabajar con Puntos se entiende que se trata de una estimación a nivel global, es decir, lo que se pretende es dimensionar la unidad de trabajo como un todo, no a nivel de actividad. Sin embargo, si durante el seguimiento queremos conocer el estado de avance en términos de esfuerzo restante, normalmente éste esfuerzo lo necesitaríamos a nivel de actividad, y no tiene mucho sentido preguntarse cuántos Puntos le restan a una actividad, menos si la estimación inicial se hizo a nivel global. Finalmente, los Puntos son una medida relativa en el marco de un equipo, lo cual impediría obtener estadísticas de esfuerzo y capacidad más allá del ámbito de cada equipo. Paradójicamente y confirmando estos inconvenientes asociados a trabajar con Puntos, he leído en repetidas ocasiones comentarios recomendando establecer equivalencias entre un Punto de Historia de Usuario o de Tarea con semanas, días u horas, intentando hacer más intuitivo el concepto de Punto :-).

Por los inconvenientes indicados, cuando es necesario un seguimiento más detallado (insisto que depende del contexto, y puede que NO se requiera ese detalle), de forma alternativa o complementaria se puede  usar Horas Ideales (es decir, una estimación suponiendo que el trabajo se hiciera en horas continuas, sin considerar pausas ni interrupciones). Normalmente cuando establecemos, por ejemplo, que una unidad de trabajo tomaría 10 horas de programación, lo estaríamos haciendo de forma intuitiva y fácil si pensamos en el tiempo que se invertiría si se trabajara de forma continua y sin interrupciones. Luego en la práctica ese trabajo podría cronológicamente llevarse a cabo, por ejemplo, durante una semana puesto que desde cuando se empiece podría tener interrupciones, es decir, probablemente no se llegará a trabajar continuamente 10 horas en dicha actividad, pero con respecto a comparar la Capacidad disponible con el Esfuerzo Estimado  habremos conseguido nuestro propósito. Por otra parte, cuando el programador responsable reflexione respecto al esfuerzo restante para acabar la programación de la unidad de trabajo, le será sencillo volver a establecer las horas ideales que estima que le restan de trabajo,o si es necesario hacer ajustes a dicha estimación. Según lo anterior, es muy importante hacer la diferencia entre la estimación (en horas ideales) y la previsión o compromiso de término de una unidad de trabajo, esto último dependerá de la previsión de disponibilidad de tiempo que se tenga para realizar el trabajo y las interrupciones que podrían ocurrir. Esto es extensible al ámbito del sprint, release o proyecto como un todo, es decir, por una parte existe una estimación de esfuerzo y por otra la capacidad que se prevé que el equipo puede dedicar en el período de tiempo hasta el plazo de entrega.

Sigamos entonces comentando la estrategia de estimación usando Horas Ideales y a nivel de actividad realizada sobre la unidad de trabajo (vuelvo a insistir, esto sería aplicable solo cuando este esfuerzo dedicado a estimación se justifique). Dichas actividades corresponden al workflow que sigue la unidad de trabajo, es decir, en términos de un tablero kanban, dichas actividades son las columnas por las cuales pasa la unidad de trabajo (representada por un post-it). ¿Interesa estimar todas las actividades por las cuales pasará la unidad de trabajo?. Categóricamente NO, primero porque hay algunas actividades para las cuales a priori sería difícil prever cuánto esfuerzo requerirán (por ejemplo, cuánto se tardará en definir una unidad de trabajo sin todavía conocer más detalles de ella, detalles que se irían descubriendo durante esa misma actividad), además, habrá actividades que consumen un esfuerzo despreciable que no merece la pena estimar. Por otra parte, siempre podemos separar las actividades en dos grupos, las de preparación que normalmente deberían realizarse mientras la unidad de trabajo está en el Backlog, y las de implementación, aquellas actividades que se realizarán en el Sprint. Como el propósito es establecer Sprints que supongan un esfuerzo que no supere la Capacidad del equipo, las actividades interesantes para ser estimadas y así establecer el esfuerzo asociado al Sprint serán aquellas que se realizan durante el período del Sprint. Más aún, NO es necesario/rentable realizar estimaciones para todas las actividades de implementación. La TOC (Theory of Constraints, propuesta por Goldratt) sugiere que para mejorar un proceso de producción hay que poner atención y centrarse en mejorar las actividades que constituyen una limitación para el sistema (aquellas que pueden constituir un cuello de botella). Así pues si identificamos una actividad que por escasez de capacidad para realizarla (u otros motivos) es un posible cuello de botella, dicha actividad debería ser aquella para la cual se realice una estimación y para la cual correspondientemente se tenga un registro de la capacidad del equipo. En desarrollo de software, los cuellos de botella en un Sprint podrían darse en algunas actividades asociadas a programación y/o a testeo. Así pues, por ejemplo, si la capacidad en horas ideales de programación por semana para un equipo de desarrollo fuera de 200 horas, cuando se esté planteando un próximo Sprint de 3 semanas, la suma de las estimaciones de esfuerzo de programación para las unidades de trabajo asignadas al Sprint no debería superar las 600 horas (ni tampoco ser mucho menor que ello).

La estrategia de gestión del esfuerzo y en particular la asociada a estimación  debe ser evaluada para cada producto y/o servicio, es decir, un mismo equipo se podrían aplicar diferentes estrategias a los distintos productos o servicios con los cuales trabaja.

En nuestra metodología y herramienta Tune-up realizamos dicha configuración de la estrategia de estimación para cada producto o servicio. Sin embargo, de forma integrada se puede realizar el seguimiento de todos los sprints (incluyendo también el seguimiento para aquellos productos o servicios que no requieren sprints o estimación). Aunque difieran en cuanto a la estrategia de estimación, cada producto o servicio dispondrá de sus correspondientes mecanismos para el seguimiento, pudiendo corresponder a una implantación pura del método Kanban, una más cercana a Scrum o incluso una aproximación mixta.

Para tener una visión más global de lo que significa Planificación y Estimación en un contexto ágil recomiendo la lectura de Agile Estimating and Planing de Mike Cohn (aunque su contenido no esté 100%  alineado con mis comentarios en este post :-).