Gestión ágil de productos que tienen varias líneas de trabajo

Cuando trabajamos con un producto nuevo y de gran envergadura o con un producto que tiene un intenso mantenimiento, y se dispone quizás de un equipo numeroso, puede ser conveniente organizar el trabajo sobre el producto en diferentes líneas, y para cada una de ellas realizar una gestión adaptada a sus necesidades. Si bien esto podría considerarse un tema "avanzado", o "raro" :-) para la literatura ágil habitual, es una situación bastante frecuente: un producto que está ya en producción y a la vez tiene mantenimiento muy activo. Esto es usual en empresas que comercializan un producto o unos pocos. Si el producto es de gran envergadura puede incluso ser conveniente formar sub-equipos por áreas del producto constituyendo cada una de esas áreas una línea de trabajo. Otros tipos usuales de líneas de trabajo sobre un mismo producto son: trabajo de desarrollo planificado (nuevos módulos o grandes remodelaciones o cambios no urgentes), trabajo de desarrollo urgente (correcciones de fallos o pequeñas mejoras), soporte (instalación y actualizaciones, atención al cliente, etc). Cada línea de trabajo puede tener sus particularidades en cuando a gestión del trabajo, acuerdos de servicio con el cliente, desarrolladores involucrados, etc. Por esto es conveniente reconocer estas líneas de trabajo y abordarlas con una estrategia adaptada a sus necesidades.

Esta situación multi-línea de trabajo en un mismo producto tiene similitudes con una situación multi-proyecto (o mejor dicho "multi-producto"), ambas comparten desafíos en lo que respecta a gestión y visualización integrada de la información. Recomiendo ver "Agilismo en contextos multiproyecto": Parte I y Parte II,  Multi-kanban, y "Patrones para planificación y seguimiento ágil").

Sea cual sea la estrategia para abordar una situación de producto con varias líneas de trabajo, la clave en esta situación es que se trata del mismo producto, con lo cual es normal que existan dependencias e incluso conflictos entre los cambios que pueda estar sufriendo el producto en cada línea de trabajo. Todos los participantes deberían poder fácilmente visualizar un Backlog global del producto y a la vez distinguir el Bakclog del trabajo correspondiente a cada línea de trabajo. Así, los participantes en cada línea de trabajo del producto podrán anticipar dichas interferencias y coordinar su trabajo. Veamos un ejemplo del desafío de gestión que presenta una situación multi-línea de trabajo sobre un mismo producto. Supongamos que tenemos al producto ACME con tres líneas de trabajo: Desarrollo Planificado, Desarrollo Urgente y Proyecto Nuevo Módulo. Además, cada línea está encargada a un equipo diferente. La siguiente figura ilusta la situación planteada.

En nuestro enfoque para la gestión ágil de proyectos, llamado TUNE-UP Process, la clave es tener una Estructura del Producto (y para ello usamos un grafo representado en un treeview) que sirva de marco para contextualizar todos los cambios del producto, provenientes de todas las líneas de trabajo. Así, cuando en una línea de trabajo se pretende realizar un cambio en un elemento del producto, se puede observar fácilmente qué cambios se han realizado, se están realizando y están pendientes de realizar por todas las líneas de trabajo en dicho elemento. Esto se ilustra en la siguiente figura, en la cual se observa cómo el nodo X está afectado por ítems de trabajo de Desarrollo Urgente y de Desarrollo Planificado, así como el nodo Y está afectado por ítems de trabajo de las tres líneas de trabajo.

Además de contar con la Estructura del Producto como mecanismo para ayudar a coordinar diferentes líneas de trabajo en un mismo producto, hay que decidir la estrategia de planificación y seguimiento para cada una de ellas (ver Patrones de planificación y seguimiento ágil) . Siguiendo con el ejemplo planteado, supongamos que para Desarrollo Urgente no se trabajará con sprints (puesto que la demanda no es planificable y se quiere simplemente generar un buen flujo de trabajo terminado). En cambio en Desarrollo Planificado y en el Proyecto Nuevo Módulo se trabajará con sprints. Cada línea de trabajo contaría con su propio tablero kanban y su backlog (podría, con algunos inconveniente, ser el mismo backlog y tablero kanban pero diferenciando de alguna forma los ítems de cada línea de trabajo). Esto se ilustra en la siguiente figura:

Llegado a este punto resulta evidente que las decisiones que se tomen deben ser soportadas con una correspondiente política para control de versiones, usando ramas, etiquetado u otros mecanismos que se acuerden.

En cuanto a la generación de versiones y planificación con sprints, la alternativa más sencilla sería que todas las líneas de trabajo coincidan en inicio y fin de cada sprint. Desafortunadamente, es difícil conseguir este grado de sincronización. Además, no sería recomendable (o posible) obligar a una línea que no debería trabajar con sprints (como en nuestro ejemplo Desarrollo Urgente) a postergar la generación de una versión para coincidir con el la fecha de término acordada para todas las líneas de trabajo.

Otra alternativa es que cuando se genere una nueva versión (por necesidad de cualquiera de las líneas), se decida qué trabajo de cada línea se quiere aprovechar de sacar en dicha versión. En esta alternativa el trabajo en marcha de las otras líneas que no se incluya en la versión se pasaría como trabajo candidato en la siguiente versión del producto (o siguiente sprint en el caso de que la línea de trabajo utilice sprints). Es decir, en esta alternativa las versiones pueden incluir trabajo de varias líneas de trabajo, pero los sprints se van modificando continuamente. Este es precisamente el inconveniente en esta alternativa para las líneas que trabajan con sprints, pues deberían redefinir su sprint actual cada vez que otra línea saca una versión o bien deberían llevar un versionado en paralelo aislándose de las versiones generadas mientras no interese incluir cambios. En la siguiente figura se ilustra esta alternativa, en cada versión se puede incluir trabajo terminado de varias líneas de trabajo y la frecuencia de generación de versiones no tiende a regularizarse:

Otra alternativa sería que cada línea de trabajo tenga su versionado, fechas de inicio y de fin de sprint, todo de forma independiente para cada línea. Así sería posible que las líneas que trabajan con sprints puedan mantener su duración constante.

Existen otras alternativas que mezclan los criterios antes señalados y detalles de versionado que harían demasiado extenso este post. Pienso que con lo expuesto el lector ya puede hacerse una idea de las variantes que deberían considerarse para conseguir una estrategia ajustada a las necesidades de cada línea se trabajo en el producto.

Otro aspecto a tener en cuenta pero que también excede el alcance de este post es la organización de los equipos, particularmente los roles de Product Owner y de Scrum Master (usando por ejemplo los roles de Scrum). Lo ideal es que pudiésemos abordar todo el trabajo con solo un PO y un SM para reducir los esfuerzos de coordinación, de no ser así, no queda más remedio que coordinar POs y SMs en caso de tener varios. Esto en en ámbito de Scrum se conoce como "Scrum de Scrums" y se refiere a los mecanismos para escalar Scrums en equipos grandes (más de 10 personas). Este post se ha centrado más en la importancia que tiene el establecer una planificación y seguimiento ajustada a las necesidades de cada línea de trabajo, aún tratándose del mismo producto, e independientemente de si son equipos diferentes en cada línea de trabajo o es mismo equipo para todas ellas.

En la herramienta que apoya nuestro enfoque TUNE-UP Process se ofrecen funcionalidades específicas para soportar las alternativas comentadas en este post, permitiendo a la vez tener una visión integrada del trabajo asociado a un producto con varias líneas de trabajo, junto también con la información de otros productos que también deban gestionarse en el mismo ámbito de trabajo.

Finalmente, en el post "Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega" comento respecto del caso particular en el cual para un mismo producto, a partir de su primera entrega surgen tres líneas de trabajo: Desarrollo, Mantenimiento y Soporte.


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com