jueves, 29 de junio de 2017

Tableros kanban en dos niveles: desde pedidos de una pizzería a gestión de portafolio

Advierto que este post no va de cómo se cocinan los proyectos :-), sino de unas interesantes analogías entre la gestión de pedidos en una pizzería y un portafolio de proyectos respecto de trabajar con tableros kanban sincronizados, en este caso tableros en dos niveles, un kanban general (pedidos de pizzas o portafolio de proyectos) y otro kanban detallado (pizzas y trabajo dentro de un proyecto).

Arranquemos con el ejemplo de la pizzería donde se reciben pedidos de pizzas. Un pedido puede incluir una o más pizzas de diferente tipo y tamaño (por ejemplo, pedido del Sr. Pérez: 2 margaritas medianas y una cuatro estaciones grande). Supongamos que en el trabajo de la pizzería para atención de sus clientes se identifican las siguientes actividades: Tomar Pedido, Preparar Masa, Añadir Ingredientes, Hornear, Armar Pedido y Entregar. El siguiente tablero kanban podría servir para visualizar el estado del trabajo.


Pero la pregunta clave es ¿qué ítems son los que aparecen en el kanban? ¿Representan los pedidos de pizzas o cada una de las pizzas de los pedidos?. Hay algunas columnas que delatan que el trabajo se hace a nivel de pedido (por ejemplo: Tomar "Pedido" o Entregar "Pedido") y otras en las que el trabajo se hace a nivel de pizzas (por ejemplo, Añadir Ingredientes). Claramente hay dos perspectivas del proceso, de cara al cliente es importante saber cómo va la elaboración de su pedido como un todo, y desde el punto de vista del trabajo interno de la pizzería lo que se manejan son pizzas. Entonces las alternativas de ítems a utilizar en nuestro tablero kanban serían: Pedidos, Pizzas (de un pedido) o incluso Pedidos y Pizzas (ambos tipos de ítems). Veamos las ventajas e inconvenientes de cada alternativa:

  • Ítems=Pedidos: Es más sencillo conocer el estado del pedido. Es más fácil la gestión de información pues siempre habrá menos pedidos que pizzas con lo cual el tablero tendrá menos ítems. Sin embargo, físicamente todas las pizzas del pedido deberían estar en la misma actividad a la vez (en la actividad que esté su Pedido) o tener algún truco para indicar que un pedido está en más de una actividad.
  • Ítems=Pizzas: Puede ser más difícil de gestionar el pedido pues las pizzas como ítems podrían estar en diferentes actividades, pero deben entregarse todas en conjunto (y calientes :-) ). Además, podemos llegar a tener muchos ítems en el tablero.
  • Ítems=Pedidos y Pizzas: Podría pensarse como una solución más detallada que combina algunas ventajas de las dos anteriores y aparentemenre reduciría sus inconvenientes, pero puede ser peor esta alternativa porque hay que gestionar dos típos de ítems a la vez y conjuntamente (el ítem Pedido y sus ítems Pizzas).

Probablemente ninguna de las alternativas anteriores resultará del todo cómoda pues lo que hay detrás de esta situación es que estamos mezclando dos niveles de trabajo (Pedidos y Pizzas incluidas en los pedidos). El trabajo y la gestión de ambos debe estar coordinado pero probablemente es más sencillo y fácil de gestionar si se representan estos dos niveles como dos tableros kanban coordinados. La siguiente figura muestra un ejemplo de lo que podrían ser estos dos tableros kanban.


Como en el kanban detallado tendremos pizzas de diferentes pedidos, deberíamos contar con un mecanismo para diferenciar los ítems e identificar fácilmente cuáles son de un mismo pedido (por ejemplo, con colores o etiquetas). En cualquier caso, y ya poniéndonos en terreno, sea cual sean los tableros e ítems utilizados, las pizzas en la cadena de producción normalmente se acompañan del ticket del pedido durante todo el proceso, y son los encargados quienes van verificando el avance en conjunto de todas las pizzas del pedido.

