Líneas de trabajo

Una Línea de trabajo es básicamente un Product Owner más un Backlog y más un equipo de trabajo. El Producto Owner es el encargado de gestionar el contenido del Backlog y las prioridades de las UT incluidas en él (asignándoles un orden). El Product Owner debería ser el representante de las necesidades de toda la "parte cliente" que va a aprovechar el resultado del trabajo. El equipo es el conjunto de colaboradores con acceso a la Línea de trabajo y se encargan de procesar las UT definidas por el Product Owner siguiendo el orden establecido. Periódicamente la "parte cliente" recibe UT terminadas. La siguiente imagen ilustra los elementos básicos de una Línea de trabajo según lo explicado antes.  

En un determinado contexto podría bastar con este planteamiento para organizar el trabajo, es decir, una sola Línea de trabajo con todo el trabajo en un mismo Backlog, todo el personal disponible como un solo equipo, y solo un Product Owner representando a toda la "parte cliente". Sin embargo, la diversidad del trabajo conviene ser abordada con soluciones adaptadas al contexto específico del trabajo. Por ejemplo, separar el trabajo de diferentes productos o servicios (o agrupaciones de ellos por tipo), separar el trabajo solicitado por diferentes clientes (representados quizás por distintos Product Owners), separar por tipo de trabajo (Tipo de UT), separar el trabajo de cada equipos (Scrum recomienda equipos de no más de 9 integrantes), y especialmente, no mezclar trabajo que tenga diferentes necesidades de planificación y seguimiento, como se ilustrará más adelante. En la siguiente imagen se muestran diferentes Líneas de trabajo. Como se observa, algunas Líneas de trabajo podrían compartir Product Owner, un equipo podría encargarse de más de una Línea de trabajo, y una persona podría trabajar en varios equipos.

Relación entre línea de trabajo y Producto (o Servicio)

Veamos a continuación una situación frecuente en desarrollo de software que hace recomendable distinguir Líneas de trabajo debido distintas necesidades de planificación y seguimiento, incluso tratándose del trabajo asociado a un mismo producto. Supongamos que se está desarrollando el producto ACME. A partir de su primera entrega, es decir, desde el momento que hacemos una primera entrega a la "parte cliente" para que lo utilice, aparecen dos nuevas fuentes de trabajo para el producto; las solicitudes de mantenimiento (mejoras y fallos detectados en la entrega) y el soporte solicitado por los usuarios. Además, el producto podría no estar acabado y continuar su desarrollo con nuevas funcionalidades. La siguiente imagen ilustra esta situación en el producto ACME; antes de la primera entrega existe una Línea de trabajo, y a partir de la primera entrega se establecen 3 Líneas de trabajo en paralelo para el mismo producto.

 

Antes de la primera entrega probablemente el trabajo era "planificable", es decir, se conocía su alcance, se podía contrastar con la capacidad del equipo y con ello se podía establecer compromisos (como la fecha de la primera entrega). Si el trabajo no era de gran envergadura o los plazos no eran muy cortos, podría también bastar con tener un solo equipo (no más de 9 personas). Esta situación podría seguir siendo válida para el trabajo asociado a la continuación del desarrollo después de la primera entrega, el equipo original continuaría dedicado exclusivamente a desarrollar nuevas funcionalidades del producto. Pero ¿quién se encargaría de las dos nuevas Líneas de trabajo?, ¿son ellas también "planificables"?. Si es el mismo equipo original el encargado de las dos nuevas Líneas de trabajo, indudablemente verá reducida su Capacidad para continuar el desarrollo. Además, si el equipo está encargado de varias Líneas de trabajo debe establecerse su distribución de Capacidad y proporcionar pautas de priorización para atender cada una de las 3 Líneas de trabajo. Este problema no existiría si posterior a la primera entrega otros equipos se encargan de las nuevas líneas de Soporte y de Mantenimiento.

En el caso de Soporte, se suele tener un Help Desk especializado en esta función y encargándose del soporte de varios productos. Sin embargo, el trabajo que se atiende en Soporte mayoritariamente "no es planificable", es decir, no se puede conocer de antemano su alcance y normalmente en este contexto lo que se pretende es una rápida solución, es decir, un buen flujo continuo de trabajo terminado, probablemente sin necesidades de estimación y planificación, solo priorizando y ejecutando lo más rápidamente posible el trabajo.

El caso del trabajo de mantenimiento es lo que podríamos llamar "semi planificable" pues puede haber una parte del trabajo acumulada (alcance conocido) con lo cual se puede planificar, y otra por llegar en cualquier momento (por ejemplo, un fallo detectado) que puede ser urgente e incluso requerir que se interrumpa el trabajo en curso.

