Gestión del Alcance en un Proyecto Ágil

El agilismo está volcado en la satisfacción del cliente, para esto debemos mantener siempre alineando el trabajo del equipo con los intereses del cliente, aún a costa de asumir cambios respecto de lo que inicialmente se acordó. Este planteamiento genera inmediatamente inquietud en quien te escucha y aparece la típica pregunta ¿y cómo se gestiona el alcance? ¿si permites que el cliente cambie lo que se acordó, cómo podremos llegar a buen término sin modificar los plazos y/o los recursos?

Obviamente, si el cliente introduce nuevos requisitos o modifica los ya considerados probablemente se estará modificando el esfuerzo requerido para completar la entrega del producto, lo cual si es asumido sin más pondría en riesgo el cumplimiento del plazo de entrega o incluso directamente podría hacer inviable dicha entrega. Por contraparte, si el equipo se niega a hacer cambios respecto de lo pactado inicialmente, puede que se consiga un producto técnicamente correcto y acorde a lo inicialmente acordado, pero que podría ser inútil respecto de  las expectativas finales del cliente. Para resolver este dilema lo que debemos hacer es permitir cambios pero evaluando su impacto respecto del esfuerzo, junto con negociar con el cliente la posible exclusión en la entrega de otros elementos menos prioritarios.

A partir de la versión de 2011 de la Scrum Guide, se ha pasado a proponer que el equipo trabaje con un solo sprint abierto y que el resto del trabajo pendiente esté en el Backlog, se ha quitado el concepto de Release (entrega) y la correspondiente Release Planning Meeting. Recordad que además los sprints no deberían tener una duración mayor a un mes. Sin embargo, si se está desarrollando un nuevo producto o se está abordando una remodelación de gran envergadura en un producto existente, probablemente necesitemos varios sprints para poder conseguir un producto preparado para ser puesto en producción. En este caso, cuando el cliente introduce cambios durante el desarrollo, éstos se harían en el sprint actual (si es estrictamente necesario) o se llevarían al Product Backlog. Esta forma de trabajo dificulta la gestión del alcance puesto que el limite de trabajo que se incluirá en la entrega debe establecerse en el Product Backlog (a menos que estemos en el último sprint antes de la entrega, caso en el cual el alcance final lo determinaría el propio sprint).

Para realizar una eficaz gestión de alcance, aceptando cambios en el trabajo pendiente, es imprescindible distinguir claramente durante todo el desarrollo cuál es el trabajo pendiente acordado para el entrega y cuál es el que NO será incluido en la entrega. El esfuerzo asociado al trabajo de la entrega debe ser ser factible de abordar con la capacidad del equipo y el tiempo disponible hasta el plazo de entrega. Para esto el equipo debe tener una noción de su Capacidad, por ejemplo en horas ideales por semana o puntos, y correspondientemente cada ítem de trabajo debería estar estimado en una unidad coherente con la usada para medir la capacidad. Así pues, la gestión del alcance conlleva la estimación del trabajo que se realizará y el registro de la Capacidad del equipo. Mientras más inflexible sea el compromiso de la entrega, más frecuente y preciso debería hacerse dicha gestión de alcance. Trabajando con sprints, el seguimiento no solo debe centrarse en el alcance del sprint sino también en el alcance de la entrega de la cual el sprint es una parte.

El alcance de la entrega se mantiene coherente con los plazos y la capacidad del equipo negociando con el cliente. Se negociará la introducción de ítems nuevos (o modificaciones en ítems existentes) o su intercambio por otros ítems considerados hasta ese momento parte de la entrega, es decir, la idea es añadir, quitar, modificar y/o intercambiar los ítems.

De cara a conseguir una buena "cadencia" (ritmo de trabajo terminado que puede entregar un equipo en regimen normal normal de trabajo) es preferible negociar el alcance de la entrega prescindiendo de ítems menos prioritarios, en lugar de modificar los plazos o introducir cambios en el equipo para conseguir más Capacidad (a menos que el equipo no tenga dedicación completa a la entrega, caso en el cual sí que sería interesante contar con más dedicación a ello, para intentar conseguir su dedicación completa). 

Aceptar el cambio conlleva estar vigilantes del alcance y negociar oportunamente cada vez que se produzcan  cambios en el esfuerzo que puedan afectar el compromiso al momento de la entrega. Por lo tanto la gestión del alcance en un contexto ágil existe y es protagonista.

Hay que destacar que la gestión del alcance sólo tiene sentido cuando existe planificación, estimación y el compromiso de entrega. Puede darse que el compromiso con el cliente esté basado en un Acuerdo de Nivel de Servicio o simplemente en indicadores de flujo, tales como ítems terminados por unidad de tiempo, tiempo de servicio de los ítem desde que se reciben hasta que se implementan, etc. Esto sucede por ejemplo en equipos que realizan mantenimiento continuo de un producto resolviendo lo antes posible fallos o pequeñas mejoras, o equipos fuera del contexto de desarrollo, tales como un help desk o un equipo de infraestructuras encargado de resolver incidencias. En estos casos el foco se cambia hacia mejorar el flujo de trabajo terminado más que en gestionar el alcance ya que la demanda suele no ser planificable. Así pues, para estos casos la gestión del alcance no es protagonista pero se mantiene la priorización del trabajo, posiblemente también su estimación y quizás el registro de esfuerzo invertido. . 

En el contexto ágil, cuando se requiere un seguimiento continuo y preciso se utiliza la Gráfica Burndown, en la cual podemos observar tanto la tendencia del trabajo restante como las perturbaciones que puedan afectar los compromisos. La siguiente figura muestra una gráfica Burndown para el segundo sprint de desarrollo de un producto.

En la figura, la línea roja muestra día a día el esfuerzo restante del sprint. La línea morada es la referencia. Si el esfuerzo restante tiende a ir por bajo la línea morada puede que se cumplan con la entrega antes de plazo. Correspondientemente, si el esfuerzo restante tiende a ir por sobre línea de referencia nos advertiría que puede que no se llegue a cumplir en el plazo establecido. Así, la gestión de alcance durante un sprint se apoyará en la Gráfica Burndown para determinar la factibilidad de incorporar cambios en lo acordado al inicio del sprint.

Si a la vez, además de supervisar el sprint abierto de un producto, estamos en el marco de una release o entrega (un compromiso a más largo plazo), mantendremos en paralelo una gráfica Burndown similar a la anterior pero para el seguimiento de todo el trabajo de la entrega (todos los sprints). Así pues, una gráfica Burdown de la entrega ilustraría el progreso y estado actual del proyecto como un todo, es decir, de todas las unidades de trabajo incluidas en la entrega (release).

El enfoque descrito lo tenemos implementado en nuestra herramienta TUNE-UP Process. Cada producto que lo necesite puede ser planificado y supervisado usando Sprints. Además, cuando se requiere una planificación y seguimiento a más largo plazo se pueden establecer Proyectos los cuales utilizan gráficas similares a las que se utilizan para el seguimiento de un Sprint.



Patricio Letelier

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

Actividad: Tablero kanban + concepto de WIP + Diagramas de Flujo Acumulado

El propósito de este post es describir una actividad que realizo en mis cursos para ilustrar cómo un proceso puede ser supervisado y mejorado mirándolo desde una perspectiva de flujo. Para una explicación más detallada del concepto de WIP (Work in Process) recomiendo leer Limitar el WIP, una buena idea, pero con matices y alternativas.  

Un tablero kanban es la visualización de un proceso cuyas actividades son las columnas del tablero. Por defecto se asume que el flujo va de izquierda a derecha y de forma secuencial. Las excepciones a este comportamiento deberían ser establecidas como reglas del kanban pero no son visibles explícitamente en el tablero. Para conocer los desafíos asociados a la implantación de un tablero kanban leer Actividad: Lo básico de kanban y Scrum y Desafíos para la implantación efectiva de Scrum + Kanban. Para conocer algunas herramientas gratuitas que dan soporte básico a tableros kanban ver Kanban for free.

