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