lunes, 31 de octubre de 2011

Workflows flexibles. Parte II: Características requeridas por workflows flexibles

El desarrollo de software exige un alto grado de colaboración/comunicación entre los agentes de un workflow, suelen aparecer situaciones imprevistas, y además, es inevitable la existencia de re-trabajo (trabajo asociado a una actividad después de haberse finalizado por primera vez). Así pues, para que los workflows sean útiles en desarrollo de software se requiere que sean Workflows Flexibles. La calificación de Workflow Flexible se refiere a que los workflows deberían actuar como una guía de referencia respecto de la vida que se espera que tenga un ítem desde su creación hasta entregarse implementado e incluido en una versión del producto. En un workflow para desarrollo de software no se debería pretender especificar explícitamente todas las posibles actividades ni conexiones entre actividades, tampoco deberían representarse las posibles situaciones de re-trabajo (vuelta atrás hacia actividades previas ya finalizadas). El workflow, en su definición, debería centrarse en flujo ideal.

Los ítems pueden necesitar un tratamiento diferente dependiendo del producto y tipo de ítem (u otros atributos del ítem). Así pues, los workflows representan las necesidades específicas para un tipo de item en un producto. Los workflows reflejarán el estado del arte del trabajo del equipo respecto a la forma de enfrentar lun tipo de ítems (en un determinado producto o servicio). Además, la mejora continua del proceso de desarrollo debería reflejarse en mejoras en el conjunto de workflows definidos, es decir, mejorar el proceso es modificar los workflows y actividades con el propósito de dar un mejor tratamiento a los ítems (incluso se podrían añadir nuevos workflows o quitar aquellos que están obsoletos).

Para poder explotar las características de un Workflow Flexible necesitaremos de una herramienta que nos permita para superar las dificultades que tendríamos al intentar gestionarlo manualmente. Dichas dificultades son las mismas o similares a las detalladas en el post "Desafíos para la aplicación efectiva de Scrum + Kanban = Scrumban". Así pues, la funcionalidad básica requerida para integrar workflows en desarrollo de software se indica a continuación:
  1. Gestión de workflows.  Alta, baja, modificación y consulta de workflows (con sus actividades y roles). En cuanto a los operadores necesarios para conectar actividades (secuencia, paralelo y selección), aunque en ciertos casos podría ser solo deseable, NO es necesario contar con mayor sofisticación al respecto, por ejemplo: anidamiento de actividades o combinación de operadores en una misma conexión. Que quede claro que ni por asomo estamos refiriéndonos a disponer de soporte para BPMN :-).
  2. Asignación de workflows a producto. Cada producto tendrá un conjunto de workflows aplicables de acuerdo con las necesidades de sus ítems.
  3. Cuando se crea un ítem, asignarle un determinado workflow.
  4. Asignar personas a roles del workflow de un determinado ítem de trabajo.
  5. Cuando se finaliza una actividad, que el ítem pase a estado pendiente en la(s) siguiente(s) actividad(es) del workflow que tiene asignado.
  6. Tablero kanban o scrumboard para tener una vista resumida de todo los ítems no terminados, con opciones de filtrado por agente, producto, versión, y otras funcionalidades asociadas a la rápida localización y acceso a ítems.
  7. Registro de seguimiento de las actividades realizadas sobre un ítem incluyendo como mínimo la fecha de pendiente y la fecha de finalización, además del agente que realizó la actividad.    
Con esta funcionalidad contaríamos con workflows integrados en el proceso de desarrollo, sin embargo, necesitamos además ciertos mecanismos para hacerlos "flexibles" para que resulten efectivos. A continuación, se indica la funcionalidad dirigida específicamente a dotar de flexibilidad a los workflows.
  1. Saltos hacia actividades previas o siguientes. Un agente del proceso puede tomar la decisión de llevar al ítem a una actividad previa del workflow (situación típica de re-trabajo). También podrían omitirse ciertas actividades no aplicables al ítem, dando un salto hacia alguna actividad posterior a la actual.
  2. Re-trabajo en paralelo a la actividad actual. En caso de re-trabajo de poca magnitud, en lugar de dar un salto a la actividad que requiere re-trabajo se podría continuar con la actividad actual pero crear una actividad de re-trabajo mediante el envío de un mensaje (o similar) desde el agente de la actividad actual hacia el agente de la actividad que necesita re-trabajo.
  3. Trabajo en paralelo en una misma actividad. Varios agentes podrían estar trabajando colaborativamente en una misma actividad del ítem (por ejemplo, programación en parejas).
  4. Cambio del workflow del ítem. En cualquier momento, si se detecta que existe otro workflow que se adapta mejor a las necesidades del ítem se debería permitir cambiar el workflow del ítem.
  5. Modificación de un workflow. Debería ser posible modificar un workflow cambiando automáticamente el workflow que tenían los ítems ya asignados a dicho workflow.
  6. Cambios en los agentes asignados a los roles del workflow del ítem.
  7. Si se establece pre-asignación de agentes a los roles de un ítem que se pueda definir para cada workflows cuáles son los agentes por defecto que tendrá un nuevo ítem en cada actividad del workflow. Por contraparte, si no se quiere o necesita realizar pre-asignación de agentes, permitir finalizar una actividad y pasar el ítem como pendiente a una actividad siguientes sin establecer aún el agente asignado. Así, los agentes que tienen el rol asociado a una actividad, que en un ítem no tiene agente asignado, podrán asignarse dicho trabajo. Esta es una funcionalidad clave para que el equipo sea self-organized (como lo plantea Scrum), los miembros del equipo en la medida que finalizan trabajo cogerían desde el trabajo restante que esté sin asignación previa.
  8. Añadir actividades no incluidas en la definición del workflow. Así, para casos excepcionales no es necesario crear un nuevo workflow, simplemente se añade la actividad que pueda faltar y solo aplicable al ítem en cuestión.
