¿Por qué los tableros Kanban solo contienen una implementación?

TL;RD

No hay una respuesta correcta o incorrecta aquí en términos de qué actividades, columnas y carriles pertenecen a un Kanban determinado. Sin embargo, es probable que su proceso esté siendo impulsado por una elección de herramienta de software en lugar de reflejar los flujos de trabajo reales y los acuerdos de trabajo en su proceso.

Debe evaluar cuidadosamente si ha capturado las abstracciones correctas para su proceso. También debe asegurarse de que sus colas Kanban realicen un seguimiento eficaz del flujo y la mejora continua de cada equipo en lugar del trabajo realizado por otros equipos .

Análisis y Recomendaciones

Kanban se basa en colas y flujos, pero se basa en sus colas y flujos. Podría decirse que es ineficiente tener colas previas y posteriores o transiciones de estado múltiples para cada actividad, por lo que muchos profesionales experimentados las omiten cuando no agregan un valor medible.

Además, muchos practicantes de Kanban en la actualidad lo hacen dentro de un contexto más ágil. Kanban-the-framework (a diferencia de varias prácticas, artefactos y metodologías de Kanban que se adoptan más ampliamente) a menudo está más alineado con Lean Manufacturing que con marcos ágiles de equipos pequeños como Scrum. Como resultado, las columnas de un solo tablero generalmente se alinean con las actividades realizadas directamente por el equipo, en lugar de mantener todos los estados posibles extrínsecos al flujo interno del equipo.

Si su equipo maneja directamente las implementaciones de UAT, preparación y producción, entonces sin duda debe reflejar esos flujos en su Kanban. Sin embargo, si esas actividades son externalidades manejadas por otros, entonces el trabajo debe moverse al Kanban apropiado (por ejemplo, no al suyo) cuando el equipo haya terminado. En tales casos, a menudo es más apropiado marcar el trabajo como "hecho" por parte del equipo y luego recibir comentarios sobre elementos más pequeños, como las tareas de implementación de la próxima etapa (quizás manejadas por un carril separado con su propio límite WIP) en lugar de continuar. para realizar un seguimiento del trabajo que se realiza fuera del flujo representado por el Kanban del equipo.

Con Kanban, una talla definitivamente no sirve para todos. Sin saber por qué ha elegido el nivel de abstracción que tiene para sus flujos de trabajo y comprender todas las métricas que está rastreando para determinar si esa abstracción es útil para usted o no, entonces no tiene sentido comparar sus abstracciones con de alguien más.

Todos los modelos están equivocados; es solo que algunos son útiles . Lo que debe preguntarse es si su modelo es útil. De lo contrario, centrarse en las deseconomías entre procesos (en lugar de tratar todas las actividades como internas, especialmente cuando no lo son) es un buen uso del ciclo de inspección y adaptación de su equipo.

Muchas empresas hoy en día no se molestan con el paso de implementación porque es demasiado trivial . Con la llegada de la entrega continua, para muchos de nosotros es solo hacer clic en un botón.

Además, Just-in-time (Kanban) implica mantener bajos los costos de inventario (trabajo sin terminar) , por lo que la cantidad de tareas en espera de publicación es 1 (en el mejor de los casos) o varias, lo que no es difícil de seguir. Por lo tanto, cuando sus probadores terminan de probar, saben que hay 2 tareas para liberar: simplemente continúan y se implementan en PRD. En dicho esquema no existe una "gran lista de tareas pendientes de liberación".

Si su proceso es más complicado (hay actividades después de las pruebas funcionales), entonces probablemente tendrá una columna para esas actividades y los probadores moverán la tarea a esa columna. Una vez más, la implementación en el entorno respectivo es cuestión de hacer clic en un botón, por lo que rara vez se necesita una columna adicional.