Karl Scotland inició un debate examinando si los workflows (flujos de trabajo) o etapas en un sistema Kanban se encuadran en las ideas ágiles de equipos colaborativos y multidiciplinarios (cross-funcionales). Comenzó citando que las etapas en un cuadro Kanban pueden ser muy similares a las fases del método de cascada. La discusión siguiente aclaró que las etapas no son necesariamente un pasaje de responsabilidad y pueden dar lugar muy bien a otros conocimientos.
Karl comenzó con el examen de un sistema Kanban aparentemente muy similar al proceso en cascada:
Análisis -> Construcción -> Test -> Lanzamiento
A continuación, presentó una típico cuadro de tareas de Scrum, parecido a esto:
A hacer -> En progreso -> Finalizado
Después Karl presentó maneras de cómo hacer que el cuadro de tareas revele más detalles de la información acerca de cómo el trabajo fluye a través del sistema. En muchos entornos, funcionalidades (historias) que se han marcado como "finalizadas" no son inmediatamente liberadas, o colocadas en un entorno de producción. En estos casos, puede resultar útil hacer una distinción entre «listo para producción» y «en producción" en el cuadro. Si el cuadro muestra que el trabajo en progreso está acumulado en espera de ser liberado, el negocio debe decidir perfeccionar el proceso mediante la adopción de implantación continua, por ejemplo.
Karl continúa para encontrar otras maneras de subdividir las etapas en el cuadro de tareas. También sugiere nombres que el siente que son más indicativos del trabajo que se realiza en cada etapa, por último llegando a este flujo:
Incubado -> Ilustrado -> Instanciado -> Demostrado -> Liquidado
A partir de este momento el debate comenzó con Robin Dymond citando que simplemente cambiar las etiquetas, no quiere decir que el comportamiento va a cambiar, pero cambiar las etiquetas pueden ser parte de una solución mayor:
El mejor enfoque es simplificar el proceso usando equipos multi-funcionales co-alocados, poner las pruebas al frente del proceso, y hacer que todos sean los responsables de la calidad, incluido el cliente. En este caso, yo usaría palabras diferentes, porque los pasos del proceso son mucho menos importantes que cómo los equipos trabajan en conjunto para entregar las funcionalidades.
Keith Braitwaite hizo esta observación:
Sugiero que por más que los procesos similares a Kanban sean descriptos en términos (e imágenes) que no sólo permiten, sino que permiten positivamente una interpretación lineal, bloqueos y contratiempos, falta de planificación y retrabajo, y mucha gente será resistente a esta idea.
Esta observación es congruente con gran parte de la doctrina ágil, que busca evitar contratiempos y eliminar o encontrar las secuencias, a fin de facilitar los ciclos de retroalimentación más cortos y rápidos. Por ejemplo, mientras que la práctica ágil de desarrollo orientado a las pruebas (TDD) tiene las etapas:
Prueba -> Codificación -> Refatorización
En la práctica, el desarrollador hará ciclos a través de estas etapas tan rápido que hacer el seguimiento de ellas en un cuadro de tareas sería tedioso.
En la perspectiva lean, lo importante es que las funcionalidades son continuamente empujadas a través del sistema (flujo continuo), en contraposición al trabajo que se encola y, a continuación, y entonces es completado en lote. El proceso de cascada tradicional es un ejemplo de un enfoque de lote y cola. Todo el trabajo de recopilación de los requisitos se lleva a cabo en un lote, con los requisitos siendo encolados esperando por el inicio del trabajo de diseño. Del mismo modo, el trabajo de diseño se realiza como un lote y la salida es encolada para la codificación, y así sucesivamente.
En un sistema de flujo continuo, las funcionalidades son empujadas del backlog y despues son trabajadas continuamente hasta que estes completas. Si existen etapas identificas durante el desarrollo, un cuadro Kanban puede utilizarse para identificar donde el progreso del trabajo se está acumulado. Estos problemas entonces son marcados para una mejora en el proceso, para mantener el flujo de trabajo fluido a través del sistema de manera eficiente.
El flujo de trabajo de una funcionalida es sólo este. La funcionalidad pasa por un número de estados del momento que se concibe hasta el momento que se despliega, se usa y se genera valor. Un workflow en Kanban no impone bloqueo entre los individuos. Igualmente es un hecho de que no hay demanda que el equipo no pueda atacar para asegurarse de que viaje rápidamente y sin problemas entre los estados.
Vasco Duarte consideró que el debate estaba muy centrado en procesos y herramientas, perdiendo la idea de Kanban, que es reducir el trabajo en progreso.
¿Por qué te preocupas? El hecho es que una secuencia Kanban (una funcionalidad del backlog para la liberación) es sobre un corto período de tiempo (un día, tal vez 2/3?) que la secuencia que utilizarás será muy similar a la de análisis, diseño, implementación, prueba, puesta en producción. Por supuesto que no es algo lineal, ¿porque estamos todavía discutiendo esto? porque una actividad se le asigna a un pequeño grupo de personas que sabrán qué hacer, incluso si esto significa "romper la secuencia."
De hecho, si el cuadro Kanban se utiliza para asegurarse de que cada una de las actividades necesarias ocurrieron, se está utilizando para reforzar la definición de hecho del equipo, siendo esto un trabajo más adecuado para una simple lista de verificación.
Para vos, ¿las etapas en un cuadro de Kanban son similares a las etapas de un proceso cascada? Si la respuesta es sí, ¿la similitud es superficial o significativa? Dejá un comentario y compartí tu perspectiva.