Algunas herramientas para gestión ágil de proyectos ofrecen soporte para workflows. Sin embargo, se trata de funcionalidad para habilitación o deshabilitación de acciones asociadas al estado del ítem, no son workflows en el sentido que hemos comentado aquí, no se definen roles y actividades para luego asignar agentes responsables, sino que se definen estados que luego son modificados manualmente en un campo desplegable puesto en la ficha del ítem. 

La siguiente figura muestra una parte del Gestor de Unidades de Trabajo (WUs) en Tune-up.  En el tracking de la WU puede observarse todas las actividades por las cuales ha pasado la WU, además, en la parte inferior se muestran los agentes asignados. El ejemplo sigue el workflow básico de Scrum. Finalmente la ventana pequeña permite continuar hacia la siguiente actividad o dar saltos hacia adelante o hacia atrás en el workflow. 

sábado, 29 de octubre de 2011

Workflows flexibles. Parte I: Reconociendo workflows en el proceso de desarrollo de software

Los workflows tienen un marcado protagonismo en definición y mejora de procesos de negocio, sin embargo, en el ámbito de desarrollo de software han recibido escasa atención. El desarrollo de software es un proceso, en él intervienen roles, actividades y artefactos. las diferencias más significativas que tiene el proceso de desarrollo de software respecto de otros tipos de proceso son: su gran dinamismo en cuanto a situaciones imprevistas, la intensa comunicación/colaboración que se requiere entre los participantes responsables de otras actividades y particularmente el hecho que el re-trabajo es una constante, es decir, una vez realizada una actividad, puede que tenga que repetirse parcialmente para corregir defectos de su ejecución previa.

A pesar de dichas particularidades, en desarrollo de software los workflows están muy presentes. Desde procesos tradicionales hasta los más ágiles. Lo que se necesita para reconocerlos explícitamente y sacarles más partido es que sean Workflows Flexibles, es decir, que estén preparados para los desafíos planteados en desarrollo de software. Precisamente los tableros kanban o scrumboards dejan en evidencia esta forma de workflows flexibles que están probando ser eficaces para la visualización y seguimiento del trabajo de un equipo.

Centrémonos en un proceso iterativo e incremental (aunque también sería aplicable a otros modelos de proceso). Cada incremento (llámese ítem, Historia de Usuario, work unit o similar) debe enfrentar al menos tres actividades: Definición, Programación y Testeo (de aceptación). Obviamente, otras actividades de interés podrían añadirse o bien podrían asumirse como incluidas en estas tres. El identificar explícitamente más o menos actividades es una cuestión de sentido común. Si se trata de un equipo de desarrollo pequeño, a priori puede que no tenga sentido establecer roles y actividades muy específicas pues una misma persona tendrá que llevar a cabo muchos roles y actividades. Sin embargo, aún teniendo un equipo pequeño podría ser interesante explicitar más actividades si se desea realizar un seguimiento más detallado, conociendo en qué actividades se encuentra en cada momento cada ítem.

Es importante destacar que en el contexto de un workflow se deben tomar tres decisiones: cuáles serán las actividades, qué roles se asociarán a cada actividad, y finalmente (una vez que aplicamos el workflow a un ítem), qué miembros del equipo desempeñarán dichos roles (para cada ítem). Scrum es enfático respecto a que las personas no deberían tener un título asignado al estilo "analista", "programador" o "tester", y utiliza un rol genérico "Development Team" para todos los miembros del equipo de desarrollo. Si bien es una postura radical respecto de los roles, no es incompatible con lo que estamos comentando, las actividades Definir, Programar y Testear (y otras más que se desee reconocer) existirán de todas formas, independientemente de los roles que se definan. Así pues, el concepto de rol sólo desempeña un papel de agrupador de actividades. Para ilustrar esto veamos los siguientes tres workflows, todos ellos tienen las mismas actividades (las esenciales indicadas antes), además en los tres workflows las actividades se realizan en los mismos ámbitos: bien en el Product Backlog o bien en el Sprint. La diferencia en los tres workflowa radica en los roles que se asocian a cada actividad.


En el WF Scrum Básico Ideal es el propio Product Owner quien se encarga de la gestión del Product Backlog, él mismo realiza todas las actividades que se realizan en dicho ámbito. El equipo sólo participa en la definición por demanda del Product Owner y para establecer la estimación de los ítems. Durante el sprint, los miembros del Development Team se encargan de la Programación y Testeo.


El WF Scrum Básico Realista representa una situación muy frecuente, en la cual el Product Owner por diversas razones no asume el protagonismo en cuanto a la preparación de los ítems en el Product Backlog, los miembros del Development Team se ven obligados a asumir dichas actividades, aunque el Product Owner debería mantenerse como responsable y encargado de tomar las decisiones relevantes. Así, en este caso miembros del Development Team deben asignarse a todas estas actividades.


El WF Scrum Básico "con roles tradicionales" a primera vista podría parecer contrario a las indicaciones de Scrum (pues se reconocen roles específicos), y lo es :-), pero sólo por indicar roles específicos de cara a un determinado ítem. En este WF aparecen roles específicos como los típicos de Analista, Programador y Tester, pero sólo son roles respecto al ítem. Es decir, cada ítem indudablemente tendrá a encargados para realizar cada una de las correspondiente actividades. Esta alternativa no implica que los miembros del equipo realizan actividades fijas para todos los ítems. Si esto último ocurriera se estaría asignando dichos roles específicos de forma fija a una persona, esto sí que estaría en contra del planteamiento de Scrum.

