viernes, 15 de noviembre de 2013

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




Patrones para planificación y seguimiento ágil

Una cuestión muy importante para el éxito de una implantación de prácticas ágiles es la configuración de prácticas de planificación y seguimiento para cada uno de los productos o servicios con los que se trabaja. Esto es especialmente más desafiante en contextos multiproyecto en los cuales el o los equipos están encargados de varios productos y/o servicios a la vez (ver Agilismo en contextos multiproyecto; Parte I y Parte II, y Multi-kanban). En este post recomendaré algunas alternativas para llevar a cabo la planificación y seguimiento de proyectos adaptadas a las necesidades específicas del producto o servicio. Nuestro enfoque en cuanto a prácticas es integrador en el sentido que incluye prácticas de los métodos ágiles más populares (Kanban, Lean Software Development, Scrum y Extreme Programming) y nuestra propuesta de patrones para planificación y seguimiento está refinada en base a experimentación y aplicación en proyectos industriales, contando además con un soporte explícito en nuestra herramienta Tune-up.

La configuración de planificación y seguimiento debe considerar la situación actual del producto o servicio, para conseguir un balance entre lo que sería el ideal y los desafíos que podría plantear el cambio hacia ese ideal. En muchas ocasiones lo más recomendable es iniciar una evolución más que un cambio radical que pueda crear ruido e incluso rechazo, particularmente para productos o servicios que son claves para el negocio.

Una práctica básica indiscutible en cualquier implantación ágil es la visualización de todo el trabajo no terminado mediante un tablero kanban. Así pues, un tablero kanban es el mecanismo básico para el seguimiento del trabajo. Ojo que con esto no estoy refiriéndome a usar el Método Kanban, sino solo el tablero que ofrece una mecánica para el flujo y visibilidad del trabajo. Existe bastante confusión respecto del uso de un tablero kanban, el cual no es exclusivo del Método Kanban, y además, es necesario en Scrum o XP porque en estos métodos no se ofrece un equivalente para visualizar el trabajo del equipo (ver ¿Kanban o Scrum?: that is not the question).

Una vez explicado el papel del tablero kanban, el resto de aspectos que podemos considerar para la configuración de planificación y seguimiento de cada producto/servicio son los siguientes:
  1. Agrupación (o no) del trabajo en sprints
  2. Gestión del esfuerzo
  3. Proceso centrado en Pruebas de Aceptación
  4. Líneas de trabajo en un mismo producto/servicio
Agrupación (o no) del trabajo en sprints
  • No usar sprints. Si la demanda del trabajo no es planificable (no sabemos qué trabajo ni cuando nos va a llegar) y/o no tenemos compromisos estrictos de plazos o alcance con el cliente, esta podría ser la mejor opción. Esta alternativa está cercana a la propuesta del Método Kanban, según la cual debemos centrarnos en generar un buen flujo de trabajo terminado, haciendo entregas muy frecuentes. Esta alternativa es particularmente adecuada para trabajo de mantenimiento continuo o solución de incidencias.
  • Sprints flexibles. Si no se tienen compomisos estrictos con el cliente pero sí que se tiene la posibilidad de acordar paquetes de trabajo para ser entregados en una cierta fecha, puede ser interesante utilizar sprints para evitar repetir muy continuamente las actividades de arranque y cierre de versión (que por ejemplo, incluyen en el cierre el pasar pruebas de regresión, despliegue, actualización de ayuda, etc.). El "Continuous Delivery" tiene ese desafío, es decir, contar con una buena infraestructura que evite una penalización en esfuerzo en dichas actividades de arranque y cierre de versión. Los ítems incluidos en el sprint, por no existir un compromiso estricto de alcance y plazo con el cliente, podrían no estar estimados y en caso de no poder terminarse en la fecha de fin del sprint simplemente se pasarían al siguiente sprint (reevaluando su prioridad respecto de los ítems contenidos en el Backlog en ese momento).
  • Sprints rígidos. Si la demanda es planificable y además el compromiso con el cliente en cuanto alcance y plazo del sprint es más bien rígido, lo recomendable es tener una noción de la capacidad del equipo y realizar estimaciones del trabajo que se incluye en el sprint para asegurar que sea consistente el esfuerzo asociado respecto de dicha capacidad. 

