Agility at work: 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:

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 :-).
Asignación de workflows a producto. Cada producto tendrá un conjunto de workflows aplicables de acuerdo con las necesidades de sus ítems.
Cuando se crea un ítem, asignarle un determinado workflow.
Asignar personas a roles del workflow de un determinado ítem de trabajo.
Cuando se finaliza una actividad, que el ítem pase a estado pendiente en la(s) siguiente(s) actividad(es) del workflow que tiene asignado.
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.
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.

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.
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.
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).
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.
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.
Cambios en los agentes asignados a los roles del workflow del ítem.
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.
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.