Aquellos que conozcan Kanban y/o Scrumban aplicados en el marco de Scrum podrán reconocer que los anteriores diagramas tienen el mismo propósito. La diferencia en cuanto a expresividad es que los workflows permiten de forma sencilla incluir actividades en paralelo o alternativas, algo que para Scumban con un tablero en la pared es complicado. Además, en Scrumban no existe explícitamente el concepto de rol.

En la Parte II de este post veremos qué características deben tener los Workflows Flexibles para resultar efectivos en desarrollo de software.



Patricio Letelier

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

Gestión eficaz del Product Backlog

Respecto del Product Backlog, en la Scrum Guide dice:

"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product... The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases".

Una sutíl pero importante diferencia respecto a las primeras ediciones de la Scrum Guide es que ahora el Product Backlog es definido como una lista "ordenada" en lugar de "priorizada". En mi opinión, con esto se está reconociendo que el orden en el cual se coge el trabajo desde el Product Backlog no depende sólo de la importancia o valor del ítem de trabajo, sino que existen además otros factores que pueden/deben ser considerados para establecer en conjunto dicho orden.

Por otra parte, también es importante destacar que el Product Backlog no sólo incluye nuevos requisitos para el producto, sino también mejoras en requisitos ya implementados, y/o correcciones de fallos. Así también, la granuralidad de los ítems en el Product Backlog puede ser muy diferente. Además, podemos encontrar en el Product Backlog ítems con una descripción muy general y/o preliminar, y otros ítems ya definidos con suficiente detalle como ser implementado. Antes de poder incluir un ítem en una iteración éste debería tener una granuralidad tal que su implementación se pueda hacer en pocos días (mi recomendación es menos de una semana).

Cuando un producto comienza a ser desarrollado, en general, no se tienen muchos ítems en el Product Backlog, siendo además la mayoría del tipo "nuevo requisito". En la medida que se realizan entregas del producto y mientras más utilización/éxito tenga, la cantidad de ítems en el Product Backlog irá incrementando y comenzarán a ser mucho más numerosos los ítems correspondientes a mejoras y correcciones de fallos. El objetivo a mediano y corto plazo NO es el vaciar el Product Backlog (dependerá de nuestra capacidad para implementar ítems y del ritmo de generación de nuevos ítems). Lo realmente importante es realizar una gestión efectiva del Product Backlog, asegurándos que en todo momento esté ordenado y preparado para coger ítems e incorporarlos en una nueva versión del producto.

A continuación, un pequeño paréntesis para comentar dos técnicas para priorización de características:  el Kano Model y MoSCoW.

El Kano Model es una técnica para clasificar las características de un producto según el grado de satisfacción que generan en el cliente. En este modelo las características del producto se clasifican en:
  • Dissatisfier – Must be’s – Cost of Entry
  • Satisfier – More is better – Competitive 
  • Delighter – Latent Need – Differentiator 
De forma similar, en la técnica MoSCoW cada característica se clasifica como:
  • M: "We MUST have this", debemos tenerla.
  • S: "We SHOULD have this", deberíamos tenerla.
  • C: "We COULD have this", podríamos tenerla. 
  • W: "WON’T have this now", ahora no la queremos pero podríamos quererla más adelante.
La clasificación debería hacerse basada en la opinión de los stakeholders con algún mecanismo de votación o encuesta, o podría hacerla una persona en representación de toda la parte cliente (Product Owner).

Estas clasificaciones nos pueden ayudar a ordenar globalmente los ítems del Product Backlog, especialmente al iniciar el desarrollo de un producto (cuando todo el contenido del Product Backlog se refiere a la incorporación de nuevos requisitos). Sin embargo, dichas clasificaciones incluyen solo tres o cuatro categorías, por esto, de todas formas habría que realizar un análisis más detallado o complementario para determinar un número de orden que diferencie en mayor medida a los ítems (que pueden ser decenas o cientos para un producto enfrentado a un intenso o continuo mantenimiento), y para pasarlos a implementación siguiendo dicho orden . Así pues, lo más adecuado en cuanto a priorización de ítems en el  Product Backlog es utilizar un número de orden, el cual reflejaría una combinación de criterios aplicados para determinarlo.

... fin del paréntesis


El "Grooming del Product Backlog" se refiere al conjunto de acciones realizadas sobre el Product Backlog, ellas son:
  • Preparar ítems. Para incluir un ítem en un Sprint debe estar suficientemente definido, estimado (si se trabaja con estimación de ítems) y tener un tamaño relativamente pequeño. En la medida que un ítem está en o se acerca a los primeros puestos de la lista del Product Backlog se hará más urgente que dicho ítem esté preparado. 
  • Poner un número de orden a un nuevos ítem. Periódicamente hay que revisar el Product Backlog para asignar un número de orden a los nuevos ítems dentro del contexto de los ya ordenados.
  • Cambiar el número de orden de ítems. Los ítems se irán definiendo y estimando, entrarán nuevos ítems, y obviamente también, se podrían cambiar las prioridades en el negocio. Es importante revisar periódicamente el orden asignado por si es necesario cambiarlo.
  • Seleccionar ítems del Product Backlog para incluirlos en una próxima versión del producto. Si el Product Backlog está preparado esta acción consiste simplemente en coger los primeros ítems de la lista según el número de orden y considerando el trabajo que puede ser abordado según la capacidad del equipo. Si un ítem no está adecuadamente preparado hay mayor riesgo en su implementación y consecuentemente en desajustes que pueda provocar en el Sprint o entrega.
  • Desestimar o eliminar ítems. Aquellos ítems que han quedado obsoletos deben quitarse del Product Backlog. Si el ítem ya ha tenido algo de trabajo de preparación o si interesa mantener registro de la existencia del ítem, lo adecuado sería desestimarlo en lugar de eliminarlo.
