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. Veáse la presentación de las funcionalidades de TUNE-UP respecto de workflows flexibles.

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 manual (usualmente puesto en una pared) usando post-it es un excelente medio para ilustrar y aprender la mecánica de trabajo incremental (yo lo utilizo en mis cursos para explicar conceptos de los métodos Scrum y Kanban). Además, para un equipo que se inicia en agilismo es un mecanismo muy socializador y entretenido que refuerza la motivación de la iniciativa de implantación del agilismo.  En internet abundan ejemplos de tableros kanban manuales. Asociado a su utilización en desarrollo de productos industriales se transmite mucho 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. Los principales inconvenientes que he detectado en los tableros kanban manuales son:
  1. Un tablero manual tiene los problemas obvios asociados a su mantenimiento en una pared y con post-its, especialmente si el volumen de ítems es alto. En la mayoría de los ejemplos se muestran muy pocos ítems en el sprint, lo cual también se asocia a la recomendación de limitar el trabajo en curso (WIP - Work in Process) en cada actividad. Sin embargo, incluso para productos y equipos relativamente pequeños, si en un sprint, además de los nuevos requisitos, se consideran como ítems las correcciones de fallos y todas las pequeñas mejoras, el resultado suele ser varias decenas de ítems. Además, la granuralidad recomendada para cada ítem debería ser tal que permitiera su implementación en no más de una semana de trabajo.
  2. Otro inconveniente obvio es que el equipo esté distribuido y/o tenga que desplazarse para estar frente al tablero físico.
  3. Un post-it ofrece un espacio demasiado limitado para gestionar la información asociada a un ítem. El ítem suele necesitar una breve descripción, bocetos de interfaz de usuario, ideas para pruebas de aceptación, notas, etc. Si el post-it sólo contiene el nombre del ítem y poco más, el resto de información no estará centralizada y disponible para todo el equipo, o lo estará pero en soportes alternativos al propio tablero.
  4. El desarrollador encargado de un ítem no lo debería coger desde el tablero para llevárselo a su puesto de trabajo, ya que el resto del equipo no visualizaría dicho ítem. 
  5. En caso de trabajar con varios productos a la vez, se tendría que mantener un tablero por cada producto (si no se quiere complicar los post-it con más decoraciones adicionales) y los participantes que trabajen en más de un producto a la vez deberían ir a diferentes tableros cuando corresponda. Algo similar ocurre trabajando varios equipos sobre el mismo producto (“Scrum de Scrums”).
  6. ¿Qué se hace con los ítems ya terminados?, por defecto se desecharían todos los post-it una vez terminado el sprint, con lo cual dicha información no estaría disponible para retrospectivas futuras, estudio de tendencias, o simplemente para conocer en qué sprint y cómo se gestionó un determinado cambio del producto.
  7. Cuando se trabaja con Sprints, el hacer coincidir de forma exacta la finalización de un sprint con el comienzo del siguiente (para evitar tiempos no aprovechados por los miembros del equipo) es muy difícil. Normalmente la finalización de un sprint se solapará 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 o bien trabajarán en la preparación de ítems para el próximo sprint (sólo si no hay ya suficientes ítems preparados) o bien ya empezarán a implementar el siguiente sprint. Esta situación obligaría a tener ítems de dos sprints en el tablero, uno para la versión actual y otro para la siguiente, o bien, tener al menos dos tableros para cada producto.
  8. Si las actividades de un ítem son realizadas por diferentes participantes, es necesario tener el registro de quién ha trabajado en ítem para poder contactar con él en caso de dudas. Esto en el tablero manual se resuelve poniendo el avatar de quien está trabajando en un ítem. Sin embargo, para saber quien ha trabajado en el ítem deberíamos dejar registrado en el post-it quien ha trabajado en el ítem y en cuál actividad. Además, esto se complica cuando dos o más miembros del equipo trabajan en paralelo en la misma actividad de un ítem (por ejemplo programación en paralelo), pues cada uno de los involucrados debería ver dicho ítem como asignado a él.
  9. El tablero manual no soporta adecuadamente actividades en paralelo o actividades alternativas. Normalmente un tablero sólo representa una secuencia de actividades (columnas) ordenadas de izquierda a derecha en el tablero. Sería complicado en una pared poder reflejar actividades en paralelo o alternativas. Además, en el caso de actividades en paralelo el ítem debería clonarse para fluir por dos caminos en paralelo, y luego los clones debrían fusionarse cuando se llegue a un punto de sincronización (cuando debe terminarse el trabajo en paralelo).
  10. Cada producto, tipo de ítem o incluso cada ítem 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 ítem) conllevaría a que ciartas columnas (actividades) no serían aplicables a un determinado ítem, es decir, tendrían que saltarse. Esto podría ser complicado de gestionar y sería fácil cometer errores en el desplazamiento de los ítems en el tablero. 
  11. 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-requerida-por", "es-parte-de"/"está-compuesto-por", etc. 
  12. El Backlog de un producto 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 un ítem antes de implementarlo (por ejemplo, definición, validación, estimación, etc.) El Backlog de un producto puede contener cientos de ítems. La gestión efectiva del trabajo pendiente y su priorización para ser implementados son la clave para el éxito (ver Gestión efectiva del Product Backlog). El Backlog está en constante cambio; se añaden item, se reordenan, se definen y estiman, se particionan, se agrupan, etc. Todo este trabajo realizado con post-it puede llegar a ser inviable.
  13. Si bien, en general no es una práctica 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 a ítems, es decir, que cuando el ítem 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 pre-asignaciones en el ítem. La pre-asignación puntualmente puede ser interesante cuando se prevé en un ítem 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 resutado gracias a la esperiencia o especialización requerida. Esto en un kanban manual es difícil de representar. Normalmente en los kanban manuales solo se indica con un avatar los que están participando en un ítem, o a lo más los que están o han participado, pero no se suele indicar quienes participarán en cierta actividad (columna) a la cual el ítem aun no ha llegado.
  14. El tablero manual no responde adecuadamente a situaciones de re-trabajo, 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 re-trabajo es cuando en testeo se detecta un fallo asociado a un defecto de programación o de análisis. En general si el defecto no impide continuar con la actividad actual lo aconsejable sería que el ítem se mantuviera en ella hasta completarla y luego devolver el ítem a la actividad donde deben resolverse los defectos detectados. Cuando el ítem se mantiene en la actividad actual debe indicarse que tiene un re-trabajo pendiente y que el encargado de hacerlo debería, en general, darle prioridad. En cualquiera de los casos, habría que evaluar si una vez terminado el re-trabajo en la actividad anterior también debería hacerse re-trabajo en otras actividades intermedias. En un post-it se pueden poner decoraciones para indicar que el ítem tiene algún defecto por resolver y también para indicar con uno o varios avatares quienes están trabajando en él, sin embargo, todo el registro asociado a los fallos y defectos detectados, o respecto a los datos históricos no suele considerarse. Una situación similar de trabajo en paralelo de varios participantes sobre un ítem es cuando se puede ir adelantando cierta actividad (por ejemplo adelantar algo de programación o de diseño de tests), en este caso el ítem 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 TUNE-UP Process (www.tuneupprocess.com) considera todos los aspectos mencionados. La siguiente imagen muestra el Multi-kanban de TUNE-UP. WU es la abreviación de Work Unit (unidad de trabajo) el nombre dado en TUNE-UP a los ítems. El Multi-kanban de TUNE-UP sintetiza múltiples tableros kanbans. El kanban básico es uno en el cual se ven las WUs de todos los agentes participantes en un determinado sprint. En el Multi-kanban de TUNE-UP, gracias a filtros, puede además ofrecer una vista del kanban de cada agente participante, de un producto, del sprint de un producto, del backlog de un producto o una vista de un proyecto. Desde el kanban de TUNE-UP existen diversas formas para acceder a las unidades de trabajo y visualizarlas en otro formulario denominado Gestor de Unidades de Trabajo el cual correspondería a un post-it del kanban de pared, pero siendo un contenedor muchísimo más potente de toda la información relacionada con la unidad de trabajo. Lectura recomendada: Multi-kanban, un tablero kanban para contextos multiproyecto.