Gestión del esfuerzo
En este aspecto me refiero a cómo medir el esfuerzo estimado, invertido y restante en realizar un ítem de trabajo.
  • Esfuerzo estimado. Primero hay que insistir en que si no hay un compromiso estricto con el cliente en cuanto a alcance y plazos la estimación puede ser opcional. El esfuerzo estimado puede medirse en Horas Ideales o en Puntos (o cualquier otra medida de tamaño). Las Horas Ideales (horas de trabajo sin interrupciones) miden el esfuerzo asociado a actividades específicas, por ejemplo, horas ideales de programación. Los Puntos en cambio miden el esfuerzo global asociado al tamaño de un ítem de trabajo. Ver "Estimación en un proyecto ágil": Parte I y Parte II.
  • Esfuerzo invertido. Son las horas reales invertidas en actividades asociadas a un ítem de trabajo, por ejemplo, cuántas horas de programación o testeo llevamos invertidas en un ítem. No tiene mucho sentido plantearse el registrar Puntos invertidos en un ítem, pues no es una medida asociada a una actividad y estaríamos forzándo a darles una interpretación de unidad de tiempo, lo cual justamente es lo que los Puntos no son.
  • Esfuerzo restante. Se puede medir como la diferencia entre horas estimadas (y actualizadas cuando corresponda) y horas invertidas. En el caso de Puntos son los punto correspondientes a ítems de trabajo no terminados, es decir, no se haría un cálculo parcial del trabajo que esté comenzado pero no terminado.También es una alternativa el registrar directamente el esfuerzo restante, es decir, para cada ítem iniciado registrar períódicamente cuántas horas ideales restan en una actividad para finalizarla.
Según lo anterior, algunas alternativas para gestión de esfuerzo serían:
  • No gestionar esfuerzo.
  • Usar Puntos solo como esfuerzo estimado y calcular los puntos restantes como puntos de ítems no terminados.
  • Registrar solo el esfuerzo invertido.
  • Registrar solo el esfuerzo restante en horas ideales.
  • Registrar el esfuerzo estimado y el esfuerzo invertido. El esfuerzo restante puede calcularse como la diferencia entre el esfuerzo estimado y el invertido.  
Proceso centrado en pruebas de aceptación
Esta es una práctica que me llamó la atención cuando dí mis primeros pasos en el agilismo con Extreme programming. Si bien no se trata de una exclusividad del enfoque ágil, pues las pruebas de aceptación están presente también en las metodologías tradicionales, es indudable que el protagonismo es mucho más marcado en el contexto ágil. Además, la diferencia fundamental es que en el ámbito ágil el proceso debería estar dirigido por las pruebas de aceptación. Ojo!, no estoy hablando de TDD, el cual está orientado a pruebas unitarias. En un enfoque ágil, las pruebas de aceptación se escriben en el momento de definir o redefinir el ítem de trabajo, es decir, son en sí mismas la especificación detallada del ítem, son el criterio de éxito establecido para la implementación. Desgraciadamente, esta práctica no es sencilla de implantar, requiere formación y experiencia, además de cambios en la forma de trabajo pues o bien el tester (de testeo de aceptación) trabaja codo a codo con el que establece los requisitos (quien define/analiza el ítem de trabajo) o es este último quien directamente especifica las pruebas de aceptación del ítem (tarea que tradicionalmente realiza el encargado de testeo).

Pues bien, de cara a la planificación y seguimiento ágil, el tener un proceso centrado en pruebas de aceptación ofrece las siguientes ventajas:
  • Para la planificación las pruebas de aceptación son una excelente forma de negociar y establecer desarrollo incremental de ítems de trabajo "grandes". Así, en lugar de particionarlos, se pueden desarrollar en ítems sucesivos que incrementan la funcionalidad dando soporte a más pruebas de aceptación.
  • Para el seguimiento las pruebas de aceptación de un ítem de trabajo y su estado nos ofrecen un detalle adicional del estado de avance del trabajo en un ítem. Por ejemplo, podríamos saber del total de pruebas identificadas cuantas están ya definidas (condiciones, pasos y resultado) y cuántas estan ya diseñadas (instanciaciones concretas de datos para las condiciones, pasos y  resultado), o por otra parte, podríamos saber cuántas pruebas están implementadas OK y cuántas tienen detectado algún fallo y están KO.   
También hay que destacar que para conseguir estas ventajas no se requiere que las pruebas de aceptación estén automatizadas. La automatización o no de las pruebas de aceptación ofrece ventajas, desafíos y consideraciones de rentabilidad adicionales a lo que es el tema de este post :-).