A continuación se presenta una lista de criterios recomendados para establecer el orden de ítems en el Produt Backlog:
  • Valor, importancia o prioridad para el negocio. Este criterio a priori debería ser fácil de establecer, y consistiría en tener una correcta percepción del valor específico que aporta al cliente/usuario cada cambio en el producto. El problema es que aunque dicha percepción es correcta en un determinado momento, luego con el paso del tiempo su valor relativo puede cambiar. Muchas veces la noción de valor está ligada a qué tan reciente es la propuesta de cambio. Es por ello que las "ideas felices" conviene que reposen un tiempo en el Product Backlog para que estabilicen su valor relativo. Estudios de uso de funcionalidades en un producto suelen mostrar que algunas funcionalidades, en las cuales se invirtió mucho esfuerzo de desarrollo con la creencia que iban a ser muy utilizadas, no son prácticamente utilizadas por los usuarios. Esto es uno de los síntomas claros de errores en la valoración de los cambios en un producto.
  • Frecuencia de uso de funcionalidad. Aunque este aspecto suele estar correlacionado con otros criterios, conviene evaluarlo por separado. Las funcionalidades muy utilizadas suelen ser importantes en términos de valor. Cuando se trata de un ítem de corrección de fallo, la frecuencia de uso de la funcionalidad asociada conlleva una criticidad del ítem y la correspondiente urgencia por resolver el fallo. Excepcionalmente, por ejemplo, cuando se trata de ítems diferenciadores (según la clasificación en el Kano Model), un ítem asociado a una funcionalidad poco usada puede aún ser prioritario cuando se considera además su aporte a una estrategia de marketing.     
  • Urgencia. Tiene más relevancia durante el mantenimiento cuando ítems de menor valor puede que tengan que implementarse cuanto antes. Por ejemplo, esto ocurre con las correcciones de fallos que tienen una alta severidad (lectura recomendada: Fallos, defectos y errores y su gestión en un contexto ágil). A veces, ciertos ítems tienen una fecha comprometida y la urgencia se ve indirectamente reflejada en el tiempo restante para que se cumpla el plazo comprometido.
  • Riesgo. El riesgo está asociado al nivel de certeza que se tiene del esfuerzo asociado a un ítem. El riesgo de implementación de un ítem depende de diversos factores, tales como: la experiencia del equipo, los desafíos tecnológicos, la complejidad, el impacto de posibles fallos, etc. Los ítems con mayor riesgo pueden alterar el desarrollo del producto por esto, en general, conviene que se aborden cuanto antes.
  • Esfuerzo. Frecuentemente hay ítems que independiente de otros criterios, requieren muy poco esfuerzo de implementación. Estos ítems podrían incluirse en cualquier momento en el próximo sprint (incluso añadirse directamente en el sprint actual). Al respecto, vale la pena mencionar la "Regla de los 2 minutos" de GTD (Getting Things Done de  David Allen) que nos recomienda algo así como:"toda acción que se pueda realizar en menos de 2 minutos hazla ya!, gastarás más en gestionarla dentro del trabajo pendiente". Por otra parte, ítems que requieren mucho esfuerzo (denominados Epics, o Historias de Usuario Épicas) pueden requerir un particionamiento previo en sub-ítems y una organización entre ellos en términos de interdependencias. Un nuevo requisito o una remodelación de cierta envergadura puede en este sentido ser tratada como un proyecto que agrupa un conjunto de ítems (similar al término Theme) y que podría irse desarrollando a lo largo de varios sprints (aunque no se incluyan en la entrega al cliente hasta tener terminados algunos o incluso todos los ítems del proyecto). Es importante destacar que la estimación (o no estimación) de los ítems en el Product Backlog es una cuestión que debería estar decidida para cada producto o servicio encargado al equipo, y dependerá principalmente de cuán rígido se establezca el compromiso o previsión de entregas con el cliente. Además, cuando se opta por estimar, se tienen varias alternativas respecto a cómo hacerlo. Lectura recomendada: "Estimación en un proyecto ágil", Parte I y Parte II.
  • Tipo de usuario al cual va dirigido el cambio asociado al ítem. Esto permite (cuando se desee) orientar una entrega hacia ciertos tipos de usuario, para esto se localizan en el Product Backlog ítems dirigidos a cierto tipo de usuario y se arma un grupo poniéndoles un número de orden igual o consecutivo para que entren juntos a un sprint.
  • Origen del ítem. Aunque quien decide el contenido del Product Backlog es el Product Owner, es importante conocer cuál fue el origen del ítem. Un ítem puede ser solicitado por una determinada persona de contacto en un cliente donde está instalado el producto o incluso por algún miembro del equipo. Las solicitudes (y correspondientes ítems) pueden tener mayor o menor prioridad dependiendo de quien realiza la solicitud. Con esta información y de forma estratégica se puede hacer un "gesto" de servicio hacia un determinado solicitante.
  • Tipo del ítem. Básicamente la clasificación podría ser: Nuevo Requisito, Mejora, Corrección de Fallo y Otros. En el caso de Correcciones de Fallos, es útil también conocer la severidad del fallo, si existe un atajo o workaround y la versión desde la cual está presente dicho fallo. lectura recomendada "Fallos - Defectos - Errores y su gestión en un contexto ágil".
  • Parte de la estructura del producto que se verá afectada por el ítem. Es importante conocer las partes del producto que se verán afectadas por el ítem. El análisis de impacto del cambio parte precisamente del conocimiento de esta información. Además, cuando se va a decidir realizar un cambio en una parte del producto podrían "de paso" hacerse otros cambios pendientes, o por el contrario, el ítem podría postergarse para cuando se pudiesen hacer más cambios en conjunto en la misma área.
  • Proyecto. Como se comentó antes en el factor Esfuerzo, los ítems de gran tamaño pueden dividirse y organizarse en proyectos que duran varias iteraciones. En este caso es importante reconocer fácilmente cuáles ítems pertenecen a un mismo proyecto y convenientemente agruparlos asignándoles el mismo número de orden o números consecutivos según se desea que se cojan para ser incluidos en un sprint.
  • Relaciones de dependencia entre ítems. Si un ítem requiere de otro para su implementación es necesario que este último se implemente primero, es decir, que tenga un número de orden menor o igual. Al cambiar el número de orden de un ítem se debe verificar que no se producen inconsistencias respecto de las dependencias asociadas al ítem.
  • Fecha de creación del ítem. Normalmente los ítems más nuevos suelen tenerse más presente que otros más antiguos. Por otra parte, revisando los ítems más antiguos se puede detectar que ya están obsoletos. También es importante la fecha de creación para asegurar, en lo posible, una no postergación indefinida de un ítem.
  • Fecha de límite. Se refiere a la fecha límite para entregar el ítem. Es acordada con el cliente, y puede ser necesaria cuando en el producto o servicio NO se trabaja con sprints o proyectos (los cuales ya conllevarían una fecha de entrega para el ítem). 
  • Estado de preparación del ítem. Es importante conocer si el ítem ya está definido o en general, qué tan preparado está el ítem para poder ser incluido en el próximo sprint.
