Estoy editando mi respuesta en función de los comentarios que recibí para ayudarme a comprender cómo y cuándo debería trabajar en la etapa de Requisitos y Planificación de Sprint de su Sprint; como también sobre la aplicación del Método Kanban a sus procesos actuales. A los fines de mi respuesta, estoy usando los términos "Kanban" y "Método Kanban" indistintamente, y ambos me refiero a las recomendaciones del Método Kanban. Espero que esto ayude.
En primer lugar, no debe cambiar nada sobre su proceso de desarrollo / elaboración de requisitos "para Kanban", porque Kanban no hace ninguna recomendación allí. Todo lo que Kanban recomienda es que visualice sus procesos actuales, incluso alrededor de la administración de requisitos y la planificación de Sprint, implemente los límites de WIP y administre el flujo. Posteriormente, realice cambios en su proceso en función de los cuellos de botella y las oportunidades de mejora observadas.
[Sugiero encarecidamente que, si aún no lo ha hecho, lea el libro - " Kanban: cambio evolutivo exitoso para su negocio tecnológico " de David Anderson, el pionero del Método Kanban. (Descargo de responsabilidad completo: soy cofundador de una empresa de productos Kanban. También soy entrenador y entrenador Kanban certificado por la Universidad Lean Kanban).
Kanban en sí mismo no es una metodología de desarrollo de software / gestión de proyectos. Sin un proceso existente, no puede aplicar / implementar Kanban. Es un método para ayudarlo a mejorar de manera evolutiva (gradual, no disruptiva), sean cuales sean sus procesos actuales. En tu caso, ese es Scrum. Por lo tanto, realmente debería aplicar Kanban en sus procesos Scrum para ayudar a su equipo a mejorar la entrega de su software. La combinación de esto se conoce popularmente como Scrumban.
Comenzaría siguiendo los 3 principios básicos de Kanban:
- Comienza con lo que haces ahora
- Estar de acuerdo en buscar cambios evolutivos e incrementales
- Respetar los procesos, roles, títulos y responsabilidades actuales.
Utilizando estos como sus principios rectores, implementará las prácticas estándar del Método Kanban, que son:
- Visualice su proceso actual (y el trabajo en curso)
- Límite de WIP (trabajo en progreso)
- Administrar flujo
- Hacer explícitas las políticas de proceso
Comience con estas 4 prácticas. Hay otras 2 prácticas definidas en el Método Kanban que puede ver una vez que comience y tenga un control. Estos son (5) Implementar bucles de retroalimentación, y (6) Mejorar y evolucionar en colaboración, utilizando el método científico.
Este es un resumen rápido: el libro realmente lo ayudará a comprenderlos mejor. También hay una completa guía Kanban disponible en nuestro sitio web.]
Lo importante para enfocarse en su situación es visualizar (en un tablero Kanban) lo que está haciendo hoy. Su proceso actual de Requisitos debe seguirse durante el proceso de Planificación de Sprint o algunos pasos secundarios que puede elegir visualizar. Su tablero Kanban debería, de hecho, reflejar la planificación de Sprint como una etapa específica del proceso general de desarrollo, seguido de diseño técnico, desarrollo y prueba, según sea el caso.
Si bien las historias de los usuarios están en la etapa de planificación del sprint, seguiría los pasos dentro de eso, como el BA que le proporciona detalles, los desarrolladores preparan preguntas y las responden antes de que la historia pase a la etapa de diseño tecnológico y más allá.
(Por cierto, si su proceso de Requisitos tiene algún aspecto ascendente que podría considerarse parte de la planificación de la hoja de ruta o la preparación del trabajo atrasado, hay un tema completo de "Upstream Kanban" que lo ayuda a administrar mejor las actividades ascendentes con el mayor detalle posible) hoy. Usted o su BA / PO podrían considerar usar un tablero Kanban aguas arriba separado para administrar toda esa actividad).
Su flujo de tablero Dev Kanban podría verse como el siguiente
Backlog -> Sprint Planning -> Tech Design -> Dev -> Test -> Integrate -> Done
Cada una de las etapas puede tener sus propias sub-columnas "En progreso" y "Listo", aunque si un solo desarrollador lo lleva a través de todas las etapas, es posible que no necesite esas sub-columnas en cada etapa. Si crees que es importante, puedes dividir Sprint Planning en 3 sub-etapas: Detalle de la historia, Aclaraciones y Hecho, para que puedas estudiar cuellos de botella en cada aspecto del trabajo. Por ejemplo, en nuestro propio equipo de desarrollo, la revisión de código puede ser un cuello de botella a menudo.
Al final de su ciclo de sprint de 2 o 3 semanas, todas las historias de usuarios que se completen pueden salir colectivamente, y comenzará con el siguiente conjunto de historias del Backlog.
Durante un período de tiempo, puede decidir que algunos de los desafíos de hacer Scrum (pérdida de la historia, fechas límite de sprints perdidos, etc.) podrían abordarse eliminando algunas de las restricciones / reglas de Scrum, que pueden parecer ser sacrílego para algunos. Nosotros mismos hacemos lanzamientos de 4-6 semanas, y no hacemos Sprints. Pero igualmente bien, podría seguir trabajando con Sprints y lanzamientos. En nuestra experiencia, aquí es donde Kanban lo ayuda a decidir qué es lo correcto para su negocio o equipo y a adoptar o modificar sus procesos que lo ayudan a entregar su trabajo de la mejor manera posible, lo que maximiza el flujo, el rendimiento / la velocidad y reduce los plazos de entrega ( hora de comprar).
Ya sea que decida deshacerse de Sprints y solo realice lanzamientos cuando se haya construido una cantidad suficiente de características (o se hayan corregido defectos o una combinación de ambos), o si mantiene Sprints, Kanban debería ayudar a su equipo a trabajar más suavemente, eliminar cuellos de botella y mejorar el rendimiento del tiempo de ciclo. Si eso lo ayuda a hacer lanzamientos más frecuentes, lo que a su vez lo ayuda a obtener comentarios más rápidos de los clientes, ahora está pasando a lo que podría llamar un estado de cosas "más ágil", pero que no necesariamente se ajusta a la definición clásica del método Scrum.
Sin embargo, si los objetivos comerciales se cumplen mejor, los clientes están más contentos y su equipo puede funcionar de manera óptima, entonces habría logrado sus objetivos de implementar Kanban.
Espero que esto ayude. Si tiene alguna pregunta, con gusto la responderé.