Usaré el término "unidades de trabajo" para referirme de forma genérica a los elementos de trabajo que fluyen en el tablero kanban, pasando de una columna a otra. En la práctica, una unidad de trabajo, dependiendo del contexto, podría ser un ticket de soporte al cliente, una incidencia asociada a una infraestructura, un expediente en un proceso administrativo, un cambio en un producto software, etc.

Recrearemos una cadena de producción de casas, simplificado a tres actividades; Armar Pared, Montar Puerta y Ventanas, y Armar y Montar Techo. Este ejercicio está pensado para realizarse en equipos de 5 a 8 personas. La duración estimada es de mínimo una hora y puede extenderse con tandas adicionales para mejorar el proceso mediante cambios y la correspondiente evaluación del resultado en base a los indicadores de flujo.

A continuación se describen los materiales que utilizados. Cada equipo deberá disponer de sus propios materiales.

Tablero kanban

Un tablero kanban puede hacerse con un tablero físico en una pared y usando post-it. Las columnas del tablero se corresponden con las actividades del proceso (en nuestro caso las indicadas antes), además añadiremos una primera columna denominada Pedidos Pendientes, la cual será una cola con los pedidos de casas que se vayan recibiendo, y una columna en el extremo derecho llamada Casas Terminadas, la cual acumulará los pedidos ya terminados.

Si bien para el ejercicio bastaría con un tablero kanban físico, prefiero utilizar una herramienta así me aseguro que el equipo tenga todo a mano pues el trabajo se estará desarrollando en una mesa. Recomiendo utilizar la herramienta Trello, definiendo en ella un tablero como el de la siguiente imagen:

Con post-it (cards en Trello) representaremos los pedidos de casas, los cuales se denominarán C01, C02,  etc. La manipulación del tablero kanban es muy sencilla, en la columna Pedidos Pendientes se irán introduciendo nuevos pedidos, cuando un encargado de actividad se quede disponible cogerá trabajo desde la columna Pedidos Pendientes o desde alguna columna que tenga trabajo preparado para continuar el proceso. Las actividades Montar Puerta y Ventana, y la actividad Armar y Montar Techo tienen implícita una subcolumna TO DO. Así, los encargados de dichas actividades cogerán pedidos en dicha situación. La actividad Armar Pared no necesita una columna TO DO puesto que dicho papel lo desempeña la columna Pedidos Pendientes. En la mesa de trabajo cada encargado cogerá un pedido desde su izquierda y al finalizar su actividad lo dejará a su derecha (lo cual representará el TO DO para la actividad siguiente). De manera alternativa se podrían considerar columnas implícitas DONE para el trabajo finalizado en una actividad. Prefiero hacerlo con TO DO de manera que cuando calculemos el WIP, si hay una tendencia creciente en algún WIP de actividad, el posible cuello de botella esté en dicha actividad. Si lo hiciéramos con DONE el posible cuello de botella estaría en la actividad siguiente que no sería capaz de consumir desde el DONE de la actividad previa.

Gráfica de Flujo Acumulado

El tablero kanban permite visualizar en qué actividad se encuentra cada unidad de trabajo (en nuestro ejemplo pedido) y junto con esto, podemos conocer el WIP de cada actividad. Toda esta información es del instante en el cual observamos el tablero kanban. Si queremos conocer la tendencia del WIP de las actividades del tablero necesitamos coleccionar snapshots con dichos datos. La Gráfica de Flujo Acumulado (Cumulative Flow Diagram o CFD) es representación adecuada para observar dichas tendencias. Descargar la hoja de cálculo para apoyar este ejercicio. A continuación describo cada una de las partes de dicha hoja de cálculo (usando la hoja de ejemplo incluida en el fichero).

• (A) Métricas de flujo. Production Rate es el promedio de unidades de trabajo terminadas en cada snapshot (los snapshots se realizarían periódicamente, por ejemplo, cada hora, día, semana, etc). En nuestro ejemplo sugiero realizar snapshots después de 30 segundos de trabajo. Cycle Time es la cantidad promedio de snapshots que se tarda en terminar una unidad de trabajo a partir del momento que se coge para entrar en la cadena de producción (en nuestro caso cuando se coge para realizarle la actividad Armar Pared). Lead Time es similar a Cycle Time pero el cálculo se hace con el snapshot en el cual la unidad de trabajo llega a estar pendiente para entrar en la línea de producción (en nuestro caso es cuando llega a la actividad Pedidos Pendientes).
• (B) Cada columna S1 ... S10 corresponde a un snapshot. En las filas se contabiliza el WIP de la correspondiente actividad. Es decir, contabilizaremos en la mesa de trabajo cuántos pedidos tenemos en cada punto del proceso. Este WIP es el que será será representado en la Gráfica de Flujo Acumulado. En la hoja de cálculo automáticamente se obtiene el número de pedidos terminados en cada snapshot para con ello calcular el Production Rate.
• (C) Cada columna C01,..., C30 refleja información de los snapshots en los cuales un pedido fue creado (colocado en Pedidos Pendientes), comenzado a procesar (cogido para aplicarle la actividad Montar Pared9 y terminado (puesto en Pedidos Terminados). Es decir, los número en dichas celdas corresponden al número del snapshot (S1, ..., S10) en el cual ocurrió el evento. Las filas inferiones Cycle Time x Pedido y Lead Time x Pedido calculan para cada pedido esos indicadores (los cuales son luego promediados para obtener los correspondientes indicadores globales).
• (D) Gráfica de Flujo Acumulado muestra en franjas el WIP de cada actividad en cada snapshot. También se ilustra la contabilización de Pedidos Pendientes (la franja superior) y de Pedidos Terminados (franja inferior). Si se mantiene una demanda constante en tiempo y cantidad el flujo ideal correspondería a una serie de franjas apiladas en diagonal de un ancho similar (excepto la franja más baja que acumula las unidades de trabajo terminadas). Este es el caso reflejado en la gráfica mostrada en el panel D. Si la demanda está fija y establecida al comenzar un período de trabajo (por ejemplo, un Sprint de desarrollo) las franjas superiores deberían irse extinguiendo hasta quedar sólo la franja de unidades de trabajo terminadas. Si una franja (que no sea la de trabajo terminado) tiende a aumentar de grosor podría tratarse de un cuello de botella. Si una franja tiende a ponerse horizontal más que diagonal puede tratarse de una detención del flujo, es decir, puede que no se esté trabajando o no esté reflejando el paso del trabajo de una actividad a otra.    

Mesa de Trabajo

Lo ideal es tener una mesa de trabajo larga para poner en ella la línea de producción con tres puntos de trabajo, más la cola de Pedidos Pendientes y de Pedidos Terminados. Es necesario contar con un ordenador para visualizar el tablero kanban y para visualizar el Gráfico de Flujo Acumulado (o si es posible, dos ordenadores, uno para cada visualización). Con post-its iremos etiquetando el trabajo, es decir, cada pedido pendiente se pondrá al principio de la línea de producción y desde allí acompañará a la casa en construcción hasta que llegue a la posición Pedidos Terminados.

Piezas de LEGO

Si bien las piezas de LEGO son bastante caras pero tengo por ellas una especial afición :-). De todas formas, el ejercicio podría ser fácilmente adaptado reemplazando las actividades de construcción con piezas de LEGO por manualidades que incluyan dibujar, recortar, pegar y pintar hasta conseguir una pequeña maqueta de casa u otro producto como resultado. A continuación se muestra la maqueta de casa propuesta para ser construida en nuestra línea de producción. Con las condiciones dadas en este ejercicio me ha bastado con disponer material para construir 8 de dichas fachadas de casa por cada equipo, además, en la medida que se vayan terminando puede desmontarse para reutilizarse en los nuevos pedidos (basta que quede en Pedidos Terminados el post-it que refleje que una determinada casa ha sido terminada).

Es importante destacar que en cada punto de trabajo la piezas deben estar completamente desensambladas de manera que en en el trabajo previo a un snapshots una persona no pueda finalizar demasiadas actividades.

Antes de comenzar

El espacio de trabajo se ilustra en la siguiente figura:

1. Previo a la sesión de trabajo asegurarse de que cada equipo dispondrá de al menos un ordenador, de una mesa de trabajo adecuada y de post-its. Es recomendable que antes del ejercicio los participantes conozcan lo básico de kanban y de la gráfica de Flujo Acumulado. Para esto bastaría con que leyesen los posts antes indicados.
2. Cada equipo debe preparar su tablero kanban (físico o en Trello).
3. Cada equipo descarga la hoja de cálculo para elaborar el Gráfico de Flujo Acumulado.
4. Cada equipo prepara unos 20 post-its etiquetándolos con C01, C02, etc.
5. Cada equipo pone en su mesa de trabajo, en cada punto de actividad de construcción, el material necesario totalmente desensamblado.
6. Dejar unos 5-10 minutos para que cada equipo practique construyendo una casa guiándose con la imagen mostrada antes. Asegurarse que cada equipo entiende el modelo y el resultado que debe obtener. Así, evitamos tener re-trabajo asociado a devolver casas defectuosas a puntos previos de la línea de producción. 
7. Una primera configuración para poner en marcha la línea de producción se muestra en la figura annterior. Existirá un encargado de registrar el estado en el kanban y otro de registrar los datos en la hoja de cálculo. Establecer un encargado para cada una de las 3 actividades de construcción. Establecer un encargado para generar pedidos, teniendo un ritmo más o menos constante de 2 pedidos adicionales en cada snapshot. Esta persona también estará encargada de controlar el tiempo de cada snapshot, esperará a que todos estén preparados, avisará y activará el cronómetro, y luego a los 30 segundos dirá STOP, momento en el cual los encargados de actividades de producción deben detener el trabajo que estaban haciendo. Para las casas terminadas una persona tiene que encargarse de completar con el snapshot de término y que esto también se registre en la hoja de cálculo. Para no tener que disponer de demasiado material lego, una persona puede ir desensamblando las casas que lleguen a Pedidos Terminados, devolviendo las piezas a los puntos correspondientes. Otros participantes podrían ir pensando en posibles mejoras para implantar en las siguientes tandas de producción (haremos al menos 2 rondas de 10 snapshots). Es importante vigilar que las casas que se vayan construyendo siempre estén acompañadas del post-it de su correspondiente pedido. Además, entre tandas podrían irse intercambiando los encargados de las actividades de construcción con los que han quedado de observadores, ... 
8. Hacer un ensayo. Antes de echar a andar el cronómetro poner 2 pedidos en Pedidos Pendientes. Cada vez que se pase un pedido a la actividad siguiente debe actualizarse el tablero kanban para que siempre refleje la posición de cara pedido en la mesa de trabajo. Al cumplirse 30 segundos detener el tiempo y con ello la construcción, y recopilar la información para registrarla en la hoja de cálculo.  En la hoja de cálculo, en la columna del snapshot (por ejemplo en el ensayo sería S1) registrar el WIP de cada actividad (la contabilización de los pedidos en dicha actividad, incluyendo aquellos qe todavía no se procesan). Además, para cada pedido que ha entrado en la línea de producción rellenar el número del snapshot en el cual se puso en Pedidos Pendientes, si es el caso en cual snapshot se puso en Montar Pared y finalmente cuando corresponda, en qué snapshot llegó a Pedidos Terminados. Al finalizar el ensayo borrar los datos introducidos.

Puesta en marcha

1. Primera Ronda. Sincronizar a todos los equipos para que comiencen al mismo tiempo. utilizar la hoja de cálculo Ronda1. Deberán realizarse 10 snapshots, cada uno después de 30 segundos de trabajo. Supervisar que el registro posterior al snapshot sea rápido y que los equipos no se atasquen en dudas o discusiones para que todos los equipos terminen más o menos a la vez. Cada ronda duraría alrededor de 20 minutos.
2. Evaluación de la Primera Ronda. Hacer una breve puesta en común del resultado obtenido por cada equipo. Comparar primero las métricas de flujo, resaltando posibles diferencias. Comentar respecto del WIP de cada actividad. En caso de detectar ensanchamientos en alguna franja revisar si se trata de posibles cuellos de botella en el proceso. De forma similar, si alguna franja desaparece es porque la actividad tiene WIP = 0 en algún momento, lo cual podría significar que en esa actividad el encargado podría no tener trabajo. Comentar respecto de la Teoría de las Restricciones (Theory of Constraints de E.Goldratt) la cual nos dice que tenemos que tener presente las limitaciones (restricciones) del sistema, es decir, los puntos que constituyen un cuello de botella. El rendimiento de la línea de producción al completo está limitado por el punto de más bajo rendimiento (el cuello de botella). Las posibles mejoras deben concentrarse en sacar el máximo rendimiento en el punto que constituye la limitación del sistema, una vez mejorada o resuelta la limitación, los esfuerzos deben concentrarse en una nueva limitación, y así sucesivamente. Una forma de "proteger" la limitación del sistema es limitando su WIP, es decir, que no se permita tener en dicha actividad más de un determinado número de unidades de trabajo, esto obligaría por ejemplo a que, si hay actividades previas, éstas deberían bajar su ritmo o incluso llegar a detenerse, aprovechando quizás dichos recursos para mejorar el punto cuello de botella, y evitando generar inventario de trabajo no finalizado. En base a estos comentarios, que cada equipo reflexione respecto de su proceso y plantee cambios para aplicarlos en una segunda tanda. Que cada equipo decida una o dos mejoras, no más (luego si existe la posibilidad se podrían aplicar otras). Algunas mejoras típicas podrían ser: (a) Poner más de un encargado en la actividad que pueda ser cuello de botella, quizás asumiendo uno el ensamble parcial de piezas, por ejemplo, preparando trozos de pared, ensamblando ventanas o puertas en los marcos, o pre-ensamblando el techo.(b) Hacer lo anterior de forma dinámica, es decir, cuando una actividad acumule tenga un bajo rendimiento, apoyar ese punto con más gente, incluso dejando detenidas otras actividades previas. (c) Reorganizar a los encargados de las actividades para que en cada puesto esté quien mejor lo hace, es decir, favorecer la especialización. (d) Crear actividades, pero no lo recomiendo pues implicaría modificar el kanban y la hoja de cálculo, y esto puede hacer retrasar el trabajo del equipo en el ejercicio. (e) Otras ...
3. Segunda Ronda y su Evaluación. Preparar el tablero kanban para empezar de nuevo. Utilizar la hoja de cálculo Ronda2. Repetir 10 snapshots. hacer una nueva puesta en común de los resultados de cada equipo. En la hoja Ronda2 se calculan los porcentajes de mejora respecto de la hoja Ronda1. Evaluar las mejoras aplicadas según los cambios en los valores de las métricas ¿ha mejorado (aumentado) el Production Rate? ¿ha mejorado (disminuido) el Cycle Time? ¿ha mejorado (disminuido) el Lead Time?. En caso de empeorar, habría que cuestionar la utilidad de las supuestas mejoras introducidas pues en caso de hacer una nueva ronda podrían descartarse.
4. Otras rondas. Si hay tiempo y ganas puede hacerse una tanda más.

Comentarios Finales

Es importante reservar unos 10 minutos finales para comentar y hacer extrapolaciones al contexto de trabajo que interese. Algunas ideas para discutir.