Al asignar un número de orden a un ítem deberían tenerse en cuenta estos factores en conjunto, no tiene por qué ser siempre el más determinante ni el único criterio el Valor del ítem. Además, el éxito del producto no sólo se basa en el éxito de su primera entrega sino que depende en gran medida del servicio de mantenimiento ofrecido, en el cual juega un papel fundamental la gestión efectiva que se haga del Product Backlog.

La visualización del Product Backlog (y del contenido de cualquier Sprint) es otro aspecto importante. La opción más utilizada es tener una lista con facilidades para aplicar ordenamientos y filtros según los criterios indicados antes. En nuestro enfoque y herramienta TUNE-UP (www.tuneupprocess.com), además de dicha tradicional lista, hemos incorporado otras dos opciones: una lista de las relaciones de entre los ítems de trabajo dentro del Product Backlog (o dentro del Sprint) incluyendo también relaciones con otros ítems en otros Sprints, y una vista que muestra un un grafo que representa la estructura del producto, remarcando las partes que son afectadas por los ítem dentro del Product Backlog (o dentro de un Sprint). La siguiente figura muestra esta vista, en la cual se ha seleccionado el nodo "Product Graph" y en el grid de la derecha se remarcan los 2 ítem de trabajo que afectan a dicho nodo en la versión 1.2.9, además de mostrar todos los ítems de trabajo que han afectado o afectarán a dicho nodo.


Esta representación tiene aspectos en común con la visualización proporcionada por los Story Mappings, la cual puede ser especialmente útil cuando se trata de un producto en desarrollo inicial. También hemos explorado otras alternativas de visualización usando TreeMaps y grafos, si bien añaden una visualización más atractiva, en términos prácticos respecto de ayudar a organizar el Backlog, no nos han parecido indispensables.



Patricio Letelier

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

viernes, 28 de octubre de 2011

Tableros kanban: ¿por qué recomiendo utilizar una herramienta en lugar de un "tablero kanban manual" y qué funcionalidades debería ofrecer?

Un tablero kanban físico (usualmente puesto en una pared) usando pósits es un excelente medio para ilustrar y aprender la mecánica de trabajo incremental. Además, para un equipo que se inicia en el enfoque ágil es un elemento socializador y entretenido, que refuerza la motivación por adquirir nuevos hábitos de trabajo.  En internet abundan ejemplos de tableros kanban físicos. Su utilización en desarrollo de productos industriales transmite quizás demasiado triunfalismo en cuanto a los resultados conseguidos con esta técnica. A continuación expongo mis razones para ser escéptico en cuanto a dicho triunfalismo, llegando a la conclusión que para hacer una eficaz implantación de esta técnica, y particularmente hacerla sostenible (que no decaiga su uso) se debe contar con una herramienta-software de apoyo. 

NOTA: me referiré a Unidad de Trabajo (UT) como equivalente a Historia de Usuario, Ítem o pósit en el tablero kanban. Usar el término UT me parece más genérico para referirnos a trabajo sin importar el ámbito del que se trate.

