https://www.javiergarzas.com/2016/11/swarming-one-piece-continuous-flow.html
Lo de Swarming, cuya traducción es algo así como “enjambre”, es una estrategia militar que consiste en atacar al enemigo con muchas unidades autónomas.
Quería hoy postear sobre esto, porque aunque es muy antiguo… creo que se olvida / desconoce en demasiadas ocasiones. Si sigues Scrum desde hace tiempo, y lo haces bien, consciente, o inconscientemente, habrás aplicado con frecuencia algo llamado Swarming o «flujo continuo de una sola pieza» (One-Piece Continuous Flow).
La idea es dedicar todos los esfuerzos a una única historia, entonces, todo lo necesario para completarla se hace tan en paralelo como sea posible. Además, cada miembro del equipo se centra en una sola historia de usuario a la vez, todo el mundo debe ayudar a que se termine la historia (item mejor dicho) de mayor prioridad.
Esto tiene varias ideas detrás…
Tener abiertas demasiadas cosas a la vez, reduce la efectividad por los cambios de contexto, cosas que se empiezan, no se terminan, se empiezan otras, vuelta a la primera, vuelta a pensar en qué estado quedó, etc. Esto hace sus años que lo hablamos, 2013, referenciando al mítico Weinberg, en trabajar en más de una tarea (ya no digo proyecto) a la vez genera pérdidas de tiempo y disminuye la productividad.
…por estas razones, las de evitar el cambio de contexto, y el desperdicio al que ello conlleva, que Kanban límite el máximo de trabajo en el proceso, el WIP, siendo esto que aquí estamos hablando, el Swarming o «flujo de una sola pieza», una alternativa al WIP de Kanban.
El tiempo entre el momento en que el equipo comienza a trabajar en una historia de usuario y está terminada (Definition of Done superado) es lo más corto posible.
La idea es más bien trabajar todos juntos para cerrar algo… más que trabajar cada uno en sus tareas (Sprint backlog) y que al final, tareas se vayan terminando pero items (Product Backlog) no. Los Dailys son una herramienta importante en todo esto, para enfocar al equipo.
En relación al anterior, el Swarming lleva a aumentar la multifuncionalidad del equipo (yo leería aquí … Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad)
Y dicho esto, el Swarming o «flujo de una sola pieza» nos implica, implica al equipo, a ordenar las tareas del Sprint Backlog, saber qué va primero, saber en qué poner primero todos los esfuerzos, que va después, teniendo en cuenta que el Product Owner previamente nos ha dejado priorizado el Product Backlog, haciéndonos saber cuál es el item del Product backlog más prioritario.
Es decir, que como sabemos cuál es el item más prioritario del Product Backlog, de ese item el equipo deriva las tareas necesarias para completarlo… y esas tareas debieran ser las más prioritarias del Sprint Backlog.
El Patrón Rey – Sirviente
En relación, y por esto, Henrik Kniberg, autor de “Scrum y XP desde las trincheras” (Entrevista a Henrik Kniberg), creó el patrón Rey – Sirviente, que, simplificádamente, consiste en lo siguiente:
Cualquiera que esté trabajando en la historia (item) de mayor prioridad es Rey y…
Todos los demás miembros del equipo son sirvientes.
Si quieres ser uno de los Reyes… tienes que ayudar con la historia de máxima prioridad.
Cuando un Rey necesita ayuda, los siervos ofrecen inmediatamente sus servicios.
Un Siervo no puede interrumpir a un Rey.
Tan pronto como la historia de máxima prioridad está terminada, cualquiera que trabaje en la siguiente historia es ahora Rey.
Terminando (o continuando)
Por supuesto, todo esto del Swaming no es un tema exclusivo del mundo ágil, y, obviamente, existen muchos trabajos previos (puedes encontrar mucho en Lean, en el método de Toyota, etc.), por lo que puedes profundizar y leer mucho sobre esto que aquí en el post apenas he introducido.
Así que esto…. para empezar, porque el tema requiere y me dará para más post…
