sábado, 11 de abril de 2020

Organización ágil del trabajo: Parte II - Dos dimensiones del trabajo

En este post ilustraré la variedad de alternativas para la organización ágil de una Línea de Trabajo. El concepto de Línea de Trabajo se refiere a un Backlog  (conteniendo el trabajo que hay que hacer) + su Product Owner + su Equipo, encargado de realizar dicho trabajo. Así pues, en un cierto contexto de trabajo podrían existir múltiples Líneas de Trabajo, cada una con una organización del trabajo diferente según sus necesidades.

La organización ágil de trabajo tiene dos dimensiones: Dimensión Contenedor del Trabajo y Dimensión Proceso del Trabajo. En la Dimensión Contenedor del Trabajo por defecto siempre tendremos el Backlog, que es una lista ordenada de Unidades de Trabajo (UT, o llámense ítems o Historias de Usuario). En la Dimensión Proceso del Trabajo tendremos al menos un tablero kanban que refleja el workflow con el cuál abordamos el trabajo. En la siguiente figura se muestra el caso por defecto, tenemos un Backlog y el tablero kanban más simple (To Do, Doing, Done).
La clave está en entender que una UT estará en una determinada posición del orden del Backlog y al mismo tiempo estará en algún estado/actividad del tablero kanban. En la figura se observa que la UT se color naranja está en la parte alta del Backlog (más cerca de terminarse) y en el tablero está en el estado Doing.

Las UT se irán terminando en el Backlog de acuerdo a su orden desde arriba hacia abajo, y las siguientes irían subiendo. Debería existir algún mecanismo para ocultar/mostrar las UT terminadas pues el foco debería centrarse en las UT no terminadas y más prioritarias. Las nuevas UT que lleguen deberían posicionarse en el Backlog compitiendo en prioridad con las ya existentes.

En la siguiente figura se ilustra el caso en el cual el tablero kanban refleja un proceso más detallado que ofrece mayor observabilidad del estado de cada una de las UT. En este caso, por ejemplo, la UT naranja estando en el Backlog como contenedor, al mismo tiempo está en la actividad Diseñar.
En los dos casos anteriores el trabajo se centra en generar un buen flujo de trabajo terminado y siguiendo el orden asignado a las UT, de acuerdo a las prioridades establecidas por el Product Owner. No hay fechas comprometidas para el término de las UT, pero podrían asignarse puntualmente fechas límite para algunas de ellas y hacer un seguimiento al respecto para mantenerlo coherente con el orden asignado a la UT.

Veamos ahora un caso en el cual la Línea de Trabajo tienen regularmente unos compromisos de entrega de UT terminadas. En este caso convendría utilizar Sprints que representan períodos de tiempo (recomendación de no más de un mes de duración), es decir, tienen una fecha de inicio y fin. Si se ponen UT en un Sprint se asume que el esfuerzo asociado a su realización es coherente con la Capacidad del equipo para dicho período. La siguiente figura ilustra el caso en el cual además del Backlog se usan Sprints.
En este caso un conjunto de UT se mueven desde el Backlog al Sprint en el cual se va a ejecutar el trabajo asociado hasta terminarlas. Nuevamente, en este caso tanto si una UT está en el Backlog como si está en un Sprint, al mismo tiempo estará en algún estado/actividad del tablero kanban. Cuando se utilizan Sprints, es importante distinguir dos grupos de estado/actividades en el tablero kanban; columnas de "preparación" de las UT, donde se define con suficiente detalle la UT, y columnas de "ejecución" de las UT, que corresponden al trabajo que se hará dentro del Sprint hasta  terminar la UT. De esta forma la correcta preparación de las UT permite tener una estimación adecuada para establecer el esfuerzo asociado. En este caso la columna "Esperar Sprint" establece dicha división del tablero en "preparación" y "ejecución". En Esperar Sprint se acumulan las UT que ya están preparadas para incluir en un Sprint. En este ejemplo, las actividades Programar y Aplicar Pruebas de Aceptación corresponden al trabajo de ejecución de las UT durante el Sprint.

Aunque podría definirse con anticipación el contenido de UT de varios Sprints futuros no es recomendable, pues los cambios en el contenido de Sprint previos repercutirán en el contenido de Sprint futuros para mantener coherente su relación entre esfuerzo y Capacidad del equipo. Así pues, se sugiere definir el próximo Sprint y cuando se esté agotando comenzar a definir el Sprint siguiente.

Finalmente, en el caso de requerir un seguimiento más detallado de un conjunto de UT que se realizarán durante un período más largo es conveniente asociarles un Proyecto para tener un seguimiento global de las UT.  Pero en este caso también puede ser interesante utilizar Sprints para el seguimiento a corto plazo. Backlog, Sprint y Proyecto son así tres contenedores que se podrían utilizar en conjunto. Una UT estará o no dentro del alcance del Proyecto, y podrían estar en el Backlog o en algún Sprint. En la siguiente imagen se muestra como el Proyecto actúa como contenedor adicional de UT que pueden estar en un Sprint o en el Backlog antes de ser incluidas en un Sprint.
La gestión de alcance del Proyecto se realizaría asociando o no las UT al proyecto. Así, en un Sprint podría haber UT del Proyecto y otras no pertenecientes al Proyecto. Lo mismo pasaría en el Backlog, donde se marcarían las UT que pertenecen al proyecto.

En este punto del post toca pasar la cuña de publicidad de nuestra herramienta Worki :-), la cual hasta donde sé es la única donde se apoya adecuadamente esta doble dimensión de la organización del trabajo. En Worki, cada Línea de Trabajo puede incluso tener asociados varios tableros kanban en caso que se apliquen diferentes procesos a distintos tipos de UT. En Worki aunque las Líneas de Trabajo tengan diferente organización (en cuanto a uso o no de Sprints y/o Proyecto, o se utilicen diversos workflows) se ofrece una visualización integrada de todo el trabajo. Esto se ilustra en la siguiente figura que corresponde a la interfaz de arranque de Worki.


En Worki se ofrecen múltiples vistas de la información facilitando la gestión en contextos multiproyecto o de varios equipos de trabajo, y quizás con personas trabajando en varios equipos. Por ejemplo, en la siguiente figura se muestra un tablero kanban asociado a la información mostrada en la figura anterior.  


En este post también espero haber dejado una vez más en evidencia que no es una buena idea el enfrentar métodos ágiles, promoviendo el uso de uno u otro de forma alternativa. Hemos visto cómo, cuando es conveniente, pueden usarse Sprints (proceso iterativo propuesto por los métodos Scrum y Extreme Programming) junto con un tablero kanban (la esencia del método Kanban). Con lo cual no se trata de aplicar de forma exclusiva Scrum o Kanban (o cualquier otro método ágil), lo sensato es aplicar las prácticas ágiles que nos ofrecen los diferentes métodos, aquellas que sean convenientes para la Línea de Trabajo, e intentar aplicarlas con la mayor profundidad posible. Lectura recomendada: ¿Kanban or Scrum? that is not the question. Si a la organización ágil de Línea de Trabajo le llamamos Scrum, Kanban u otro nombre, eso es un asunto de simplificación, al cual no vale la pena darle más importancia, solo daría para discusiones puristas infructuosas :-).


Patricio Letelier

www.tuneupprocess.com 




No hay comentarios:

Publicar un comentario