jueves, 25 de mayo de 2017

"Flecos" de implementación y gestión ágil de proyectos

Para implantar métodos que resulten eficaces hay que entender la naturaleza de la construcción de software. Teóricamente, desde el punto de vista técnico, si disponemos de cierto tiempo podremos preparar (definir, diseñar y estimar) adecuadamente el trabajo que se va a implementar (programar y probar), de tal forma que una vez hecha dicha implementación ésta sea totalmente satisfactoria, que no se requiera trabajar más en ella. Sin embargo, por una parte, la certeza en cuanto a corrección y completitud de dicha preparación no suele ser muy alta, y por otra, cuando el cliente ya puede interactuar con algo tangible suele desear algunas mejoras. Esto hacer que de unos requisitos ya implementados aparezcan "Flecos"; mejoras (o incluso fallos) que corresponden a una continuación del trabajo iniciado por un ítem (Historia de Usuario) que ya dábamos por terminado. Aunque los flecos incomoden, el objetivo no debería ser el conseguir que no aparezcan flecos, sino gestionarlos adecuadamente. Debemos asumir que una estrategia puramente ágil, centrada en el desarrollo incremental, generará flecos. Esta inconveniencia se amortiza con creces en comparación con una estrategia tradicional. Solo desde el punto de vista de la especificación ya estamos evitando el "Análisis-Parálisis", un problema mucho más grave (lectura recomendada: ¿Análisis-Parálisis o No Análisis?. MVP la respuesta razonable).

Para gestionar dichos flecos una opción sería continuar (o reabrir) el mismo ítem original para extenderlo con los flecos que se van detectando. Esta alternativa no es recomendable porque no permite fácilmente distinguir entre lo ya realizado y lo pendiente (asociado a los flecos). Además, psicológicamente no es bueno que se trabaje en algo de forma muy prolongada sin terminarlo (o reabriéndolo). Por ultimo, los flecos si están separados pueden también competir individualmente por prioridad con otros ítems, es decir, los flecos puede que no sean prioritarios cuando los contrastamos con todo el trabajo pendiente. Así pues, los flecos deberían representarse como nuevos ítems que tengan una trazabilidad del tipo "es continuación de" o similar con respecto al ítem original.

Esta naturaleza imperfecta pone en jaque a una mentalidad tradicional para construir software, en la cual, un ítem se prepara y se implementa con la idea de ser terminado al primer intento, sin flecos :-). Si desde una perspectiva ágil además añadimos mucha interacción con el cliente, entregas frecuentes, reuniones de revisión, desarrollo incremental, etc., se desata tempranamente la identificación de flecos, especialmente cuando se trata de requisitos implementados y entregados, y que tienen éxito entre los usuarios (por ser muy apreciados y/o porque se utilizan con mucha frecuencia).

En la siguiente figura se ilustra cómo en un proceso iterativo e incremental el trabajo se va preparando e implementando incrementalmente. Obviamente en un desarrollo de un nuevo producto hay un breve período inicial de establecimiento del Backlog con la identificación de ítems y la preparación de los que se implementarán en el primer Sprint. A partir de allí la preparación se repite para cada siguiente Sprint, y a partir del segundo Sprint ya comenzamos a detectar flecos que conllevarán la identificación y posible implantación de los correspondientes ítems que los representen. Así pues, la implementación de nuevos requisitos no se concentra toda en una fase inicial, ni la implementación de los flecos en una fase más hacia el final.



Así pues, un enfoque ágil promueve la aparición temprana de flecos. Esto que parecería algo negativo (y lo es en un sentido tradicional) pues representa cambios no previstos, pero resulta ser una gran ventaja ya que tempranamente se detectan y gestionan oportunamente.

Cuando afirmamos que con un enfoque ágil se gestionan mejor los cambios, en gran medida nos referimos a dicha identificación y gestión de los flecos de implementación (lectura recomendada: ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?). Obviamente los flecos y cambios en general nos incomodan, pero esto hay que valorarlo con una visión global del proyecto, ya que su detección y gestión tardía probablemente comprometería el éxito del proyecto. Más aún, el hecho que los flecos compitan con otros ítems pendientes ofrece la oportunidad para que el cliente discrimine entre lo esencial y lo prescindible de cada uno de los requisitos. El cliente podría ir interactuando con versiones parciales/incompletas pero tangibles (implementadas) del requisito, hasta el punto que considere que se ha alcanzado un MVP del requisito, lo cual dejaría espacio para la implementación de otros requisitos que de otra forma se habrían descartado por falta de capacidad o tiempo para implementarlos.

Asumir que existirán cambios y gestionarlo conlleva gestionar continuamente el alcance del proyecto  (lectura recomendada: Gestión del Alcance en un Proyecto Ágil ) y correspondientemente negociar con el cliente. Una medida preventiva para abordar un margen de cambios imprevistos es considerar un Buffer de Capacidad para proyectos ágiles.



Patricio Letelier