En mi opinión, los principales inconvenientes o situaciones difíciles de gestionar en un tablero kanban físico son:
  1. Un tablero físico tiene los problemas obvios asociados a su mantenimiento en una pared y con pósits, especialmente si la cantidad de UT es alta. Mi recomendación respecto de la granuralidad de cada UT es que permita su implementación en no más de una semana de trabajo, con lo cual en contextos con gran volumen de trabajo y con una alta tasa de cambios sería normal enfrentarse a la gestión de cientos de UT, caso en el cual necesitaríamos una pared muy grande para instalar el tablero kanban :-), sería difícil la gestión de tantos pósits y además, la manipulación de la posición de los pósits estaría propensa a errores.
  2. Otro inconveniente obvio es que el equipo esté distribuido y/o tenga que desplazarse para estar frente al tablero físico. Aunque el tablero kanban se puede fotografiar, no es lo mismo verlo presencialmente e interactuar con él.
  3. Un pósit ofrece un espacio demasiado limitado para gestionar la información asociada a una UT. Una UT suele necesitar una breve descripción, bocetos de interfaz de usuario, ideas para pruebas de aceptación, notas, etc. Si el pósit sólo contiene el nombre de la UT y poco más, el resto de información no estará centralizada y disponible para todo el equipo, o podría estar pero en soportes externos al tablero.
  4. Un encargado de trabajar en una UT no la debería coger desde el tablero para llevársela a su puesto de trabajo, ya que el resto del equipo no visualizaría dicha UT. Habría que copiarla o fotografiarla para tener la información necesaria para trabajar en ella "lejos" del tablero. 
  5. En caso se trabaje con UT que difieren significativamente en su procesamiento lo recomendable sería tener diferentes tableros. Así, cada tablero tendría las columnas que requieran las UT que se incluyan en el tablero.
  6. Cuando el número de UT en un tablero es alto, probablemente se querrá identificar o distinguir cuáles UT tienen una determinada característica, por ejemplo, persona que la solicitó, tipo de la UT, las que son urgentes, las más antiguas/recientes, etc. En un tablero físico se podrían añadir decoraciones a los pósit para diferenciarlos, sin embargo esto es muy rudimentario si lo comparamos con un mecanismo de filtrado y búsqueda que se ofreciera en un software para gestionar el tablero kanban.
  7. ¿Qué se hace con las UT ya terminados?, por defecto se desecharían todos los pósits una vez terminados, con lo cual dicha información no estaría disponible para retrospectivas futuras, estudio de tendencias, o simplemente para conocer cómo se gestionó una determinada UT.
  8. Cuando se trabaja con Sprints, podría darse la situación en la cual la finalización de un Sprint se solapa con el trabajo del siguiente Sprint. Si bien el foco debería ser terminar el trabajo del Sprint actual, dicho trabajo se irá extinguiendo y los miembros del equipo si no tienen otro trabajo más prioritario podrían empezar a trabajar en UT del siguiente Sprint. Esta situación obligaría a gestionar UT de más de un Sprint en el tablero, y si esto ocurre convendría distinguirlas. Nuevamente, esto podría ser mucho mejor gestionado en una herramienta-software. 
  9. Si las actividades (columnas del tablero) por las que pasa una UT son realizadas por diferentes colaboradores, es útil conocer quién ha trabajado en cada actividad asociada a al UT. En un tablero físico se suele adjuntar en el pósit un avatar representando quién está trabajando en una UT. Sin embargo, para saber quién ha trabajado en la unidad de trabajo deberíamos dejar registrado en el pósit quiénes han trabajado en él y en cuál actividad. 
  10. El tablero físico no soporta adecuadamente actividades en paralelo o actividades alternativas. Si bien el tablero corresponde a un workflow, solo representa una secuencia de actividades (columnas) ordenadas de izquierda a derecha. Sería complicado en una pared poder reflejar actividades en paralelo o alternativas. Además, en el caso de actividades en paralelo la UT debería clonarse para fluir por dos caminos en paralelo, y luego los clones deberían fusionarse cuando se llegue a un punto de sincronización (cuando debe terminarse el trabajo en paralelo).
  11. Cada tipo de UT o incluso cada UT en particular podría requerir un workflow específico. Un tablero físico no ofrece apoyo adecuado para un tratamiento específico para los ítems, normalmente el tablero kanban representa solo un workflow aplicable a todos los ítems. Tener un solo tablero para diferentes procesamientos (según el tipo de UT) conllevaría a que ciertas columnas (actividades) no serían aplicables a algunas UT, es decir, tendrían que saltarse algunas columnas. Esto podría ser complicado de gestionar y sería propenso a errores en el desplazamiento de las UT en el tablero. 
  12. Las dependencias entre ítems son difíciles de representar en un tablero kanban físico. Se deberían reflejar adecuadamente relaciones tales como: "continua-en"/"es-continuación-de", "requiere-a"/"es-requerido-por", etc. 
  13. El Backlog (Product Backlog) está representado por unas o varias columnas del tablero (ubicadas en su parte izquierda). En estas columnas se realizan las actividades de "Preparación" de una UT  (por ejemplo: definición, validación, estimación, etc.), es decir, las actividades que establecen qué debe obtenerse como resultado al terminar la UT. Correspondientemente, hacia la derecha del tablero habrá columnas de "Ejecución" del trabajo, es decir, aquellas a realizar y probar que efectivamente se ha hecho lo solicitado. El Backlog puede contener cientos de UT. La gestión efectiva del trabajo pendiente y su priorización son clave para el éxito del trabajo (ver Gestión efectiva del Product Backlog). El Backlog está en constante cambio; se añaden UT, se reordenan, se dividen, se agrupan, se eliminan, etc. Todo este trabajo realizado con pósits puede llegar a ser inviable.
  14. Si bien no es una práctica ágil recomendada, si se quisiera organizar el trabajo dando importancia a balancear la carga entre los miembros del equipo, debería existir una forma de representar pre-asignación de responsables en las actividades de cada UT, es decir, que cuando la UT llegue a cierta actividad, que ya se sepa de antemano cuál es la persona que se ocupará de dicha actividad. Esto también obligaría a registrar dichas preasignaciones en la UT. La preasignación puntualmente puede ser interesante cuando se prevé en una UT tiene un cierto desafío en cuanto a alguna actividad, decidiendo de antemano quién(nes) debería(n) encargarse de dichas actividades para garantizar un buen resultado gracias a la experiencia o especialización requerida. En un tablero kanban físico es difícil de representar preasignaciones. Normalmente en los tableros kanban físicos solo se indica con un avatar los que están o han participado en una UT, pero no se suele indicar quienes participarán en cierta actividad (columna) a la cual la UT aun no ha llegado.
  15. El tablero físico no responde adecuadamente a situaciones de retrabajo, es decir, cuando una actividad se debe volver a realizar debido a la detección de un defecto. Una de las situaciones más típicas de retrabajo es cuando en pruebas se detecta un fallo asociado a un defecto arrastrado desde una actividad previa (por ejemplo un fallo de programación detectado en pruebas). En general, si el defecto no impide continuar con la actividad actual lo aconsejable sería que la UT se mantuviera en ella hasta completarla y luego devolver la UT a la actividad donde deben corregirse los fallos o defectos detectados. Cuando la UT se mantiene en la actividad actual debería indicarse que tiene un retrabajo pendiente. Además, habría que evaluar si una vez terminado el retrabajo en la actividad anterior (a la que se ha devuelto la UT) debería o no hacerse retrabajo en otras actividades intermedias. En un pósit se pueden poner decoraciones para indicar que la UT tiene algún defecto por resolver y también para indicar con uno o varios avatares quienes están trabajando en ella, sin embargo, la información asociada a los fallos o defectos detectados no suele registrarse. 
  16. Similar a la situación de retrabajo, en cuanto a que la UT podría estar en más de una actividad a la vez, es cuando se puede ir adelantando trabajo de cierta actividad (por ejemplo adelantar algo de pruebas de la UT aunque su programación aún no está totalmente finalizada), en este caso la UT se mantiene en una actividad pero a la vez se está trabajando en otra actividad posterior.