En TUNE-UP Process estas tres situaciones pueden ser abordadas de forma integrada para un mismo producto. Una Línea de trabajo NO planificable tendrá simplemente un Backlog ordenado. De forma que el equipo en todo momento trabaja siguiendo ese orden, pero pudiendo interrumpirse y modificarse dicho orden por la aparición de un trabajo más prioritario.

Por otra parte, tratándose del mismo producto o servicio que se ha dividido en varias Líneas de trabajo, sería interesante poder visualizar el trabajo en conjunto que se está realizando sobre el producto o servicio desde las diferentes Líneas de trabajo. En Worki esto se hace estableciendo una Estructura-Temas compartida entre Líneas de trabajo.

Así, en TUNE-UP Process para cada Línea de trabajo se puede establecer una estrategia diferente para planificación y seguimiento. En TUNE-UP Process se establecer 5 los patrones básicos aplicables para planificación y seguimiento, ellos se presentan más adelante.

Backlogs y Workflows

En la siguiente imagen se ilustra la posible dinámica del Backlog de una Línea de trabajo. Es muy importante que el Backlog esté ordenado para asegurar que el equipo siempre esté trabajando en lo que se ha establecido como más prioritario. Además, cualquier bloqueo o espera se hará evidente porque obligaría al equipo a trabajar en UT menos prioritarias.

Un Backlog estático, sin cambios, correspondería a un contexto en el cual no hay incertidumbre en cuanto a lo que pide la "parte cliente" y/o a un contexto en el cual la "parte cliente" no solicita nuevos trabajos al equipo. Por lo cual, y particularmente en contextos TI, la dinámica del Backlog es bastante alta, es más, de no serlo podríamos sospechar que el producto o servicio simplemente no está siendo utilizado por la "parte cliente". Un producto o servicio exitoso demandará nuevas funcionalidades, mantenimiento y soporte.

A continuación, se muestra el workflow más simple que podríamos establecer como proceso para UT.

Este tablero kanban solo muestra tres posibles estados (TO DO, DOING, DONE) y podría ser suficiente para tareas simples, que no requieren mayor procesamiento y/o actividades especializadas. Solo con la columna "Realizar trabajo" tendríamos muy poca observabilidad del estado de las UT, lo cual es útil en trabajos más sofisticados. En general, lo básico que podríamos esperar respecto de una determinada UT es que se especifique, se ejecute el trabajo asociado y que se pruebe antes de entregar. Además, antes de especificar en detalle una UT es importante que haya llegado el momento de hacerlo, es decir, que estamos cerca de su ejecución. Por lo cual, es interesante que las UT esperen a alcanzar prioridad antes de pasar a especificarse en detalle. Según esto, a continuación, se ilustra lo que podría ser un tablero kanban (workflow) básico para el procesamiento de las UT.

La columna "Introducir" permite asegurar que las UT no están repetidas o solapadas con otras ya existentes y que además tienen unos mínimos atributos establecidos. La columna "Esperar prioridad" sirve de buffer para que en ese estado se ordenen las UT y esperen a comenzar su procesamiento. Las columnas "Especificar", "Ejecutar" y " Probar" representan los estados/actividades básicas de procesamiento. Las UT recorren el tablero de izquierda a derecha hasta terminar, sin embargo, podría haber re-trabajo representado por el retorno de una UT a una columna previa en las actividades de procesamiento (volver a Ejecutar por detectarse fallos al Probar, o volver a Especificar por encontrarse defectos de especificación). Además, como se ilustra con las líneas rojas en la imagen anterior, durante el procesamiento de las UT es importante mantener el orden previamente establecido, así las UT más prioritarias deberían ser las primeras en llegar a terminarse.  

Patrones de planificación y seguimiento para Líneas de trabajo

Pero antes de comentar lo patrones es importante destacar que independiente del patrón aplicado en una Línea de trabajo, siempre tendremos que gestionar un Backlog y cada UT seguirá un proceso establecido en su workflow (el diseño de su tablero kanban). Es decir, todos los patrones que se presentan a continuación se aplican sobre una Línea de trabajo que ya tiene de base un Backlog y los workflows definidos para sus UT (al menos uno).

A. Entrega continua de trabajo terminado (sin Sprints ni Proyecto). Se trabaja sin Sprint ni Proyectos (no planificar), el trabajo se prioriza en el Backlog y se atiende según dicho orden haciendo la entrega inmediata del trabajo terminado.