• Establecer las analogías con producción de software. Los post-it son unidades de trabajo, los snapshots son días de trabajo, las rondas son sprints, las actividades en el contexto software serían por ejemplo: especificar requisitos, diseñar y estimar, programar, testear, etc. No hemos hecho énfasis en la calidad, pero aplicaría en cualquier contexto, es decir, habría ciertas actividades durante y al final del proceso para asegurar la calidad.
• Establecer las NO analogías con producción de software. La más importante es que en desarrollo y mantenimiento de software el tamaño y/o complejidad (y por consecuencia el esfuerzo) asociados a una unidad de trabajo es diverso, cada unidad de trabajo de software tiene un esfuerzo asociado diferente pues no se generan productos iguales ni independiente, sino que corresponden a componentes de un mismo producto software, que deben además irse integrando y probando para asegurar que se mantenga el comportamiento de componentes antes integrados. Por esto es que las métricas de flujo no son directamente aplicables pues pueden carecer de sentido si las unidades de trabajo son muy diversas. Asociado a lo anterior, aunque en la actividad realizada se puede enfatizar la competencia entre los equipos para motivarlos, si se tratara de equipos de desarrollo de software no tendría sentido hacer comparaciones basándose en las métricas de flujo. Finalmente, si bien es importante promover la mejora de la productividad, un proceso de mejora continua también puede y debe considerar otros aspectos mejorables tales como calidad, costos, clima laboral, motivación y compromiso de los participantes, etc.
• Nuestro proceso ha sido estrictamente secuencial. Esto puede no ser así en el contexto que nos interese aplicar estos conceptos. Es normal que sea conveniente paralelizar actividades.
• No hemos considerado re-trabajo, en contextos como el desarrollo o mantenimiento de software el re-trabajo es habitual. Por ejemplo, se presenta re-trabajo cuando en la actividad de Testeo se detecta un fallo y la unidad de trabajo se devuelve a la actividad de Programación, o incluso puede devolverse más atrás en el workflow cuando se trata de defectos de Requisitos. Podría haberse establecido una actividad adicional al final de la línea de producción que fuese algo así como "Control de Calidad", en la cual se aplicaran pruebas al producto resultante.
• Limitar el WIP puede ser efectivo en ciertos casos, sin embargo, lo que considero más importante y siempre útil para descubrir deficiencias en el proceso, es el realizar una supervisión constante del WIP, detectando oportunamente posibles cuellos de botella, y tomando decisiones sobre la marcha para resolver dicha situación.
• Hemos trabajado (al menos en la primera ronda) con pre-asignación de responsables en cada actividad, y es más, con roles fijos (cada uno realiza sólo una actividad). El concepto Self-organizing Team promueve que todos los miembros de un equipo estén dispuestos a realizar cualquier actividad (aunque cada uno pueda tener más protagonismo o especialización en ciertas actividades). La idea sería que todos los participantes en la línea de producción no estén fijos en un puesto de la línea y que vayan cogiendo trabajo de diferentes actividades, de forma que por encima de todo se privilegie la terminación de pedidos. Esto podría plantearse como una mejora en una de las tandas posteriores a la primera, aunque quizás el tiempo del ejercicio y sus pocas actividades no dan mucho juego para visualizar estas ventajas. 
• Esa interesante destacar que al arrancar cada ronda los puntos hacia el final de la línea de producción están "ociosos" pues aún no les llega trabajo. Esta situación podría invertirse al final de cada ronda si trabajáramos con una cantidad fija de pedidos, y si estos se agotaran ya empezarían a quedar "ociosos" los encargados de las primeras actividades de la línea de producción. Este fenómeno es usual cuando se trabaja con Sprints, al arrancar cada Sprint y al acercarse al su término. Esto puede generar que puntualmente algunos encargados queden "ociosos" respecto del trabajo del Sprint, con lo podrían echar una mano a otros compañeros o podrían preparar trabajo para el siguiente Sprint. 
• Con este ejercicio queda en evidencia el importante esfuerzo requerido para aplicar estos conceptos en un contexto real. La aplicación eficiente y efectiva sólo se consigue con un apoyo automatizado para la recolección de los datos necesarios, para su representación en la Gráfica de Flujo Acumulado, y para el cálculo de las métricas asociadas al flujo. Además, no es sostenible el registrar información en el tablero kanban y a la vez en la Gráfica de Flujo Acumulado. En nuestra metodología y herramienta TUNE-UP Process hemos abordado y resuelto estos desafíos. 

Imágenes de la actividad

Patricio Letelier

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

Agilidad en un contexto multiproyecto. Parte II: Planificación y Seguimiento

En este post ilustraré cómo es posible planificar y realizar el seguimiento de múltiples proyectos bajo un marco común de prácticas ágiles (ver Parte I).

Lo primero que destacaría es que un mismo equipo a lo largo del tiempo (e incluso en un mismo período) puede ser responsable de uno o más productos o servicios (o proyectos definidos sobre ellos). Además, en cada caso, y aunque se trate del mismo equipo, las características de cada tipo de trabajo pueden ser diferentes. No reconocer esta diversidad llevaría que en algunos casos nos "sobre proceso" y en otros quizás nos "falte proceso", es decir, que algunas actividades sobre o tengan que realizarse con menos intensidad, o por contraparte que deban añadirse otras actividades no contempladas inicialmente o complementar las existentes, todo ello dependiendo de la unidad de trabajo abordada. Por unidad de trabajo me refiero a un ítem de trabajo, historia de usuario, incidencia, expediente, etc., es decir, un gránulo de trabajo dentro de un producto, servicio o proyecto. La siguiente figura remarca la diversidad de trabajos de los cuales un equipo podría estar encargado durante períodos de tiempo (en la Parte I ya comenté que esto, aunque NO es lo más deseable, suele ocurrir :-) y no es fácil de evitar). En cada caso debería realizarse la configuración del proceso que se aplicará.

Esta diversidad tampoco implica tener obligatoriamente un proceso a medida para cada unidad de trabajo, o cada producto, servicio o proyecto. En la práctica simplemente hay que tener un conjunto de workflows (ver Workflows Flexibles) que acumulen la experiencia de proceso del equipo ante determinados tipos de trabajo. La definición de estos  workflows resuelven directamente una parte de la planificación y seguimiento puesto que cuando una unidad de trabajo sigue un workflow tenemos una previsión de las actividades que se realizarán sobre ella y el seguimiento básico es conocer en qué actividades del workflow se encuentra cada unidad de trabajo. Este seguimiento esencial se debería apoyar con un tablero kanban (no estoy hablando de el Método Kanban de David Anderson, solo del tablero kanban, que de paso también es utilizado en dicho método) . El problema es que cuando nos enfrentamos a la diversidad antes indicada necesitamos un tablero kanban más versátil (ver algunos Desafíos para la aplicación efectiva de Scrum + Kanban = Scrumban).

Más adelante en este post seguiré comentando respecto del tablero kanban. Centrémonos ahora en la clasificación que os propongo. En general existen dos tipos de trabajo, los denominaré Orientado a Flujo y Orientado a Sprint/Proyecto.

Trabajo Orientado a Flujo

Un trabajo Orientado a Flujo es aquel para el cual no es conveniente hacer planificación y seguimiento respecto de un compromiso o previsión de terminación. A priori cualquier trabajo podría ser planificable, sin embargo, la planificación pierde protagonismo o resulta poco rentable cuando el trabajo pendiente cambia continuamente (y no se pueden predecir dichos cambios), o cuando más importante que generar grupos de unidades de trabajo terminadas en un determinado plazo es generar un flujo continuo de unidades de trabajo terminadas a lo largo del tiempo. En este caso se reemplaza la planificación continua por la continua priorización del trabajo. El desempeño de un trabajo Orientado al Flujo se mide en términos de parámetros tales como: Cycle Time (tiempo desde que se empieza un trabajo hasta que se termina), Lead Time (tiempo desde que se registra el trabajo como pendiente hasta que se termina) y Production Rate (número de unidades de trabajo terminadas por unidad de tiempo). En este contexto se suelen establecer SLAs (Acuerdos de Nivel de Servicio) que determinan ciertos objetivos respecto de parámetros tales como los indicados antes. También, y relacionado con alcanzar un buen flujo, es importante supervisar el WIP (Work in Process) para detectar y resolver posibles cuellos de botella. Los siguientes son ejemplos de trabajo para los cuales es más conveniente generar flujo de unidades de trabajo terminadas que planificar unidades de trabajo en el marco de un Sprint o de un proyectos:

• Atención o soporte al cliente 
• Solución de incidencias
• Mantenimiento correctivo o de pequeñas mejoras en un producto
• Otros trabajos donde existan workflows y la demanda (unidades de trabajo que se reciben) no es controlable, es decir, simplemente se va recibiendo y según ciertas políticas se va atendiendo. En este caso estaría los procedimientos administrativos en general, en los cuales los "expedientes" (por usar un nombre para la unidad de trabajo) se van atendiendo según orden de llegada, prioridad, urgencia u otros criterios.   