Una vez explicada la situación de la pizzería, llevémoslo al contexto de un portafolio de proyectos. En organizaciones con un cierto grado de madurez en la gestión de sus proyectos es normal que tengan definido un flujo de trabajo para sus proyectos, que incluya estados tales como: Propuesto, En Evaluación, En Ejecución, Cerrado, etc.. Los nombres y el detalle de estado pueden obviamente ser diferentes. Sin embargo, estos estados corresponderían con las columnas del tablero kanban que ilustraría el estado de los proyectos (el estado del portafolio de proyectos), es decir, sería un equivalente a los pedidos de la pizzería. Y además, la columna "En Ejecución" estaría detallada en otro(s) tablero(s) kanban que representarían el estado de ejecución de cada uno de los ítems en los proyectos. Por ejemplo, si fuera un proyecto de desarrollo de software el tablero kanban detallado (el equivalente al de las pizzas) contendría ítems del tipo Nuevo Requisito, Mejora o Corrección de fallo, y las actividades serían del tipo Especificación, Programación, Pruebas, etc. Así, en algún momento los ítems de un proyecto se terminan y el proyecto como un todo (en el kanban de proyectos) saldría del estado "En ejecución" pasando al siguiente estado en el kanban de portafolio. Tal como en el caso de las pizzas, los ítems de cada proyecto deberían poder distinguirse o filtrarse fácilmente (para evitar tener un kanban para cada proyecto).



Patricio Letelier

www.tuneupprocess.com 

sábado, 10 de junio de 2017

Sprints, "welcome to the real world" ...

Un Sprint es un contenedor/agrupador de ítems de trabajo que se implementan en un período de tiempo. El uso de Sprints se ha convertido casi en sinónimo de estar aplicando Scrum. Pero Scrum es bastante más que el solo concepto de Sprint. Además, el modelo de proceso iterativo e incremental no es una exclusividad de Scrum, también está presente en otros métodos ágiles, aunque en lugar de Sprint se utilizan el término Iteración. Incluso RUP, una metodología tradicional, sigue un proceso iterativo e incremental claramente basado en iteraciones. También se suele contraponer Scrum y Kanban en cuanto a usar o no usar Sprints. Vistos como métodos, Kanban no cuenta con el concepto de Sprint, y Scrum en su propuesta original no dispone de un tablero para visualizar el estado del trabajo (tablero kanban). Sin embargo, desde la perspectiva de prácticas ágiles, el uso de dicho tablero es fundamental siempre, y el uso (opcional) de Sprints es un excelente complemento para la organización del trabajo (lecturas recomendadas: ¿Kanban o Scrum?: that is not the question y Tableros kanban. Parte II: Diseño de tablero kanban para aplicarlo con Scrum).

En este post me centraré en ilustrar algunas variantes del concepto de Sprint en su aplicación en diferentes contextos de trabajo. Tener presente estas variantes es muy importante para hacer una buena adaptación metodológica al contexto de trabajo. Sin embargo, tampoco habría que desestimar la opción "cero", que sería simplemente NO usar Sprints :-). Pero de aquí en adelante en este post asumo que estamos en un contexto donde sí que es conveniente usar Sprints.  

En Scrum el concepto de Sprint es protagonista, aunque si no usáramos Sprints todavía tendríamos de Scrum otras prácticas ágiles que son muy interesantes, tales como: equipo auto-gestionado, equipo crosss-functional, los roles de Scrum, etc. Aunque básicamente un Sprint es una iteración, en Scrum establecen las siguientes características específicas:
  • Debe dar como resultado un incremento potencialmente entregable del producto.
  • No debería durar más de 4 semanas.
  • Debería comenzar apenas se termine el Sprint anterior.
  • Contiene ítems cuya suma de esfuerzo estimado debe ser coherente con la Capacidad del equipo. 
Estas características son sencillas y sensatas, pero al usar Sprints en un contexto específico suelen aparecer dudas, algunas de las cuales comento a continuación:

Contenido de los Sprints
  • A priori, se esperaría que al usar Sprints los ítems que se van a implementar en un Sprint estén predeterminados, ya que asumimos que el contexto de un Sprint es el de trabajo planificable (se conoce anticipadamente qué se hará en el Sprint). Además, durante el Sprint no debería haber demasiada presión por añadir ítems adicionales, considerando que su duración es de unas pocas semanas. El cliente puede que no vería resuelto su nuevo ítem al finalizar el Sprint actual, pero si dicho ítem tiene suficiente prioridad podrá incluirse en el siguiente Sprint. Sin embargo, si hay cierta urgencia se podría añadir el nuevo ítem al Sprint quitando otro equivalente en esfuerzo y que aún no haya sido implementado. 
  • Por otra parte, los Sprints pueden ser útiles en contextos NO planificables, es decir, donde no se conoce con exactitud qué trabajo se realizará en las próximas semanas. En estos casos el Sprint permite agrupar ítems de trabajo, aunque el contenido no será definitivo hasta que no se dé por terminado el Sprint. Por ejemplo, en un contexto de mantenimiento de un producto, al comenzar un Sprint se podría en extremo iniciarlo vacío, y en la medida que se van terminando ítems se van incluyendo (ya terminados) en el Sprint. Luego, en algún momento se decide cerrar el Sprint con el contenido de ítems terminados en ese instante. Otro escenario posible sería incluir en el Sprint un conjunto de ítems candidatos y que luego, cuando se considere conveniente, se terminaría el Sprint solo con los ítems terminados, y el resto de ítems se devolverían al Backlog para competir con otros ítems candidatos para el siguiente Sprint.