Este patrón es el más recomendado para contextos de trabajo "no planificable", básicamente porque el alcance del trabajo para un período futuro no es conocido a priori. Por ejemplo, en un contexto de trabajo de soporte, en el cual no se sabe de antemano qué incidencias reportarán los clientes en las próximas semanas. Es esto contextos se puede hacer una cierta previsión de carga de trabajo usando datos históricos pero el contenido concreto del trabajo no se conoce hasta que el cliente lo reporta.

Los miembros del equipo cogen del Backlog la siguiente UT siguiendo el orden establecido y la procesan según su workflow hasta terminarla (y entregarla), para luego ir por la siguiente y así sucesivamente. El buen rendimiento del equipo se basa en el buen flujo de trabajo terminado, es decir, entregar lo más rápidamente el trabajo solicitado por el cliente. Se presta atención a indicadores tales como: lead time (tiempo transcurrido entre la solicitud y la entrega del trabajo terminado) o cycle time (tiempo transcurrido entre el comienzo del procesamiento y la entrega del trabajo terminado), bloqueos o esperas, cuellos de botella en el proceso, postergación de UT (vigilar la edad de las UT, tiempo desde cuándo es solicitada la UT).

Si el flujo de nuevas UT es relativamente alto y su contenido está bien tipificado el Product Owner de la línea de trabajo puede establecer ciertas guías respecto de la priorización del trabajo y así el mismo equipo, aplicando dichas guías, mantiene el Backlog. Esto se ilustra en la siguiente imagen.

B. Sprints "ideales". El trabajo se entrega en grupos de UT terminadas al final de cada Sprint. Se intenta que los Sprints tengan la misma duración y que no cambien el contenido del Sprint durante su realización. La siguiente imagen ilustra la idea de Sprints ideales, en cuanto a que: tienen una misma duración, son consecutivos (apenas termina uno comienza el siguiente), y no sufren cambios de contenido durante su realización.

Este patrón es adecuado cuando se trata de un trabajo cuyo alcance se puede establecer a priori (antes de comenzar dicho trabajo) y se prevé una duración de más de un mes (tamaño máximo recomendado para un Sprint).

Se establece un Backlog, se acuerda con el Product Owner el contenido del primer Sprint. Una vez terminado el Sprint éste se revisa, si aparecen nuevas UT (mejoras o correcciones de fallo) se incluyen como nuevas UT en el Backlog. Se verifica la priorización de UT restantes en el Backlog y se vuelve a acordar un siguiente Sprint. Este proceso continúa hasta agotar el contenido del Backlog o hasta que el Product Owner decide parar la Línea de trabajo.

Al acordar el contenido de un Sprint el equipo contrasta su Capacidad con la Estimación del esfuerzo asociado al trabajo candidato para ser incluido en el Sprint. La estimación puede ser "a ojo", usando Puntos, o usando Horas Ideales. Si se usan Horas Ideales, éstas estarán asociadas a alguna actividad específica del proceso, por ejemplo, Horas Ideales de Programación.

En este patrón solo se gestiona el alcance del Sprint, la duración y costo del Sprint sería constante, y el término del trabajo no está pre-establecido.

Si bien todo lo anterior sería una situación muy favorable para aplicar el enfoque ágil, no suelen cumplirse todas las características mencionadas, por eso lo denominamos Sprint "ideales".  

C. Sprints "flexibles". El trabajo se entrega en grupos de UT terminadas al final de cada Sprint. Los Sprints pueden tener diferente duración y/o se asume que pueden cambiar su contenido. Es decir, los Sprints pueden ser flexibles en cuanto a su duración y/o contenido. La siguiente imagen ilustra Sprint con diferente duración y ciertos movimientos de UT que entran a un Sprint o son desplazadas a Sprints posteriores.

Los Sprint flexibles son una alternativa más realista para contextos en los cuales hay bastante dinámica especialmente en cuanto a aparición de nuevas UT en el Backlog y especialmente cuando éstas conllevan cierta urgencia. Así, una UT urgente podría entrar directamente en el Sprint actual (no esperar en el Backlog hasta el próximo Sprint) pero esto puede llevar también a terminar anticipadamente (por urgencia) un Sprint o alargarlo para incluir lo original más lo añadido.

Detrás de esta idea de Sprint "flexible" está la reflexión respecto a cuán planificable es el trabajo que se está gestionando en la Línea de trabajo. Mientras menos planificable sea, es decir, mientras más cambios se introduzcan sobre la marcha de los Sprints (y que no puedan esperar al siguiente Sprint) más trabajo de gestión tendremos respecto de decidir nueva duración del Sprint o determinar qué UT postergar quitándolas del Sprint y volviéndolas al Backlog. También es importante evaluar si convendría organizar el trabajo de esta Línea de trabajo convirtiéndola en dos, una planificable más cercana a Sprint "ideales" y otra "no planificable" gestionada con el patrón A, de entrega continua.

