domingo, 25 de mayo de 2014

El Backlog: el contenedor del trabajo pendiente

Con este post quiereo destacar la importancia del concepto de Backlog (Product Backlog) en el agilismo. Sí, aunque el concepto de Backlog es algo básico y cualquiera que aplique métodos ágles debería saber su importancia, me parece que a veces se subestima su papel. Además, en contextos de trabajo más desafiantes, tales como: multi-proyecto o multi-equipo, el concepto de Backlog debe adaptarse adecuadamente a dicho contexto. A continuación haré una breve descripción de diversos aspectos relacionados con el Backlog.



Definición de Backlog. El Backlog es una lista ordenada de todo el trabajo pendiente.

Contenido. Dependiendo del método ágil utilizado, los elementos incluidos en el Backlog se denominan ítems, historias de usuario, unidades de trabajo, etc. Utilizaré simplemente "ítem" para refererirme a los elementos del Backlog.  Además, dependiendo del contexto de trabajo, los ítems podrían tener una determinada clasificación. Por ejemplo, en el caso de productos software, el Backlog incluirá ítems que corresponden a nuevos requisitos, mejoras en requisitos ya implementados y/o correcciones de fallos. A continuación se indican algunas características del contenido del Backlog:
  1. Un ítem debe, en general, ser algo de valor para el cliente, y algo que él mismo pueda evaluar. Por ejemplo, "Elaborar una especificación de diseño" NO debería ser un ítem del Backlog, a menos que el cliente solo esté interesado en conseguir una especificación como resultado :-). Sin embargo, de forma puntual pueden existir trabajos técnicos incluidos en el Backlog, tales como "Montar entorno de desarrollo". Aunque este tipo de ítems no es recomendable incluirlos en la planificación y revisión del trabajo de cara al cliente porque para él probablemente no son evaluables (aunque sí deben ser considerados respecto del esfuerzo que restarán a la capacidad del equipo cuando se realicen).
  2. Los ítems del Backlog puede ser de diferente tamaño. Orientativamente se prefieren ítems que se puedan terminar en no más de una semana de trabajo.
  3. Siempre antes de realizar un trabajo es necesario contar con una clara definición de lo que se espera como resultado. Indudablemente esta definición conlleva una inversión en esfuerzo. Siguiendo la recomendación de Lean, en cuanto a su "muda" que sugiere "no producir demasiado o con mucha antelación", la definición detallada de un ítem puede postargarse hasta que no se acerque la realización del ítem. Es decir, si un ítem no es prioritario podemos esperar a que llegue a serlo para trabajar en su definición más detallada. Con esto reducimos el riesgo de perder esa inversión de esfuerzo en definición cuando posteriormente un ítem pierde prioridad, cambia su orientación, o simplemente llega a desestimarse. Idealmente antes de realizar un trabajo se debería tener una cierta especificación de él, suficiente para que se puede llevar a cabo. Cuando se trabaja sin sprints, dicha especificación se puede postergar hasta seleccionar el ítem para trabajar en él. Sin embargo, cuando se trabaja con sprints, y si existe un compromiso para terminar lo incluido en el sprint, lo normal es que antes de incluir el ítem en el sprint esté suficientemente especificado (y estimado).
Orden. El Backlog debería en lo posible estar siempre ordenado para así facilitar la selección del próximo trabajo que debe realizarse (ya sea cogiendo un grupo de ítems para asignarlos al próximo sprint, o para coger un ítem para trabajar de inmediato en él). El número de orden de un ítem debe reflejar su prioridad, evaluada mediante una combinación de criterios, tales como el valor que supone el ítem para el cliente, su urgencia, el esfuerzo asociado a la realización del ítem, etc. En "Gestión eficaz del Backlog" se describen criterios que podrían aplicarse para establecer dicho ordenamiento.

Extensión. No debería preocupar que el Backlog de una línea de trabajo tenga muchos ítems. Al contrario un Backlog extenso probablemente se debe a que el producto o servicio tiene demanda para mantenimiento, lo cual es síntoma que el producto o servicio se está utilizando e interesa mejorarlo. Obviamente si se trata mayoritariamente de ítems asociados a corrección de fallo, esto no sería deseable :-). 


Niveles. Si bien lo usual es referirnos al Backlog de un producto, servicio o proyecto, también el trabajo pendiente (Backlog) puede verse desde otros niveles de agregación, por ejemplo: el Backlog de cada persona, el Backlog de un equipo de trabajo (incluyendo todo los productos, servicios o proyectos encargados al equipo), o cualquier otro nivel de agrupación superior, u otras combinaciones posibles. 


Backlog Multi-proyecto. Aunque no es recomendable, frecuentemente un equipo está encargado de realizar trabajo en varios frentes o líneas de trabajo (productos, servicios o proyectos). Estas líneas de trabajo pueden ser, por ejemplo: desarrollo un nuevo producto, mantenimiento de un producto existente, un proyecto de integración entre productos, servicio de soporte para productos, etc. Así, es conveniente disponer de un Backlog para cada línea de trabajo. En un contexto-multi-proyecto es necesario primero disponer de directrices globales en términos de asignación de capacidad y prioridad entre las líneas de trabajo, y en segunda instancia la propia priorización del Backlog de cada línea de trabajo, expresada en el ordenamiento del Backlog correspondiente.En la siguiente figura se ilustra el trabajo multi-proyecto de un mismo equipo, encargado de tres productos (P1, P2 y P3), cada uno con su Backlog y kanban, pero solo P2 y P3 trabajan con sprints.



Backlog Multi-equipo. En casos de productos, servicios o proyectos de gran envergadura, cuando participan varios equipos, cada uno encargado de una parte o área, es conveniente que cada equipo tenga su propio Backlog. Sin embargo, probablemente la demanda de trabajo llegará a la línea de trabajo como un todo, para lo cual conviene tener un Backlog global donde se reciba toda la demanda, y que periódicamente, después de una evaluación que permita determinar el área o áreas afectadas, los ítems se muevan a los Backlogs de equipo según corresponda.

Extracción de ítems. Cuando en una línea de trabajo se trabaja usando Sprints períodicamente (antes de comenzar el siguiente Sprint) se traslada un conjunto de ítems desde el Backlog hacia el próximo Sprint, lo cual hace disminuir los ítems contenidos en el Backlog. Sin embargo, cuando en una línea de trabajo NO se usan Sprints (porque, por ejemplo, la demanda de trabajo no se puede o no se quiere planificar, sino que se prefiere generar un buen flujo de trabajo terminado), en este caso los ítems se abordan también por orden pero en el Backlog, y una vez terminados podrían guardarse en otro contenedor. Así, los ítems del Backlog van escalando posiciones en la medida que aquellos que están en la parte superior se van terminando.  

Todas estas consideraciones las abordamos en nuestra herramienta TUNE-UP Process proporcionando apoyo con funcionalidades específicas para ello.



Patricio Letelier

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


No hay comentarios:

Publicar un comentario