Regularidad de los Sprints
  • Tener Sprints de la misma duración genera una sana rutina de trabajo para el equipo. Esto además facilita el cálculo de la Capacidad del equipo, es decir, facilita el conocer cuántos Puntos u Horas Ideales (o cualquier otra unidad de medida que se utilice) podría abordar con éxito el equipo en un Sprint. 
  • Por otra parte, si durante el Sprint se detecta que no será posible terminar todos los ítems podría optarse por alargar el Sprint. Si esto se hace de forma habitual puede llevar a una relajación o falta de compromiso del equipo. Suele ser más recomendable terminar el Sprint en la fecha prevista y tomar oportunamente las acciones necesarias respecto a decidir qué ítems no se llegarán a terminar, o incluso para aquellos ítems ya comenzados crear un nuevo ítem que incluya el trabajo no realizado permitiendo así terminar el ítem original solo con la parte del trabajo ya hecha.
  • Hay situaciones en las cuales la demanda de trabajo no es previsible y fluctúa de forma importante. Por ejemplo, en un contexto de mantenimiento podemos pasar por períodos de mucho trabajo (después de una entrega de una versión con cambios importantes), y otros en los cuales hay poca demanda. En esta situación aún podría ser útil usar Sprints como agrupador, pero en este caso los Sprints podrían no ser ni continuos ni de la misma duración.
  • En cuanto al tamaño de los Sprints, ¿cuál es el tamaño aconsejable (considerando que no deben ser de más de 4 semanas)?. Mientras menos duración tengan los Sprints más frecuentemente podremos evaluar la buena marcha del trabajo. Sin embargo, el arranque y cierre de cada Sprint conlleva un esfuerzo (costes de transacción), y debe evaluarse hasta qué punto compensa realizarlo tan frecuentemente. Me refiero a actividades tales como las reuniones de planificación y de revisión del Sprint, el posible despliegue de la versión, pruebas (y especialmente pruebas de regresión), formación de usuarios, actualización de manuales, etc. Para un contexto nuevo de trabajo (nuevo en cuanto a los miembros del equipo, la tecnología utilizada, el dominio de aplicación, etc.) mi recomendación es comenzar con Sprints más bien pequeños, de 1 a 2 semanas, con el propósito de que el equipo aprenda y se adapte rápidamente. Luego, en un régimen de trabajo más estable recomendaría pasar a Sprints de 3 semanas. No me gustan los Sprint de 4 semanas y menos cuando se corresponden con meses de calendario pues prefiero que exista mayor atención (o inquietud) respecto a qué semana se termina un Sprint :-). 
Preparación de los ítems de cada Sprint
  • Para poder tener cierta garantía de cumplir con la implementación de los ítems incluidos en el Sprint debería existir coherencia entre la Capacidad del equipo y el esfuerzo requerido. Pero para hacer estimaciones de dicho esfuerzo con cierta precisión es necesario definir qué involucra cada ítem, es decir, saber cuáles son los requisitos asociados al ítem. Cada ítem necesita una "preparación", es decir, tareas relacionadas con la definición, especificación, validación, diseño y estimación (entre otras). Así pues, cada ítem del Sprint debería estar preparado antes de comenzar el Sprint. De esta forma, durante el periodo del Sprint el trabajo consistiría básicamente en implementar y probar cada ítem. La preparación de ítems de un próximo Sprint se debería hacer en paralelo a la implementación del Sprint actual. Particularmente, podría dejarse dicha preparación hacia el final del Sprint actual, cuando se va extinguiemdo el trabajo del Sprint actual y los miembros del equipo que vayan quedando sin trabajo en el Sprint actual puedan dedicarse a la preparación de ítems del Sprint siguiente. El caso extremo sería esperar a realizar toda la preparación en la Reunión de Planificación del Sprint, para la cual Scrum propone una duración de 8 horas (para un Sprint de 4 semanas). La razón de dichas 8 horas es precisamente porque se asume que los ítems que se incluirán en el Sprint podrían aún no estar preparados.
  • Si hay ítems incluidos en el Sprint y que no están preparados al comenzar el Sprint puede deberse a que simplemente no alcanzaron a ser preparados, y se tendrán que ir preparando durante el Sprint con el ruido que esto conlleve en la marcha del Sprint. También esa situación podría corresponder a una decisión estratégica para abordar un ítem de cierta complejidad, entremezclando su preparación e implementación, llevando al extremo el desarrollo incremental de dicho ítem. Obviamente, cuando no todos los ítems del Sprint están preparados y estimados hay más incertidumbre respecto a si se terminarán todos los ítems en la fecha de fin del Sprint.