La técnicas recomendada para realizar el seguimiento y la mejora del proceso en un contexto orientado al flujo son el tablero kanban (ver Kanban for free: una evaluacion informal de 5 herramientas gratuitas) y la Gráfica de Flujo Acumulado (Cumulative Flow Diagram, CFD), (ver Limitar el WIP una buena idea pero con matices y alternativas).

Tablero kanban

Cuando un equipo esté encargado de varios productos, servicios o proyectos, no nos bastará con cualquier tipo de tablero kanban . Lo ideal es que el tablero kanban sintetice todo el trabajo del equipo y a la vez, de una manera sencilla, permita visualizar dicha información filtrada por producto/servicio, proyecto, miembro del equipo, etc., y que también ayude a localizar rápidamente un cierta unidad de trabajo. El equipo deberá tener una estrategia para distribuir su capacidad cuidando el no penalizar demasiado su rendimiento en los cambios de contexto al pasar de un producto/servicio o proyecto a otro durante un mismo período. El tablero kanban debería ayudar a seleccionar correctamente el trabajo que debe ser realizado en cada momento por los miembros del equipo. La siguiente figura muestra una parte del kanban de nuestra herramienta TUNE-UP Process, en el cual en el grid de la izquierda se tiene una lista de actividades con las contabilizaciones de unidades de trabajo en cada una de ellas, separando por estado To Do y Doing. Seleccionando en una celda en el grid de la derecha se puede ver la lista de unidades de trabajo en dicha actividad-estado. Sobre esta información se pueden aplicar los filtros y la búsqueda antes indicada.

Así, un tablero kanban ofrece una excelente visualización de dónde están las unidades de trabajo respecto del su workflow (el proceso definido por las actividades por las cuales pasan las unidades de trabajo que siguen dicho workflow). Lectura recomendada Multi-kanban, un tablero kanban para contextos multi-proyecto.

Gráfica de Flujo Acumulado (Cumulative Flow Diagram - CFD)

La siguiente figura muestra en las columnas de tabla de la izquierda los snapshots con contabilizaciones del WIP en cada actividad del tablero kanban. La Gráfica de Flujo Acumulado de la derecha muestra cómo un aumento del ancho de una franja (el WIP de una actividad del proceso) alerta de un posible cuello de botella.

 

Trabajo Orientado a Sprint/Proyecto

Un trabajo Orientado a Sprint o Proyecto es un trabajo planificable, es decir, que antes de comenzar a ejecutar el trabajo se puede/debe identificar, organizar y estimar las unidades de trabajo necesarias para obtener un resultado en un plazo establecido y con la restricción de capacidad del equipo para dicho trabajo. En esta situación suele existir compromiso o pronóstico asociado a completar un cierto alcance, en un determinado plazo, y con determinados recursos. Para que un trabajo sea planificable debe cumplirse que éste, al menos en gran parte, pueda ser definido con anticipación y/o que no sufra modificaciones significativas durante su ejecución. El límite está en el punto en el cual ya no tiene sentido intentar re-planificar y hacer un seguimiento al respecto cuando el plan se modifica con demasiada frecuencia. En las metodologías ágiles se promueve la planificación y el seguimiento continuo, alineado con la idea de conseguir  entregas frecuentes de trabajo terminado. Sin embargo, como se trabaja con ciclos cortos (Scrum recomienda sprints de menos de 4 semanas y Extreme Programming de menos de 3 semanas), se sugiere que mientras no se trate de una urgencia, no se altere el contenido de un sprint. El desempeño de un trabajo planificable se mide considerando el grado de terminación de las unidades de trabajo acordadas para terminar en el Sprint.

La técnicas que recomiendo para realizar el seguimiento y la mejora del proceso en un contexto orientado a Sprint o Proyecto son el tablero kanban, la Gráfica Burndown (ver Gráficas Burndown: ¿Cómo rentabilizar el esfuerzo para elaborarlas?) y la Gráfica de Trabajo Finalizado (que muestra la proporción del trabajo terminado respecto del trabajo pendiente). Nótese que el tablero kanban es la técnica básica que recomiendo usar tanto para un trabajo Orientado a Flujo como para uno Orientado a Sprint o Proyecto.

Gráfica Burndown y otras complementarias

La siguiente figura muestra una Gráfica Burndown. La línea roja representa el esfuerzo restante día a día durante un Sprint o Proyecto, el cual debe evaluarse respecto de la línea de referencia (la línea morada) que converge hacia 0 en el día de finalización del Sprint o Proyecto. La línea azul es el Burn-up, el esfuerzo invertido y la línea verde es el esfuerzo estimado.

Puede que el trabajo restante muestre una buena tendencia pero que todas las unidades de trabajo estén sin terminar y posiblemente acumulándose en las últimas actividades del proceso. Para anticiparse a esta anomalía se recomienda complementar el Burndown con la Gráfica de Trabajo Finalizado como la mostrada en la siguiente figura, donde la parte naranja de la barra representa el esfuerzo asociado a unidades de trabajo no terminadas y la parte verde corresponde al esfuerzo de las unidades de trabajo ya terminadas.

Si queremos tener una visualización integrada del estado de varios Sprints y/o Proyectos hemos elaborado la siguiente gráfica, la cual es una adaptación de la representación sugerida por J. R. Holt (ver How to Get Things Done, Visual project management shows the way). En esta gráfica cada punto representa un Sprint o Proyecto. En el eje Y se representa el % de progreso del trabajo, medido como el esfuerzo invertido respecto del esfuerzo total estimado. El eje X representa el progreso del tiempo, medido como el tiempo transcurrido desde el comienzo del Sprint o Proyecto hasta el día actual respecto del tiempo total.

A continuación se nuestra cómo hemos implementado dicha visualización en TUNE-UP Process  Nótese que para la correcta interpretación de la gráfica todo el trabajo del proyecto debe estar estimado (pues sino no estaríamos considerando todo el esfuerzo asociado) y no deben sobrepasarse dichas estimaciones (pues el trabajo restante tendría un valor negativo). En la gráfica, estas advertencias se destacan poniendo en negrita y con un asterisco el nombre del proyecto, y además, el bocadillo que se muestra al poner el cursor sobre un proyecto indica en sus últimas líneas dichas advertencias respecto del número de unidades de trabajo en dicha situación anómala. 

Haciendo doble click sobre un proyecto se puede acceder a su dashboard, del cual se muestra con un ejemplo en la siguiente figura. 

Desde el dashboard se puede acceder a la lista de unidades de trabajo o directamente al detalle de una unidad de trabajo, ambos casos ilustrados a continuación:

Conclusiones

