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 una y otra vez). Así pues, recomiendo que los flecos siempre se representen con nuevos ítems dando por terminado el ítem original o los flecos ya abordados. Además, si los flecos están representados como ítems por separado pueden competir individualmente por prioridad con otros ítems, es decir, los flecos puede que ya no sean prioritarios cuando los contrastamos con todo el trabajo pendiente. Así pues, los flecos deberían tener 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 ya entregados, y más aún si esos requisitos tienen cierto é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, pero a partir del término del primer Sprint ya podríamos estar detectando flecos. Estos flecos aparecerán como ítems en el Backlog y según su prioridad se irán incorporando en los siguientes Sprints como ítems de mejora o de corrección de fallo. Así pues, la implementación de nuevos requisitos no se concentra toda en una fase inicial, ni tampoco la implementación de los flecos tiene que ser relegada a una fase más hacia el final.
Un enfoque ágil promueve la aparición temprana de flecos y su gestión como nuevos ítems que deben ser priorizados. 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 los flecos se detectan y gestionan tempranamente.
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 gestionarlos conlleva prestar atención continuamente al 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
