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).
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 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.
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.
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.
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.
Patricio Letelier
No hay comentarios:
Publicar un comentario