Primero debo insistir en que un ambiente multi-proyecto NO es lo óptimo para el rendimiento del equipo. Existirá una reducción del desempeño del equipo por tener que estar cambiando de contexto entre diferentes trabajos, ocurriendo algo similar a lo que pasa en un proyecto cuando los participantes intentan avanzar en paralelo muchos ítems asociados de dicho proyecto. La recomendación es similar a la ofrecida en el marco de un proyecto: reducir/limitar el WIP, pero en este caso a nivel del conjunto de proyectos asignados al equipo. Según esto, lo primero que habría que hacer es intentar reducir la cantidad de proyectos encargados a un equipo. Las decisiones al respecto deben ser tomadas por la dirección pues conllevará seleccionar los proyectos más prioritarios, postergar el comienzo de ciertos proyectos, suspender temporalmente algún proyecto, etc. Probablemente aún después de tomar estas decisiones, el equipo siga teniendo asignado varios proyectos :-(, con lo cual el siguiente paso es proporcionar pautas claras respecto de cómo el equipo debe distribuir su capacidad. Para cada tipo o línea de trabajo encargada a un equipo debería identificarse su orientación (Flujo o Sprint/Proyecto). Dependiendo de la orientación, se aplicarían las técnicas indicadas, teniendo el tablero kanban como técnica base aplicable siempre e independiente de la orientación del trabajo. Para los trabajos con Orientación al Flujo deberían establecerse "reservas de capacidad" (esfuerzo que dedicará el equipo por día, semana o mes). Para los trabajos con Orientación a Sprint/Proyecto debería distribuirse la capacidad restante. Así, el equipo intentará en un cierto período de tiempo cumplir con dichas directrices en cuando a distribución de su capacidad. Especialmente para el caso de Orientación a Sprint/Proyecto, mientras mayor sea el período utilizado mejor será para el equipo, por ejemplo, si el equipo tiene que dedicar un cuarto de su capacidad para un proyecto, mejor es que el equipo dedique una semana del mes a dicho proyecto, en lugar, por ejemplo, que esté dedicando un cuarto de cada día a dicho proyecto.

Por otra parte, una visión más "ejecutiva" y realista del agilismo (que complementa a las más usuales, centradas más en presentación de metodologías y prácticas ágiles, e ignorando los desafíos del trabajo multi-proyecto) debería ayudar para conseguir el apoyo de los niveles más altos de la organización y entidades del tipo PMO para implantar prácticas ágiles, puesto que podemos demostrar que:

• La planificación y seguimiento ágil puede ser tan o más rigurosa que la ofrecida en enfoques tradicionales. 
• Es posible reducir o evitar el interrumpir a los equipos o ciertos miembros para que éstos recolecten datos y preparen estados de situación de su trabajo. Esta información resumida, que está orientada hacia la supervisión global y periódica que requieren los niveles superiores, no suele rentabilizarla el equipo en su trabajo diario. Si conseguimos que la disciplina de trabajo del equipo conlleve de forma natural y en el momento la recopilación de dicha información este esfuerzo se verá recompensado por el ahorro de todo el esfuerzo gastado a causa de dichas interrupciones. Además, los niveles superiores pueden realizar la supervisión en cualquier momento y sólo intervenir puntualmente cuando sea necesario.

La clave para el éxito del enfoque presentado y para mantenerse fiel a los principios ágiles es que toda la recolección y síntesis de la información para el seguimiento se realice de forma automática sin suponer un esfuerzo adicional para los equipos.Además, se ofrecen mecanismos para que el registro de progreso del trabajo (cuando este registro se considera necesario) se realice de forma semi-automática.

En Tune-up Process hemos abordado todas las funcionalidades comentadas y enfrentado muchos detalles adicionales, pero esto sería largo para explicar en un post :-).



Patricio Letelier

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

Agilidad en un contexto multiproyecto, Parte I: Proyectos-Productos-Servicios

Gestionar simultáneamente múltiples proyectos es un gran desafío, y tiene mucho de malabarismo.

Dos situaciones me han motivado a escribir este post. La primera es que más que una excepción, es casi una regla que un equipo de trabajo es responsable de más de un producto o servicio. Cuando todo el equipo está 100 % dedicado en un solo proyecto, la planificación y seguimiento se simplifica considerablemente. La mayoría de la literatura ágil asume esta condición favorable (que el equipo trabaja en solo un proyecto a la vez) o simplemente ignora dicha situación multi-proyecto. Por otra parte, el agilismo encuentra un importante obstáculo respecto de cómo convivir con (o cambiar) las prácticas tradicionales de planificación y seguimiento de proyectos, especialmente en organizaciones de mayor tamaño y/o donde hay prácticas tradicionales institucionalizadas, y posiblemente promovidas por una PMO (Project Management Office) o entidad similar. Así pues, pienso que es clave dotar de una visión "ejecutiva" al agilismo, para poder convencer de sus bondades y conseguir ese apoyo imprescindible de los niveles altos de la organización. Hasta ahora lo que más he visto/leído al respecto corresponde a una estrategia de confrontación con la gestión tradicional de proyectos. Mi recomendación como estrategia, y sin ceder un ápice respecto de las prácticas ágiles asociadas, es ilustrar y demostrar que la planificación y el seguimiento ágil son efectivos, y especialmente, que pueden reportar información del estado de los proyectos tan o más completa y rigurosa como la que se haría con un enfoque tradicional. Esto último es lo que debería enfatizarse como argumento y como punto de encuentro y convivencia con otros enfoques más tradicionales.  

En esta Parte I voy a presentar la problemática y establecer la terminología para, posteriormente en la Parte II mostrar nuestra visión respecto de cómo abordarlo.

El término "proyecto" suele resultar ambiguo cuando se utiliza para referirse a cualquier trabajo que desarrolla un equipo. En el PMBOK "proyecto" se define como el esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado, y que en cada cualquier éstos sean únicos. Aquí "únicos" se usa para para diferenciar proyecto respecto de "operaciones", las cuales de forma repetitiva producen productos u ofrecen servicios. Es importante puntualizar el significado de proyecto puesto que en el agilismo se enfatiza más el concepto de producto o servicio, pues se desea por ejemplo, establecer un buen flujo de trabajo terminado asociado a un servicio, o se desea hacer entregas frecuentes de nuevas versiones de un producto. Si bien cuando sólo interesa generar un buen flujo estaríamos más cercanos a "operaciones", cuando se hace una entrega frecuente de versiones de un producto la diferencia entre proyecto u operaciones puede no ser tan clara. Proyecto debería en un contexto ágil interpretarse como un sinónimo de Release (o entrega a producción) de un nuevo producto, o la creación de un nuevo servicio, o incluso un cambio o remodelación significativa de un producto o servicio (la cual conllevará un esfuerzo y tiempo importante).

Dicho lo anterior, un equipo puede estar ligado a varios productos o servicios. Por contraparte, un producto o servicio podrá estar ligado a varios equipos responsables de diferente proyectos (por ejemplo el equipo que lo crea o el equipo asociado a una remodelación importante) o equipos de operaciones (por ejemplo, el equipo de mantenimiento o el equipo de soporte). Así pues, la siguiente imagen ilustra la relación muchos-a-muchos entre equipo y producto/servicio.

Obviamente, esta situación "muchos-a-muchos" no es la más apropiada ni para el desempeño del equipo ni para el desarrollo o mantenimiento eficiente del producto o servicio. El equipo en esta situación debe distribuir su capacidad en la atención de varios productos o servicios, y los cambios de contexto penalizarán su desempeño. Esta situación es similar a la que se presenta cuando existe un WIP (Work in Process) demasiado alto en alguna actividad de un tablero kanban, el efecto negativo es el mismo, el alternar entre un trabajo y otro, sin privilegiar la finalización un determinado trabajo, reduce el desempeño del equipo. Pero limitar el WIP a nivel de ítems de trabajo es más sencillo que limitar el número de productos o servicios de los cuales es responsable un equipo, lo cual no suele ser decisión del equipo, sino de más alto nivel. Por otra parte, la tendencia en grandes empresas no suele ser crear equipos por producto o servicio. Así pues, tal como se refleja en la siguiente imagen, el trabajo sobre un producto o servicio lo pueden realizar diversos equipos, muchas veces creados puntualmente para un proyecto, o equipos externos encargados del outsourcing de ciertas actividades. Los protocolos de interacción entre estos diferentes equipos suelen penalizar el desempeño del producto o servicio visto de forma global.

Podríamos promover que se evite o reduzca dicha situación "muchos-a-muchos", sin embargo, no se trata de una decisión sencilla y rápida de implantar. Además, el tener diferentes equipos realizando trabajo sobre un mismo producto o servicio también tiene sus ventajas. Por ejemplo, basta pensar en el impacto que tendría prescindir del Outsurcing de actividades o de un área de QA, y la resistencia que encontraríamos para intentar hacerlo. Así pues, de antemano debemos estar preparados para ofrecer una forma se abordar de la mejor manera dicha situación, probablemente conviviendo con ella o haciendo mezclas. Por ejemplo, un Outsourcing in-situ, contando con el personal del proveedor en nuestra empresa no representa ningín inconveniente mayor de cara a nuestro propósito de aglutinar equipo. Si ponemos como condición previa a la implantación de agilismo que dicha situación "muchos-a-muchos" no exista, probablemente ni siquiera se llegue a disponer de una oportunidad para introducir agilismo en dicho contexto.

En mi opinión, la mejor forma de conseguir el apoyo de los altos ejecutivos para la introducción del agilismo (más allá de explicarles las bondades de la cultura y prácticas ágiles) pasa por dar respuesta a los siguientes desafíos (sin renunciar a los principios ágiles):