Patricio Letelier

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



¿Revolución o evolución hacia el agilismo? ¿Cuál es tú estrategia para implantar métodos ágiles?

El sentido común no se resiste a las ventajas del agilismo. 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 en otros ámbitos. El interés por el agilismo 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 más de una década del Manifiesto Ágil sigue sin ser suficientemente atendido el desafío que implica la implantación efectiva de métodos ágiles en una organización. Las dificultades para implantar metodología ágiles comienzan a ser evidentes [1][2][3][4] y 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 agilismo 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 (leer acerca del término Post-Agilism).

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, 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 tomar las decisiones 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é otras 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 agilismo? ¿debe resignarse a que el agilismo no es para ellos? ¿qué tan importante es poder calificarse como equipo Scrum o XP?

Sí, existe otra alternativa, y consiste en implantar el agilismo 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 respecto del agilismo. Los elementos del agilismo 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 cuatro principios del agilismo (del Manifiesto Ágil) e incorpore los elementos ágiles que le aporten mayor valor, y que a su vez puedan ser efectivamente aplicados en un contexto y momento determinado.

Curiosamente, CMMI, 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 propios mecanismos, por ejemplo, limitar el WIP (Work-in-Progress) para abordar las limitaciones que presente el flujo del trabajo, lo cual en cuanto a prácticas ágiles puede no ser suficiente ni lo más rentable para el contexto de un equipo.

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 agilismo debería ser "razonable" en términos de que su preparación se corresponda con la rentabilidad conseguida. La implantación 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 aunque sean parciales. 



¿Existen herramientas para gestión de proyectos software que apoyen está estrategia evolutiva?. Aunque la recomendación es demasiado cercana, hasta donde llega mi conocimiento sólo nuestra herramienta TUNE-UP (www.tuneupprocess.com) permite dicha evolución, es decir, 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. Son escasas las propuestas como la nuestra, que aborden la implantación del agilismo (y su posterior mejora) desde una perspectiva integradora de prácticas ágiles, independientemente de si ellas provienen de XP, Scrum, Kanban o Lean. 

[1] Agile's Teenage Crisis?, Philippe Kruchten, http://www.infoq.com/articles/agile-teenage-crisis
[2] “Scrumbut and Modifying Scrum”, http://www.scrum.org/scrumbut
[3] “Flaccid Scrum”, Martin Fowler, http://martinfowler.com/bliki/FlaccidScrum.html
[4] “Succeding with Agile: Software Development using Scrum”, Mike Cohn, Addison-Wesley, 2009.



Patricio Letelier

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