Número de Sprints abiertos simultáneamente
  • En ediciones anteriores de la Guía de Scrum (scrumguide.org) se hablaba de la Release Planning Meeting, la cual consistía en establecer previamente cuáles serían los Sprints que conformarían una Release (Entrega). Por ejemplo, si teníamos una Release comprometida en 6 meses, podríamos planificar el contenido de 8 Sprints de 3 semanas cada uno hasta conseguir dicha Release. Sin embargo, muchas veces la dinámica del contexto de trabajo usualmente tira por tierra cualquier intento de planificación detallada a mediano o largo plazo. Por esto es más eficaz trabajar con un Backlog bien gestionado y ordenado, y luego a partir de él ir estableciendo solo el Sprint siguiente. Sin embargo, en la medida que se va extinguiendo el trabajo del Sprint actual podría abrirse ya el nuevo Sprint, aunque no necesariamente para comenzar a implementar sus ítems, sino solo como contenedor de los ítems candidatos que se están preparando para ese próximo Sprint. 
  • Otra situación en la cual puede ser útil tener varios Sprints abiertos, e incluso implementándose en paralelo, es cuando tenemos equipos diferentes trabajando sobre el mismo producto. Podría tratarse que equipos trabajando en diferentes áreas o subsistemas, equipos trabajando en mantenimiento o en desarrollo, etc. En esas situaciones puede que además sea conveniente que cada línea de trabajo tenga su propio Backlog y planificación de Sprints (aunque se trate del mismo producto). Indudablemente en estos casos se requiere una buena coordinación del entre los equipos involucrados.
Como hemos visto, el término Sprint da para mucho más de lo que plantea Scrum. En las implantaciones del enfoque ágil en las cuales he participado me ha resultado útil referirme a "Sprints" (a secas) cuando hablo de Sprints tal como los plantea Scrum, y usar el término "Sprints Flexibles" cuando hablo de Sprints que tienen alguna consideración especial de entre las comentadas antes. Los Sprints Flexibles son un aspecto clave para conseguir una conveniente adaptación de un proceso iterativo e incremental al contexto de trabajo de un equipo. No es necesario renunciar al uso de Sprints cuando no es posible aplicarlos tal como los plantea Scrum. Eso sí, un Sprint no es tal si no da como resultado un incremento del producto o si dura demasiado (orientativamente, más de cuatro semanas), estos dos aspecto son esenciales. Por otra parte, cuando existe una demanda constante de trabajo sobre un producto no hay excusas para no mantener una sana regularidad de duración (la misma duración) y continuidad (uno tras otro) de los Sprints.

Finalmente, y muy importante que cualquier decisión asociada a los Sprints (y otros aspectos de organización del trabajo) debe tomarse considerando las características de cada línea de trabajo, pues puede haber diferencias significativas entre una y otra. Aplicar de forma uniforme una decisión siempre es lo más sencillo, pero suele ser muy ineficaz cuando hay diferencias importantes entre las líneas de trabajo. Cuando digo "línea de trabajo" me refiero al desarrollo, mantenimiento o soporte, de un producto o de un servicio. No es lo mismo un contexto de desarrollo planificado respecto de uno de mantenimiento continuo, o de uno de soporte (donde no podemos prever el trabajo que llegará en las próximas semanas), incluso tratándose del mismo producto o servicio sus líneas de trabajo en general requieren un tratamiento particular. Lectura recomendada: Gestión ágil de productos. Líneas de trabajo en un producto a partir de su primera entrega.



Patricio Letelier

www.tuneupprocess.com