1. Realizar la planificación y el seguimiento de los diferentes productos, servicios y/o de sus proyectos asociados.
2. Coordinar los diferentes equipos que trabajan en un producto o servicio.
3. Abordar eficazmente con un mismo equipo trabajo en varios productos o servicios durante un mismo período de tiempo.
4. Supervisar el trabajos de diferentes equipos, disponiendo de reportes de estado que puedan equipararse a los que suelen disponer en proyectos tradicionales.

Cada uno de estos puntos los desarrollaré en detalle en la Parte II. Ahora concluiré esta primera parte enfatizando la gran oportunidad de mejora que en general se puede tener respecto del punto 4. 

La forma en la cual se generan los reportes de estado en un contexto tradicional suele constituir una gran fuente de desperdicio ("waste"). A pesar de que la información de estado se genera a nivel operativo en cada equipo, ésta no suele ser aprovechada (al menos no restabilizada del todo) en el día a día del trabajo del equipo, y solo se recolecta de forma periódica para elaborar informes dirigidos a niveles superiores de supervisión. Por ejemplo, la gerencia pide informes a los departamentos, éstos a las unidades departamentales, éstas a los jefes de proyecto, y éstos finalmente recolectan la información que les proporcionan los miembros del equipo, por ejemplo, registrándola una vez a la semana. La siguiente imagen ilustra esta situación.

Las interrupciones y el tiempo invertido en dicha recolección de información y preparación de datos puede (y debería) evitarse. Hay que conectar el registro de dicha información con el trabajo díario de los miembros del equipo, de forma que el registro y recolección se realice de forma semi-automática. Además, hay que automatizar la elaboración de dichos reportes de estado, y finalmente, hay que promover una política de transparencia en cuanto a que dicha información esté disponible en todo momento y para todos los que la necesiten. 

Continúa en  Parte II: Planificación y Seguimiento ...

Patricio Letelier

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

Estimación en un proyecto ágil, Parte II: Algunas diferencias respecto de estimación tradicional

¿Qué diferencias puede tener la estimación en un contexto ágil respecto de uno tradicional?. Las estimaciones son protagonistas al  evaluar la factibilidad de un proyecto, al establecer su planificación y para realizar su seguimiento. En un enfoque ágil dichas actividades también están presentes pero con características especiales que obligan a replantearse cómo hacer las estimaciones e incluso si vale la pena hacerlas. Este post es la continuación de "Estimación en un proyecto ágil: Parte I".

Un primer punto a destacar es que en un contexto ágil los ítems de trabajo deberían ser, en general, elementos de valor de cara al cliente. Es decir, los ítems deberían ser cambios en el producto o servicio que recibe el cliente. Aunque el equipo pueda descomponer un ítem de trabajo en tareas técnicas, lo relevante en términos de satisfacción del cliente es la entrega del ítem de trabajo como un todo y desde su perspectiva. Además, un ítem de trabajo debe tener una granularidad consecuente con las entregas frecuentes que se esperan realizar. A modo orientativo si un ítem de trabajo es una Épica, es decir , es demasiado grande/complejo para terminarlo en una semana (considerando la Capacidad del equipo), habría que descomponerlo en partes o incrementos que permitan hacer una entrega parcial. Pero dichas partes o incrementos deberían ser establecidos desde la perspectiva del cliente, es decir, apreciables por él como una entrega parcial.

Las estimaciones en sí mismas no aportan valor al cliente, con lo cual de entrada podrían ser prescindibles :-). No estimar es una opción válida en contextos de trabajo muy favorables para el enfoque ágil. Por ejemplo, cuando existe una estrecha colaboración y complicidad con el cliente y él está satisfecho consiguiendo continuamente funcionalidad, cuando la planificación es a corto plazo y solo se establece el Sprint actual y quizás el próximo, o cuando simplemente no se usan Sprints y se pone el foco en generar un buen flujo de trabajo terminado con entregas frecuentes, pero sin planificación a priori. Es decir, en un contexto muy flexibile, con constante posibilidad de negociación del alcance y plazos, la estimación podría ser prescindible. Desgraciadamente, aunque dichas condiciones favorables serían ideales para una aplicación del enfoque ágil, no es lo usual, ya que cuestiones contractuales tradicionales tienden a establecer compromisos de alcance, plazos y costos bajo condiciones poco flexibles. De todas formas, aunque fuera posible prescindir de las estimaciones, siempre puede rentabilizarse el esfuerzo invertido en ellas, por el simple hecho de que una estimación conlleva la definición, al menos preliminar, del trabajo que se va a realizar, lo cual es importante en ciertos ítems de trabajo que por envergadura o complejidad requieren una evaluación preliminar que nos advierta del desafío que involucran. 

La estimaciones conllevan un nivel de precisión esperado el cual está condicionado por el nivel de definición de la unidad de trabajo. Obviamente la precisión de dicha estimación es mayor mientras más nos acercamos al término de la implementación del trabajo :-). Sin embargo, desde el momento de la identificación de un ítem de trabajo es interesante poder contar con una estimación al menos preliminar.

Estimación usando Puntos. Un punto es una medida de tamaño relativa a una unidad de trabajo de referencia. La estimación en Puntos puede ser consensuada fácilmente por el equipo, utilizando por ejemplo Planning Poker, donde los Puntos corresponden a una escala de Fibonacci modificada. El equipo establece una unidad de trabajo de referencia y le asigna unos determinados Puntos, así la estimación de cualquier otra unidad de trabajo se hace por comparación de tamaño respecto de la referencia establecida. Por ejemplo, si la referencia tiene 3 puntos, a una unidad de trabajo del doble de tamaño se le asociarían 6 Puntos, a una de la mitad 1.5 Puntos, una que es cuatro veces más grande 12 Puntos, etc. En todo caso por tratarse de estimaciones no tiene mucho sentido trabajar con decimales o complicarse por una precisión de un punto de más o de menos. Si además el equipo mantiene un registro de su capacidad en Puntos (registro de cuántos Puntos ha podido realizar en un cierto período de tiempo), dispondría con ello de un mecanismo probablemente suficiente para una evaluación de factibilidad y/o planificación global de sus Sprints o Proyectos, todo ello con muy poco esfuerzo y de forma temprana. Por ejemplo, si el equipo en el último Sprint terminó un conjunto de unidades de trabajo que sumaban 50 puntos, si planificamos un próximo Sprint (de la misma duración y con condiciones similares de trabajo para el equipo) sería razonable prever que se puede realizar un nuevo conjunto de unidades de trabajo cuya suma de Puntos no sobrepase 50 Puntos (la Capacidad actual del equipo).

Algunos inconvenientes de la estimación usando Puntos. Antes es importante insistir en que usando Puntos como una medida global del tamaño de cada unidad de trabajo y contrastándolo con la Capacidad disponible del equipo para un Sprint o Proyecto podría ser suficiente para gestionar el alcance durante el desarrollo del trabajo. Sin embargo, desde el punto de vista del seguimiento diario del trabajo restante (por ejemplo, en una gráfica Burndown) la pregunta ¿cuánto esfuerzo nos queda para terminar?, responder esto en Puntos no resulta tan directo, como tampoco el hacer un ajuste en la estimación cuando se detecta que se requerirá más o menos que el esfuerzo previsto. Si se trabaja con Puntos deberíamos esperar a que el trabajo termine para descontar los Puntos que se estimaron para él. Además, una estimación en Puntos se hace como una valoración global del esfuerzo de un ítem de trabajo, sin distinguir los esfuerzos particulares asociados a cada actividad que debe realizarse sobre ella. Podríamos tener una estimación para cada actividad que pensamos llevar a cabo en el ítem de trabajo, por ejemplo, estimar el esfuerzo de analizar, de implementarlo y de probarlo, etc., pero NO es lo que se pretende cuando se hace una estimación en Puntos. Al estimar usando Puntos se busca una estimación a nivel global, es decir, se quiere dimensionar el ítem de trabajo como un todo, no a nivel de actividad. Sin embargo, si durante el seguimiento queremos conocer el estado de avance en términos de esfuerzo restante, normalmente éste esfuerzo lo necesitaríamos a nivel de actividad, y no tiene sentido preguntarse cuántos Puntos le restan a una actividad, menos si la estimación inicial se hizo a nivel global. Por ejemplo, no tendría sentido preguntarle a un programador cuántos Puntos le faltan para terminar un ítem de trabajo. Finalmente, los Puntos son una medida relativa y en el marco de trabajo de un equipo, lo cual impediría obtener estadísticas de esfuerzo y capacidad más allá del ámbito de cada equipo. Paradójicamente y confirmando estos inconvenientes asociados a trabajar con Puntos, he leído en repetidas ocasiones comentarios recomendando establecer equivalencias entre un Punto de Historia de Usuario o de Tarea con semanas, días u horas, intentando hacer más intuitivo el concepto de Punto :-). Si al estimar en Puntos hacemos una correlación con tiempo de trabajo lo mejor es reconocer que NO estamos estimando en Puntos sino en tiempo (como comento a continuación).