Líneas de trabajo en un mismo producto
Una situación bastante habitual en productos grandes y/o con un mantenimiento continuo es tener varias líneas de trabajo en paralelo sobre el mismo producto. Por ejemplo, trabajo asociado a módulos específicos del producto los cuales llevan probablemente su propio versionado, o trabajo de grandes cambios o nuevos módulos, o trabajo de mantenimiento asociados a corrección de fallos o pequeñas mejoras que debe entregarse a muy corto plazo. De cara a la planificación y seguimiento esta situación incluye varios desafíos. Si lo tratamos como un solo producto, podríamos caer en hecho de someter a una única configuración de planificación y seguimiento a todas las líneas de trabajo, por ejemplo, trabajando con sprints, cada sprint contendría trabajo de las diferentes líneas y se tendría que sincronizar de alguna forma al cierre del sprint. Si gestionáramos cada línea de trabajo como un producto separado tendríamos la libertad para definir la configuración de planificación y seguimiento para cada línea de trabajo, por ejemplo, si se trabaja con sprints, cada línea de trabajo tendría sus propios sprints. En cualquiera de los casos deberíamos asegurar que los cambios se gestionen y visualicen en conjunto para detectar conflictos o dependencias entre las diferentes líneas pues de todas formas estaríamos trabajando sobre el mismo producto. Para conocer más detalles respecto de esta situación y alternativas asociadas a cómo abordarla ver "Gestión ágil de productos que tienen varias líneas de trabajo".

Conclusiones
Los patrones de planificación y seguimiento ágil surgen de la elección de estrategias en cada uno de los 4 aspectos planteados. A continuación se muestran algunos patrones de ejemplo:

Producto A: Usar sprints flexibles, registrar en horas esfuerzo invertido (sin hacer estimaciones), no trabajar centrado en pruebas de aceptación, y tratar el desarrollo y el mantenimiento urgente dentro del mismo producto y sprint pero pasando a producción versiones asociadas a mantenimientos urgentes.

Producto B: No usar sprints, registrar el esfuerzo en Puntos (no registrar el esfuerzo invertido) y usarlo solo como un dato descriptivo para reconocer en el Backlog ítems pequeños o grandes, trabajar centrado en las pruebas de aceptación, el producto ya está en producción y mientras no aparecen grandes cambios, todo el mantenimiento se hace de forma contínua en la medida que va recibiéndose y priorizándose.

Producto C: Un producto grande con diferentes módulos abordados por diferentes equipos. Cada equipo-módulo ajusta su configuración de planificación y seguimiento, pero todos los equipos comparten la información de la estructura del producto para poder detectar conflictos y dependencias respecto del trabajo que realiza otro equipo en otro módulo. Por ejemplo el equipo E1 trabaja en el módulo M1 con sprints, registrando tiempo estimado e invertido en horas (y disponiendo del tiempo restante también en horas), y trabaja centrado en pruebas de aceptación. El Equipo E2 trabaja en el módulo M2 (un nuevo módulo para el cual hay que desarrollar inicialmente un prototipo), no utiliza sprints, no hace estimaciones ni registros de tiempo invertido, y no trabaja centrado en pruebas de aceptación.

Obviamente de acuerdo al patrón seleccionado, la planificación y las formas de seguimiento serán diferentes. Por ejemplo, si no se tienen sprints no tiene sentido preguntarse si vamos a cumplir con una fecha de entrega de un paquete de trabajo, sin embargo, esto no debería ser un problema puesto que justamente lo que quieres darle al cliente es una solución lo más inmediata posible del problema que te está reportando en el momento. Si no se estima, no se podrá disponer de una gráfica Burndown o de trabajo Finalizado versus No Finalizado. Si se utilizan Puntos podrás tener una gráfica Burndown y una gráfica de relación entre ítems Finalizados/No Finalizados, pero en ambos casos solo se contabilizará un cambio cuando el ítem esté terminado, mientras los ítems siguen sin finalizarse ambas gráficas no muestran cambios. Si se registran estimaciones en horas y esfuerzo invertido también en horas, automáticamente puede calcularse el trabajo restante de la gráfica Burndown y las proporciones de trabajo finalizado y no finalizado. Si se trabaja centrado en pruebas de aceptación podrá adicionalmente conocerse el estado de especificación de las pruebas (identificadas, definidas o diseñadas) y su estado de ejecución (OK o KO).

Ignorar la configuración de la planificación y seguimiento de cada producto (o de sus líneas de trabajo) puede conllevar situaciones de proceso en las cuales se hace más trabajo o menos trabajo del que realmente se requiere para ser eficaz en cuanto al éxito del equipo en el producto, o simplemente incomodidades para abordar el trabajo pues no se ajusta a las necesidades del contexto del producto.  

Las variantes para establecer los patrones de planificación y seguimiento ágil los hemos ido refinando con nuestra experiencia en múltiples proyectos de implantación de nuestro enfoque Tune-up, y se ofrecen en nuestra herramienta como sencillas opciones de configuración de cada producto/servicio, incluso es posible cambiar en cualquier momento de una configuración a otra si se considera conveniente.


Patricio Letelier