¿Dónde encajarían las sesiones de desarrollo de aplicaciones conjuntas en el marco de Scrum?

La recopilación de requisitos se realiza a lo largo de la vida del proyecto por parte del propietario del producto. Por lo general, gran parte de esto ocurrirá antes de que el equipo de desarrollo comience a correr, pero al final de cada sprint, se lleva a cabo una reunión de revisión de sprint, lo que permite que el propietario del producto y las partes interesadas vean el estado actual del proyecto y el producto. Esto permite que los requisitos sean refinados.

En cuanto a las reuniones oficiales y formales que forman parte de Scrum, solo existen las de la Guía de Scrum . El standup diario, la retrospectiva, la reunión de planificación y la revisión. Cualquier cosa más allá de esto es parte del procedimiento de una organización específica, no parte de Scrum en sí.

Entonces, en este caso, JAD es una versión de recopilación de requisitos. El PO puede programarlos cuando lo desee para cumplir con sus requisitos y mejorar los detalles épicos / de la historia del usuario.

Sin embargo, el equipo Scrum debe estar protegido de estos tanto como sea posible. Si roban el tiempo de desarrollo de los equipos en el sprint actual, romperían los términos de scrum.

Puede ser necesario consultar con el equipo scrum para aclarar algún aspecto de los requisitos... pero debe ser solo en casos excepcionales.

En los equipos ágiles, normalmente tiene 5 capas de planificación:

Estas capas generalmente están vinculadas a un cuadro de tiempo, o lo que a menudo se denomina un 'horizonte de planificación', por ejemplo, la cantidad de detalles en los que entraremos en este momento se basa en la línea de tiempo de nuestras metas y expectativas. La fidelidad de nuestras discusiones va desde una milla de ancho y un pie de profundidad para la visión del producto, hasta 100 pies de ancho y 1000 pies de profundidad para cada iteración.

En Scrum, las discusiones de requisitos ocurren en todos los niveles de planificación y ocurren diariamente. Las ceremonias basadas en la cadencia establecen expectativas claras para cuando ocurran las discusiones más importantes. En Scrum, normalmente tiene un evento de planificación de lanzamiento cada pocos meses, con planificación de sprint cada 2-3 semanas y sesiones de refinamiento de backlog ~ 2 o más veces por sprint, y luego reuniones diarias.

La mayoría de los equipos de Scrum comienzan con una iteración 0, que no es un sprint, y durante la cual el equipo continúa desarrollando la visión del producto, la hoja de ruta del producto y las actividades de planificación de lanzamiento para el primer sprint. Esto generalmente se hace a través de talleres y actividades, en el transcurso de unos pocos días. Recomiendo consultar The Agile Samurai de Jonathan Rasmusson, ya que incluye una gran cantidad de material excelente para configurar un equipo Agile usando un 'Inception Deck'.

https://www.amazon.com/Agile-Samurai-Software-Pragmatic-Programmers/dp/1934356581/ref=sr_1_1?ie=UTF8&qid=1514494663&sr=8-1&keywords=the+agile+samurai

Permítame preguntarle por qué considera mudarse a Scrum. La transición a Scrum es mucho más difícil, en comparación con una transición a Kanban . En este artículo, hablamos sobre la implementación de una estructura de descomposición del trabajo Kanban utilizando el método Kanban y la ejecución de los elementos de trabajo de la manera más rápida posible. En otras palabras, proponemos una transición de Waterfall (WBS es un enfoque de cascada típico) a Kanban, que es un enfoque ágil ligero.

Este enfoque no solo le permite seguir haciendo lo que ha estado haciendo (y mejorar continuamente), sino que acelerará las cosas de manera ridícula (hasta un 700%). Espero que esto no suene como un argumento de venta, porque no lo es, pero Kanban realmente puede hacer milagros por ti.