Estimación usando Horas Ideales. Por los inconvenientes indicados, cuando es necesario un seguimiento más detallado (vuelvo a insistir que depende del contexto, y puede que NO se requiera ese detalle), de forma alternativa o complementaria se puede usar Horas Ideales. Una Hora Ideal es una hora ininterrumpida de trabajo, es decir, al estimar en Horas Ideales se piensa (idealmente) como si el trabajo se fuera a realizar en horas continuas, sin considerar pausas ni interrupciones. Normalmente cuando establecemos, por ejemplo, que una unidad de trabajo tomará 10 horas de programación, lo estaríamos haciendo de forma intuitiva y fácil pensando solo en el tiempo que se invertiría si se trabajara de forma continua y sin interrupciones. Luego en la práctica ese trabajo podría cronológicamente llevarse a cabo, por ejemplo, durante una semana puesto que desde cuando se empiece podría tener interrupciones, es decir, puede que no se llegará a trabajar continuamente 10 horas en dicha actividad, pero con respecto a comparar la Capacidad disponible con el Esfuerzo Estimado habremos conseguido nuestro propósito. Por otra parte, cuando el programador responsable reflexione respecto al esfuerzo restante para acabar la programación de la unidad de trabajo, le será sencillo volver a establecer las Horas Ideales que estima que le restan de trabajo,o si es necesario hacer ajustes a dicha estimación. Según lo anterior, es muy importante hacer la diferencia entre la estimación (en Horas Ideales) y la previsión o compromiso de término de un ítem de trabajo, esto último dependerá de la previsión de disponibilidad de tiempo que se tenga para realizar el trabajo y las interrupciones que podrían ocurrir. Esto es extensible al ámbito del Sprint o Proyecto como un todo, es decir, por una parte existe una estimación de esfuerzo y por otra la Capacidad que se prevé que el equipo tiene en el período de tiempo dentro del plazo de entrega.
Sigamos entonces comentando la estrategia de estimación usando Horas Ideales y a nivel de actividad realizada sobre un ítem de trabajo. Dichas actividades corresponden al workflow que sigue la unidad de trabajo, es decir, en términos de un tablero kanban, dichas actividades son las columnas por las cuales pasa el ítem de trabajo (como si fuese el post-it que transita en el tablero kanban). ¿Interesa estimar todas las actividades por las cuales pasará el ítem de trabajo?. Categóricamente NO, primero porque hay algunas actividades para las cuales a priori sería difícil prever cuánto esfuerzo requerirán (por ejemplo, cuánto se tardará en definir una unidad de trabajo sin todavía conocer más detalles de ella, detalles que se irían descubriendo durante esa misma actividad), además, habrá actividades que consumen un esfuerzo despreciable que no merece la pena estimar. Por otra parte, siempre podemos separar las actividades en dos grupos, las de preparación que normalmente deberían realizarse mientras la unidad de trabajo está en el Backlog, y las de implementación, aquellas actividades que se realizarán en el Sprint (cuando no se usa Sprints podemos considerar que todo el trabajo se realiza directamente sobre el Backlog). Como el propósito es establecer Sprints que supongan un esfuerzo que no supere la Capacidad del equipo, las actividades interesantes para ser estimadas y así establecer el esfuerzo asociado al Sprint serán aquellas que se realizan durante el período del Sprint. Más aún, NO es necesario/rentable realizar estimaciones para todas las actividades de implementación. La TOC (Theory of Constraints, propuesta por Goldratt) sugiere que para mejorar un proceso de producción hay que poner atención y centrarse en mejorar las actividades que constituyen una limitación para el sistema (aquellas que pueden constituir un cuello de botella). Así pues si identificamos una actividad que por escasez de Capacidad para realizarla (u otros motivos) es un posible cuello de botella, dicha actividad debería ser aquella para la cual se realice una estimación y para la cual correspondientemente se tenga un registro de la Capacidad del equipo. En desarrollo de software, los cuellos de botella en un Sprint podrían darse en algunas actividades asociadas a programación y/o a pruebas. Así pues, por ejemplo, si la capacidad en Horas Ideales de programación por semana para un equipo de desarrollo fuera de 200 horas, cuando se esté planteando un próximo Sprint de 3 semanas, la suma de las estimaciones de esfuerzo de programación para los ítems de trabajo asignados al Sprint no debería superar las 600 horas (ni tampoco ser mucho menor que ello).

Las estimación pueden variar según la experiencia/habilidad de quien ejecutará el trabajo. Este aspecto es muy importante pero debería ser circunstancial, es decir, solo debería ocurrir en determinadas situaciones, por ejemplo, cuando se trata de un trabajo totalmente nuevo para el equipo o cuando en el equipo exista una deferencia significativa entre el desempeño de sus integrantes ante la realización de un mismo ítem de trabajo. Podría ser el caso de una persona recién incorporada que requiere un período de formación y entrenamiento, luego del cual debería ir poniéndose a nivel del resto de miembros del equipo (el trabajo en parejas puede ser un medio para nivelar rápidamente el desempeño de un nuevo miembro). En un caso extremo, si se tratase de una persona que no llega a ponerse al nivel de rendimiento del resto del equipo posiblemente habrá que tomar la decisión de sacarla de ese equipo. Este inconveniente se puede presentar independientemente de la unidad de esfuerzo que se utilice, Puntos u Horas Ideales, aunque puede resultar más evidente la diferencia de estimación en dos personas con rendimiento muy desigual cuando se estima en Horas Ideales. Respecto del caso cuando se trata de un trabajo para el cual el equipo no tiene experiencia, lo que sugiere Extreme Programming (XP) es realizar un skipe, es decir, una exploración o investigación para conseguir mayor información respecto del esfuerzo que podría requerir dicho trabajo. Es decir, no debemos caer en la tentación de engordar la estimación solo porque no se tiene experiencia. Si abusamos de esto probablemente se caiga en la Ley de Parkinson ("La duración del trabajo se extiende hasta agotar el tiempo disponible para realizarlo"). Además, la recomendación es que la estimación de cada ítem de trabajo sea más bien agresiva, y en lugar de añadir holguras para cada ítem establecer explícitamente un búffer de Capacidad para el Sprint o Proyecto, del cual puedan disponer los ítems que lo necesiten y los cambios menores que aparezcan (lectura recomendada: Búffer de Capacidad para proyectos ágiles).

Finalmente, la estrategia de gestión del esfuerzo y en particular la asociada a estimación debe ser evaluada para cada línea de trabajo del equipo, es decir, un mismo equipo se podrían aplicar diferentes estrategias a los distintos productos o servicios con los cuales trabaja.

En nuestra metodología y herramienta TUNE-UP realizamos dicha configuración de la estrategia de estimación para cada producto o servicio. Sin embargo, de forma integrada se puede realizar el seguimiento de todos los Sprints (incluyendo también el seguimiento para aquellos productos o servicios que no requieren Sprints o estimación). Aunque difieran en cuanto a la estrategia de estimación, cada producto o servicio dispondrá de sus correspondientes mecanismos para el seguimiento, pudiendo corresponder a una implantación pura del método Kanban, una más cercana a Scrum, o incluso una aproximación mixta.

Patricio Letelier

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