Estos argumentos dejan en evidencia la necesidad de contar con una herramienta-software que apoye la gestión del tablero kanban. Sin embargo, el desafío es que dicha herramienta resuelva cada uno de los inconvenientes indicados. Modestias aparte :-), hasta donde llega nuestro conocimiento sólo Worki, la herramienta de apoyo a nuestra metodología ágil TUNE-UP Process (www.tuneupprocess.com), considera todos los aspectos mencionados. La siguiente imagen muestra la vista "Tablero multikanban" de Worki. El "Tablero multikanban" de Worki sintetiza múltiples tableros kanbans. Gracias a filtros, se puede ofrece una vista del kanban de cada participante, de una Línea de Trabajo, de un Sprint de un Proyecto, o del del Backlog. 
De forma alternativa se ofrece la vista "Tablero unikanban", es decir, una visualización de un tablero a la vez, con sus columnas específicas, y nuevamente con funcionalidades de filtrado y acceso a las UT. En la siguiente figura se muestra un ejemplo de la vista "Tablero unikanban", con la misma información de la figura anterior, pero esta vez restringida además a un tablero específico (el seleccionado en el desplegable "Workflow").
En Worki, desde estas dos vistas de tableros kanban existen diversas formas para acceder a las UT y visualizarlas en otro formulario denominado Gestor de UT, el cual correspondería a un pósit del tablero kanban físico, pero que obviamente es un contenedor muchísimo más potente de toda la información relacionada con la UT. Lectura recomendada: Multikanban, un tablero kanban para contextos multiproyecto.


Patricio Letelier

www.tuneupprocess.com 


¿Revolución o evolución hacia la agilidad? ¿Cuál es tú estrategia de Transformación Ágil?

El sentido común no se resiste a las ventajas del enfoque ágil. Las buenas prácticas de Extreme Programming, la contundencia de los planteamientos de Scrum, la efectividad de Kanban y la sensatez de Lean, todo ello ha puesto en la mira a los métodos tradicionales de producción de software, llevando el debate incluso más lejos, cuestionando también la gestión de proyectos (o del trabajo en general) en otros ámbitos. El interés por el enfoque ágil ya está creado, los conceptos y prácticas ya se explican en una multitud de libros, cursos e información en internet. Sin embargo, a casi dos décadas del Manifiesto Ágil sigue sin ser estar resuelto el desafío que implica la implantación efectiva de métodos ágiles en una organización. Las dificultades para implantar metodología ágiles son evidentes, basta leer artículos como los siguientes: Agile's Teenage Crisis?Scrumbut and Modifying Scrum, o Flaccid Scrum.


Aunque los cursos y certificaciones del estilo CSM (Certified Scrum Master) o ACP (Agile Certified Practitioner) siguen en aumento, estas iniciativas no parecen ser la solución. El desencanto con el enfoque ágil comienza a crear nuevas corrientes, no necesariamente contrarias, pero recelosas de las recetas genéricas difíciles de llevar a la práctica en contextos específicos, por ejemplo, el término Post-Agilism, o una visión crítica del estado del enfoque ágil en Maybe Agile is the Problem).

Hasta ahora, se ha promovido el “pseudo-purismo” en cuanto a la aplicación de los principios y prácticas ágiles, el “todo o nada”, el “ser o no ser Ágil”, “el aplicar o no Scrum”, etc. Extreme Programming (XP) en este sentido es menos radical, y aunque en su nombre “Extreme” se refiere a la aplicación en extremo de cada una de sus 12 prácticas, reconoce que es posible que no se apliquen todas o que alguna se apliquen en menor medida, eso sí, advirtiendo que esto restaría efectividad al método pues las prácticas se relacionan entre sí. Scrum sugiere menos prácticas que XP y a priori resultaría más sencillo de implantar, sin embargo, su postura es mucho más radical en cuanto a la aplicación de sus elementos.

Bastaría con hacer una lista de elementos (roles, prácticas y artefactos) propuestos por Scrum y XP, y luego hacer una reflexión en equipo preguntándose en qué medida en un determinado contexto de producto (relación con el cliente, dominio de aplicación, tecnología, composición del equipo, etc.) cada uno de dichos elemento podría aplicarse y en qué nivel de profundidad.

