Nuestro equipo tiene una amplia variedad de tipos de elementos de trabajo. Parte del trabajo que hacemos está relacionado con proyectos, parte es operativo, parte lo generamos internamente nosotros mismos.
Para ser reactivos a las necesidades de la empresa y otros equipos, elegimos Kanban en lugar de Scrum.
Algunos proyectos más grandes todavía se gestionan en forma de cascada. Esto esta fuera de nuestro control.
En estos casos, comenzamos el desarrollo y las historias relacionadas con la transición del proyecto a través de varios estados en el tablero, y finalmente terminan en una columna UAT/QA, donde permanecen antes de que se lancen a producción al final del proyecto. Un proyecto puede durar hasta 12 meses (o, a veces, un poco más). El resultado es que terminamos con una gran cantidad de tareas acumuladas en esa columna y todas se cierran o se mueven a Listo de una sola vez.
El sistema kanban debe cubrir la parte del proceso sobre la que usted y su equipo tienen control. En su caso, parece que comenzaría con todo el trabajo del proyecto en la etapa 'To Do'. Llevaría tareas individuales a través del proceso durante la vida útil del proyecto. También parece que debería tener una etapa después de UAT/QA llamada 'Terminado'.
Si establece un buen límite WIP, en un momento dado, la mayoría de sus tareas estarán en 'Por hacer' o 'Listo'. Solo una pequeña parte del trabajo estará en progreso. La ventaja de esto es que puede comenzar a fomentar un enfoque más ágil en sus clientes. Si les permite revisar las tareas en la etapa 'Listo' a medida que se completan, la entrega final no tendrá sorpresas. Esto también le dará al cliente una buena visibilidad del progreso del proyecto. También debe permitirles hacer cambios en el trabajo que todavía está en 'To Do'. Si adquieren el hábito de revisar pequeñas piezas de trabajo y luego ajustar sus planes, estarás en la mayor parte del camino para convencerlos de que abandonen el enfoque de cascada.
Desafortunadamente, las dos soluciones propuestas sufren el mismo problema: nunca se sabe realmente cuánto trabajo queda en los elementos 'terminados'.
¿Qué sucede si cuando se llega al lanzamiento se encuentran algunos problemas importantes? ¿Cuánto tiempo llevará solucionar estos problemas? ¿Qué pasa si es necesaria una rediseño completo del código?
Usted habla de medir el tiempo del ciclo, pero sin conocer el trabajo restante en los elementos, el tiempo del ciclo tiene poco valor.
Por ejemplo, digamos que el equipo realiza algunos cambios en la forma en que funciona y mejora el tiempo del ciclo. El equipo está contento de que los cambios sean positivos. Luego, varios meses después, durante la integración final y el lanzamiento, descubre algunos problemas relacionados con los cambios que realizó. Ahora queda claro que los cambios fueron negativos.
Puede modificar las columnas en el tablero Kanban tanto como desee, pero dado que los lanzamientos ocurren con tan poca frecuencia, será difícil adoptar un enfoque genuinamente ágil. Agile funciona mejor cuando hay un ciclo frecuente de inspección y adaptación que le permite mejorar.
Mi sugerencia sería investigar si hay formas de hacer lanzamientos provisionales o algún tipo de entrega beta. Esto al menos le brinda la oportunidad de recibir comentarios regulares y adaptar sus prácticas de trabajo.
Una característica está lista cuando potencialmente podría lanzarse a un cliente. Puede haber buenas razones comerciales para no entregarlo al cliente, pero esto no cambia si se hace o no.
Entonces, si está listo para ser lanzado, márquelo como hecho. Realice un seguimiento para ver su tasa de revisita, si es alta, vuelva a evaluar la definición de hecho.
Como un proyecto separado, la empresa puede ver los niveles de inventario (trabajo terminado, que no se vende). No te metas con esto, en este momento.
Bart van Ingen Schenau
Adán Arroz