Aunque ambas formas de flexibilidad son posibles (duración y contenido del Sprint), se recomienda intentar mantener la regularidad de duración de los Sprint y cuando sea necesario negociar con el Product Owner el alcance (quitando o reduciendo UT del Sprint). Para la moral y disciplina del equipo es mejor esta opción, así se mantiene una sana rutina de trabajo y compromisos.

Los Sprints "flexibles" son también la mejor opción cuando se ofrece un producto genérico ya entregado y ahora en mantenimiento continuo, es decir, cuando no se trata de un producto a medida, donde suele existir una relación más estrecha con los clientes. Aunque es interesante mostrar una continuidad en la mejora del producto, en este caso los desarrolladores del producto suelen tener mayor libertad en cuanto a decidir qué incluir en un Sprint y cuándo darlo por terminado.

D. Sprints "a posteriori". Una última alternativa complementaria a la opción A, es que después de terminar y entregar un conjunto de trabajo se defina un Sprint simplemente como agrupador de trabajo ya terminado. Esto puede ser útil e interesante para consultar más fácilmente el trabajo terminado. Por ejemplo, una vez finalizado el mes de junio, todas las UT terminadas en dicho mes podrían incluirse en el "Sprint Junio". De esta forma también se evita que se produzca una acumulación de UT terminadas en el contexto del Backlog pues continuamente las UT terminadas se irían pasando a algún Sprint.

Este patrón es básicamente un complemento al patrón A, de entrega continua, es decir, se trabaja de dicha forma pero a períodos regulares todo el trabajo terminado en el Backlog para un período se mueve a un Sprint creado al terminar dicho período.

E. Combinando Sprints y Proyecto. Un Proyecto conlleva un compromiso de entrega en más de un mes de plazo (en general varios meses). Así, podemos mezclar ambos conceptos, abordando el Proyecto como una secuencia de Sprints. El resultado de cada Sprint no es necesariamente una entrega, sí lo es el resultado del último Sprint, el cual coincide con el término del Proyecto. Combinando Sprints y Proyecto se tienen dos niveles de planificación y seguimiento, a corto plazo con el Sprint y a mediano o largo plazo con el Proyecto. Al mezclar Sprints con Proyecto los Sprints podrían ser "ideales", "flexibles" o "a posteriori".

Antes de ejecutar el Proyecto se establece el Backlog, y luego se estima y ordena. Con esto se puede realizar la gestión de alcance del Proyecto de forma que el esfuerzo estimado sea consistente con los plazos de entrega y Capacidad del equipo. A partir de allí se van abordando los Sprints, con su correspondiente gestión de alcance a nivel de Sprint. Durante el proyecto podrán aparecer nuevas UT (muchas de ellas como mejoras o correcciones de fallos detectadas en las revisiones de Sprints). Estas nuevas UT se incluyen en el Backlog e inmediatamente se debería volver a gestionar el alcance del Proyecto. El Proyecto como un todo debería tener un buffer de Capacidad para poder abordar hasta un cierto nivel las nuevas UT o desviaciones de la estimación que ocurran durante el Proyecto, pero aun así puede que en algún momento no quede más remedio que negociar con el Product Owner. Desde la perspectiva ágil la recomendación es negociar alcance más que plazos o costos (posible incremento de Capacidad). La negociación de alcance se centra en determinar hasta qué punto, siguiendo el orden de las UT en el Backlog, las siguientes UT ya no entrarían en la entrega del Proyecto. Otra alternativa de negociación de alcance es la reducción del propio alcance de algunas UT, es decir, reducir el trabajo que suponen algunas UT. Cuando se trata de UT Épicas (UT grandes) normalmente existe la oportunidad de separarlas en una primera versión (una UT) con lo esencial y otra UT adicional representando el resto de trabajo que podría quedar en el Backlog pero fuera de la entrega del Proyecto.    

Comentarios finales

La organización más eficaz y eficiente del trabajo pasa por una buena organización de Líneas de trabajo y equipos encargados de dichas Líneas de trabajo. Cada Línea de trabajo debe tener un buen Product Owner (leer "Se busca Product Owner ..."). De acuerdo con las características de cada Línea de trabajo se debe establecer cuál es el patrón de planificación y seguimiento que se le aplicará. Así, un equipo encargado de distintas Líneas de trabajo podría estar aplicando diferentes patrones de planificación y seguimiento en cada una de sus Líneas de trabajo.