Tomemos por ejemplo el rol Cliente en XP o Product Owner en Scrum. El Product Owner define y ordena el Product Backlog (el trabajo pendiente asociado al producto) teniéndolo preparado para cuando se realice la planificación. Este Product Owner está altamente disponible para el equipo (ojalá in-situ como remarca XP). El Product Owner es una única persona y representa a todos los otros posibles stakeholders, y es su responsabilidad resolver requisitos o prioridades en conflicto. En XP es el cliente el que debería escribir las Historias de Usuario y definir las correspondientes pruebas de aceptación. Pero es difícil tener un cliente con este nivel de participación, y si el cliente no asume dicho trabajo será el equipo quien tendrá que realizarlo, eso sí, el cliente mantendrá la responsabilidad de las decisiones que se tomen al respecto. En este caso, ¿sería correcto decir que estamos usando Scrum o XP si no se cumple con dicha definición de Cliente o Product Owner, aunque estemos aplicando otros elementos ágiles?. Tal como se suele interpretar Scrum, probablemente no nos calificarían como un equipo Scrum, en el caso de XP probablemente podríamos tener el calificativo de equipo XP, dependiendo de qué otros elementos estemos aplicando y en qué medida.

El pseudo-purismo en la aplicación de Scrum o XP ha marcado distancia con los métodos tradicionales, lo cual es positivo en término de tener referencias claras de uno y otro enfoque. Sin embargo, desde la perspectiva de implantación dicho purismo como estrategia de cambio para un equipo representa una revolución hacia métodos ágiles. Esto puede ser ideal y deseable en ciertos contextos, pero en muchos otros es claramente inviable, o incluso probablemente llevaría a una decepción y frustración a mediano plazo.

¿Qué alternativa tiene un equipo para el cual no es posible llevar a cabo dicha revolución? ¿debe esperar hasta que tenga condiciones más favorables para embarcarse en el enfoque ágil? ¿debe resignarse a que el enfoque ágil no es para ellos? ¿qué tan importante es poder calificarse como equipo Scrum o XP?

Sí, existe otra alternativa, y consiste en implantar el enfoque ágil con una estrategia de evolución. El equipo no tendría que esperar y en un corto plazo podría estar ya aplicando ciertos elementos ágiles e iniciando un camino de mejora continua hasta donde pueda y le interese llegar. Los elementos del enfoque ágil deberían actuar como una “lista de deseos” un punto de referencia hacia el cual se intenten dirigir los cambios de proceso. No hay por qué obsesionarse en tener la calificación Scrum o XP, lo realmente importante es que el equipo asimile los principios del enfoque ágil (del Manifiesto Ágil) e incorpore los elementos que le aporten mayor valor, y que a su vez puedan ser efectivamente aplicados en un contexto y momento determinado.

Curiosamente, CMMI, visto por alguno como el Satanás para las metodologías ágiles :-), pasó por una situación similar en cuanto a estrategia de implantación. Inicialmente sólo existía el modelo CMMI Escalonado (Staged) para el cual hay que demostrar evidencias de implantación de todas las prácticas incluidas en el nivel que se quiere certificar (y de los niveles inferiores). Posteriormente, como una alternativa apareció el modelo CMMI Continuo el cual permite certificarse sólo de aquellas prácticas que el equipo considera más importantes o factibles de implantar de acuerdo con su contexto de trabajo.

Kanban, al menos en la propuesta de David J. Anderson, sugiere una estrategia evolutiva insistiendo en que para encontrar una menor resistencia al cambio inicialmente se debe cambiar lo menos posible, es decir, para asegurar el éxito de introducir Kanban lo mejor es partir por dar soporte a la forma actual de trabajo del equipo y luego ir realizando mejoras, una vez que Kanban esté establecido. Sin embargo, tal como ocurre en XP o Scrum, en Kanban la mejora se centra en sus propias prácticas, sin prestar atención a prácticas de otros métodos.

La estrategia evolutiva requiere un diagnóstico del contexto del equipo y su trabajo en productos o servicios. El diagnóstico debería orientarnos para establecer un roadmap para la implantación incremental de prácticas ágiles (ver Carta de prácticas ágiles y/o acceder a AGILE Roadmap para realizar un diagnóstico preliminar on-line). Este roadmap constituye un Improvement Backlog para el equipo, es decir, una lista ordenada de mejoras metodológicas que se irán introduciendo y evaluando. La siguiente figura ilustra cómo para un equipo determinado sus prácticas lo pondrían en un punto intermedio entre una supuesta clasificación NO ágil y ágil. Con una estrategia evolutiva la idea es mover paso a paso al equipo hacia prácticas ágiles. Cada paso hacia el enfoque ágil debería ser "razonable" para que el esfuerzo invertido en dicho paso se corresponda con la rentabilidad conseguida. La Transformación Ágil también debe ser fiel a los principios ágiles, NO debería ser un esfuerzo largo en el tiempo, con mucha preparación y sin mostrar resultados (al menos parciales). 



¿Existen propuestas para Transformación Ágil basadas en una estrategia evolutiva?. Aunque la recomendación es demasiado cercana, hasta donde llega mi conocimiento sólo nuestra metodología TUNE-UP Process (www.tuneupprocess.com) y apoyada por su Worki  ofrecen una estrategia evolutiva, es decir, que permite al equipo poder situarse en un punto de partida y luego ir modificando la forma de trabajo, llegando, si se desea, a cumplir totalmente con Kanban, Scrum o XP. TUNE-UP Process y Worki abordan la implantación del enfoque ágil (y su posterior mejora) desde una perspectiva integradora de prácticas ágiles, independientemente de si ellas provienen de XP, Scrum, Kanban o Lean. 





Patricio Letelier

www.tuneupprocess.com