He estado leyendo un poco sobre Kanban y estoy un poco confundido sobre el tema de Requisitos.
En mi proyecto actual usamos Scrum. Al comienzo de un Sprint, tenemos una sesión en la que el BA hace un recorrido de la Historia y la describe lo mejor que puede. Luego tomamos la historia, la revisamos, la discutimos y preparamos preguntas para el BA para la próxima sesión de planificación de Sprint. En la próxima sesión, el BA responde a todas las preguntas y la sesión termina con nosotros entendiendo los requisitos (bueno, la mayoría del tiempo).
El siguiente paso es que luego produzcamos un diseño técnico y desarrollemos la solución / historia.
Con Kanban, todo lo que leo sugiere que no hay planificación de Sprint en Kanban. Mi pregunta es ¿en qué punto (en Kanban) se sientan juntos los técnicos y los empresarios para discutir el requisito de la historia? ¿El Gerente de producto o BA no ofrece un recorrido de la historia en Kanban?
Con Scrum, el BA generalmente está disponible en todo el Sprint para apoyar el desarrollo y supongo que es lo mismo con Kanban. Sin embargo, no está claro para mí cómo con Kanban, los técnicos entienden la historia si no hay una planificación de sprint.
fuente
Respuestas:
Tienes razón en que Kanban no tiene el concepto de Sprints o Sprint Planning como Scrum. Eso es porque es una metodología más ágil . Se hacen más cosas justo a tiempo .
Depende de usted decidir cómo programar las actividades de planificación, pero recomendaría hacerlo lo más cerca posible del inicio del trabajo. Esto es más efectivo cuando hay representantes de todas las principales partes interesadas integradas en el equipo (lo mismo también hace que Scrum sea más efectivo).
Creo que este diagrama, basado en la entrega ágil disciplinada , ofrece una buena representación gráfica de un proceso de software optimizado:
Los eventos del Standup diario y la planificación de Sprint se capturan en la reunión de coordinación y la sesión de modelado de reabastecimiento. La Reunión de coordinación es más como una Standup diaria de Scrum y una Sesión de modelado de reabastecimiento es más como Refinamiento de trabajos pendientes y Planificación de Sprint. Sin embargo, está bien incluir algunas discusiones de requisitos en la Reunión de Coordinación si eso funciona para su equipo.
Como la mayoría de las cosas en un proceso ajustado, esto sucede justo a tiempo. No hay timeboxes y los eventos no suceden en una cadencia particular como lo hacen en Scrum. Usted hace el trabajo cuando agrega valor para el equipo y las partes interesadas.
Que puede comparar con una representación gráfica de un proceso basado en Scrum modelado en el contexto de Entrega ágil disciplinada:
En lugar de limitarse a Sprints de 2 a 4 semanas con planificación al inicio, stand-ups diarios y una revisión y retrospectiva al final, las metodologías más ágiles promulgarán su demostración, coordinación y reuniones retrospectivas cada vez que los interesados piensen que es apropiado .
Kanban le proporcionará orientación para administrar su trabajo atrasado y su trabajo en progreso (WIP). Puede recurrir a otras técnicas y métodos para la implementación exacta de otras actividades, ya que Kanban generalmente no dice nada sobre ellas.
fuente
Usted está tergiversando / malentendiendo ligeramente lo que hace la reunión de Planificación de Sprint en Scrum, que creo que es la causa de su confusión. Una reunión de planificación de Sprint suele ser el lugar equivocado para resolver los detalles de las historias. Además de algunos ajustes finales y una revisión rápida para asegurarse de que no haya preocupaciones pendientes que impacten significativamente las estimaciones, las historias que se consideran deberían estar listas en su mayoría. A partir de ahí, la planificación de Sprint hace lo que dice en la lata: planifica lo que será en el próximo sprint. Si no tienes sprints, entonces no hay necesidad de Sprint Planning.
Entonces, ¿cuándo se desarrollan los detalles de las historias? Típicamente a través de Backlog Grooming o en comunicaciones continuas durante sprints anteriores. El objetivo aquí es obtener suficiente claridad para que se pueda dar una estimación razonablemente segura. Esto no requiere que cada detalle se resuelva con anticipación. No importa cuánto lo intente, siempre habrá preguntas que surjan durante la implementación. El objetivo en Scrum es que las preguntas que surjan durante la implementación sean relativamente menores (esencialmente, lo suficientemente pequeñas como para que no afecten lo que habría sido la estimación).
En Kanban, la estimación es opcional. Si estima, entonces es probable que haga algo similar a Scrum en el sentido de que antes de que se cuente la historia, se discute para calcular una estimación. Si no hace una estimación, el comportamiento real es similar, excepto que no puede discutir una historia hasta que se inicie.
En mi experiencia, típicamente he trabajado en equipos que usaron un enfoque tipo Scrum para el desarrollo principal y luego cambiaron a un enfoque más Kanban para la fase de mantenimiento. El trabajo en la fase de mantenimiento tiende a ser más esporádico, y las historias se definen más claramente ab initio y en menor escala. En la fase principal de desarrollo, las historias a menudo comienzan a un alto nivel y necesitan ser refinadas y desglosadas para llegar a un punto en el que sean aceptables para un sprint. Comenzar tales historias en un contexto Kanban tiene poco sentido y absolutamente hundiría sus métricas.
No existe un rol oficial de "Analista de negocios" en Scrum o Kanban. Es el equipo que analiza y estima historias. Si Sprint Planning es la primera vez que el equipo de desarrollo escucha los detalles de las historias, entonces algo va mal. No digo que no pueda utilizar un BA o que cada desarrollador deba estar en cada reunión de reunión de requisitos, pero algunosLa representación de los desarrolladores debe ocurrir en algún momento durante la recopilación de requisitos antes de la planificación de Sprint. Un BA generalmente no tiene los conocimientos suficientes sobre los detalles de la implementación para saber el costo de las cosas o qué preguntas podrían tener un impacto significativo en el costo. Esto significa que puede haber detalles que pueden afectar drásticamente las estimaciones que no se reconocerán hasta que el equipo de desarrollo las vea. Además, los desarrolladores pueden proporcionar orientación hacia enfoques más rentables o sugerir características que son relativamente fáciles de implementar pero que pueden agregar mucho valor para el usuario. Lo que sospecho que podría estar sucediendo en su caso, es que los desarrolladores están ayudando al BA a medida que el BA está reuniendo los requisitos (por ejemplo, respondiendo preguntas para el BA o proporcionando algún orden de estimación de magnitud), y que esto está reemplazando más o menos el Backlog Grooming. Alternativamente, está haciendo un trabajo (por ejemplo, trabajo de mantenimiento) que, naturalmente, llega en paquetes relativamente pequeños, en cuyo caso Kanban puede ser un proceso más apropiado.
fuente
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:
Utilizando estos como sus principios rectores, implementará las prácticas estándar del Método Kanban, que son:
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é.
fuente
Para concentrarse específicamente en sus preguntas ...
El Método Kanban , iniciado por David Anderson, no contiene una práctica o recomendación específica sobre cuándo ocurren estas actividades. La respuesta que cualquier profesional de Kanban proporcionaría es que inicialmente cuando adopta el Método Kanban , debe realizar esta actividad de la misma manera que la realiza antes de decidir evolucionar la forma en que maneja el trabajo. Si lo realiza cada 2 semanas, debe continuar haciéndolo cada 2 semanas.
Su equipo descubrirá si hay una oportunidad y un valor en cambiar el horario. Recuerde que el horario de 1 mes es más ágil que el de 1 año, el horario de 2 semanas es más ágil que el de 1 mes, 1 semana es más ágil que las 2 semanas. Este pensamiento eventualmente nos lleva justo a tiempo como los más ágiles . Ser el más ágil no debería ser la condición objetivo antes de comenzar.
El Método Kanban como una mentalidad y un conjunto de prácticas no imponen condiciones ni restricciones a la existencia de un Sprint, una reunión de Planificación de Sprint o cualquier otra práctica. Es completamente respetuoso con un equipo Scrum y sus prácticas. Si tiene una reunión hoy donde los Techies discuten la historia, continuaría teniendo esa reunión, utilizando el mismo horario.
No podría decirle en buena conciencia cuál sería / debería / podría ser el cronograma sin comprender a su equipo y la organización que lo rodea. Si no realiza estas actividades hoy, hay muchas otras fuentes de información que le enseñarán cómo hacer estas actividades. El Método Kanban puede brindarle orientación para enseñarle a descubrir si sus elecciones son buenas.
Lea las publicaciones de blog en estas dos series. Uno de mí y uno de Steve Porter, miembro del equipo en Scrum.org.
Nada en Kanban previene Scrum - Dave White - WesternDevs.com
Scrum y Kanban - Más fuertes juntos - Steve Porter - Scrum.org
fuente
La mayor parte de lo que dice Mahesh Singh en la parte superior es del material de capacitación publicado de Lean Kanban Inc. Entonces, realmente ... no hay nada de qué discutir aquí. Hable con cualquier AKT o KCP y él / ella dirá lo mismo.
A la pregunta original sobre dónde podría hacer aclaraciones de requisitos, hay varias opciones:
Podrías hacer lo que haces hoy, pero visualizando y poniendo esos pasos en una cadena de valor, identifica tus impedimentos. Luego, haga un cambio y vea cómo funciona. La comunidad de Toyota Kata llama a esto como experimentos de un solo factor.
Haga un tablero ascendente para la refinación de requisitos, la descomposición, el diseño de UX / interacción, etc. En nuestro propio equipo, dividimos Temas en Epics, hacemos el ciclo completo de diseño de UX y solo luego lo dividimos en historias. Luego, las historias se priorizan al reunir a todos los interesados en una reunión. El final de este flujo de valor da como resultado historias refinadas y priorizadas. Eso constituye nuestra cartera de pedidos para el equipo de desarrollo. De hecho, este flujo lleva mucho tiempo de ciclo, principalmente porque lleva tiempo pasar de un requisito de nivel épico a estructuras de alambre en Sketch o Zeppelin para el equipo de desarrollo.
Si no tiene un flujo de valor significativo o un tiempo de ciclo para convertir algo de requisito a historias refinadas, entonces simplemente podría tener una etapa en su flujo de valor de Desarrollo (como la aclaración de Requisitos). Sin embargo, Scrum espera un alto nivel de claridad para estimar y dividir las tareas. Entonces, ya sea que realice una reunión antes de la reunión de planificación de Sprint o una reunión de planificación de Sprint extendida, dependerá de su equipo y organización.
Si recordamos los principios y estamos abiertos a las prácticas definidas, el ciclo de Inspección y Adaptación se vuelve mucho más fácil.
fuente