¿Cómo podemos integrar continuamente nuevas funciones cuando el PO solo determina si una función está "terminada" al final de cada Sprint?

El equipo dice que la historia está hecha. Piense en esto en un guión gráfico donde el equipo marca la historia como lista para pasar (terminada o completada) al estado aceptado.

El propietario del producto acepta la historia (haciéndola aceptar), pero su aceptación solo indica que la historia se realiza en términos de funcionalidad comercial.

Por lo tanto, la aceptación por parte del propietario de un producto es solo parcial para decir que la historia está terminada. Hecho va más allá de la aceptación de PO porque también abarca las partes no funcionales de terminar una historia. QA, deuda tecnológica, etc.

Un modelo para manejar la integración y las historias terminadas es colocar estas historias en un entorno de ensayo. La puesta en escena es un clon o una réplica cercana de su entorno de producción. También es donde los equipos de integración irían a consumir cualquier código. Su propietario del producto utiliza este entorno para validar que se cumplan los requisitos funcionales de la historia y aceptar la historia. Esto no tiene por qué suceder durante la ceremonia de revisión. Puede ocurrir en cualquier momento a lo largo de la iteración, pero lo ideal es que se complete poco después de que finalice la iteración (de lo contrario, mantendrá el entorno de escenario como rehén y no podrá registrar nuevas funciones).

Para llegar a la puesta en escena, todos los criterios de finalización (funcionales y no funcionales) ya deben estar completados.

Estoy simplificando un poco con este modelo ya que hay criterios que pueden ocurrir en producción en algunas situaciones. Pero la mayoría de los criterios de finalización deben cumplirse antes de que el código de tiempo entre en escena.

Desde Scrum.Org:

El DoD suele ser una lista clara y concisa de los requisitos que debe cumplir un incremento de software para que el equipo lo considere completo. Hasta que no se cumpla esta lista, no se realiza un Incremento de producto . Durante la reunión de Planificación de Sprint, el Equipo Scrum desarrolla o reconfirma su DoD , lo que le permite al Equipo de Desarrollo saber cuánto trabajo seleccionar para un Sprint determinado.

La oración clave para mí es que el equipo Scrum (especialmente el propietario del producto) desarrolla y confirma el DoD. Es un estándar acordado antes de que comience el trabajo de Sprint.

Si el Product Owner no considera que se ha cumplido la Definición de Listo, entonces técnicamente el Equipo Scrum no ha cumplido la Definición de Listo y el PO se reserva el derecho de rechazar las Historias de Usuario como no hechas.

Editar para agregar

Scrum Alliance tiene un gráfico útil para garantizar que la Definición de Listo sea simple, transparente y consistente. Tenga en cuenta las dos casillas que indican

• Aprobación del propietario del producto
• Test de aceptación

Sé que algunos en la comunidad responderán con ira por mi estricta postura con el Product Owner, pero en mi opinión, es absurdo pensar que los desarrolladores pueden decidir cuándo tomar el trabajo, qué constituye la finalización de ese trabajo y luego forzar ese trabajo. en la columna Listo, independientemente de las expectativas del propietario del producto.

El propietario del producto gestiona las partes interesadas, los requisitos comerciales y asume el riesgo en nombre de la entidad comercial. Por supuesto, absolutamente deben poseer la Definición de Listo.

Como acto de equilibrio, el Equipo Scrum posee la Definición de Listo que les permite rechazar las Historias de Usuario del Propietario del Producto debido a especificaciones poco claras, problemas técnicos, trabajo de dependencia o cualquier otra preocupación válida.

En última instancia, si permitimos que los Equipos Scrum marquen su propia tarea y envíen productos a una empresa sin la debida diligencia del Propietario del producto, los resultados podrían ser terribles.

Además, eso no se adapta a Scrum of Scrums; de lo contrario, cada equipo de Scrum simplemente proclamaría que su dependencia estaba 'terminada' sin un propietario del producto que considerara que todo el producto estaba progresando.

Enfoques personales

Aparte, pensé que sería útil ilustrar cómo controlo este problema como Scrum Master.

• Cuando se ha probado una historia de usuario de desarrollador de back-end, entra en "Siendo verificado", donde lo discutimos con el PO.
• Si la orden de compra no está de acuerdo, solicito las especificaciones comerciales o los requisitos que demuestren que no está "hecho".
• El 95 % de las veces me pongo del lado del desarrollador y motivo al propietario del producto para que produzca una nueva tarjeta para la cartera de productos o acepte la finalización actual.
• Business Intelligence Front End Development en nuestro entorno es más complicado, ya que se requieren muchas más pruebas, incluida la UX y la reconciliación de datos entre las salidas antiguas y las nuevas.
• En este punto, el PO representa al usuario final y actúa como cliente.
• Damos al propietario del producto mucha más capacidad para rechazar informes en esta etapa

Como todo lo relacionado con Scrum (y Agile), se debe lograr un equilibrio para garantizar la armonía del equipo, la confianza y un equipo de alto funcionamiento. Tomo las partes de Scrum que necesito para lograr eso y adapto el resto.

Algunos podrían decir que ya no estoy haciendo Scrum, pero la verdad es que no necesito la etiqueta, lo que necesito es un Centro de Inteligencia de Negocios altamente productivo.

Al OP, le digo esto:

¿Se adapta a sus necesidades que el propietario del producto rechace las historias de usuario? Se honesto. Si él / ella es realmente hábil y bueno en su función, su rechazo de las Historias de usuario puede ser lo mejor que le suceda a su entrega, lo que le ahorrará al equipo una mayor cantidad de trabajo a largo plazo.

La fuente principal de su acertijo es el Product Owner que espera hasta el final del sprint para aceptar historias. La función de Sprint Review no es que el Product Owner revise y acepte el trabajo del Equipo. Corresponde al Equipo revisarse a sí mismo y presentar lo que se hizo a otras partes interesadas. El tiempo para la revisión, los comentarios y la iteración del propietario del producto debe incluirse en su cronograma de sprint.

Con eso en mente, respondamos a su pregunta principal "¿cuándo se solicitan funciones en nuestra rama de código de integración?"

Cuándo integrarse puede ser una decisión difícil. Es común tener un entorno de prueba que sirva como entorno tanto para la integración como para las pruebas de aceptación. Pero fusionar una característica puede ser difícil de evitar. Si el propietario del producto encuentra problemas importantes, ahora tiene un posible bloqueador para pasar a la producción y una rama no confiable para que se ramifiquen otras funciones.

Si es posible, el propietario del producto debe revisar y aprobar cada función de forma aislada antes de fusionarla con otras funciones. La aceptación de la característica en esta etapa significa que se ha realizado según lo previsto, aunque es posible que se necesite más trabajo para que se pueda enviar. La aprobación del propietario del producto en este punto debería ser la luz verde para continuar con el trabajo de integración e implementación de la función.

Aquí hay una forma en que se pueden manejar los conflictos de integración y fusión:

Digamos que dos características, A y B, se están desarrollando simultáneamente. La función A pasa a ser revisable primero y el propietario del producto la acepta. Ahora se puede fusionar en la rama de integración. Todas las demás funciones, a medida que se acercan a la posibilidad de revisión, deben prestar atención al progreso de la rama de integración y actualizarse desde la rama de integración. Este es el punto donde pueden surgir y resolverse los conflictos de fusión. Ahora la responsabilidad recae en el desarrollador de la Característica B para resolver cualquier conflicto. Esto puede incluso requerir modificaciones a la Característica A. Una vez hecho esto, el Product Owner ahora puede revisar la Característica B, junto con las modificaciones a la Característica A. Una vez aceptado, también se puede fusionar con la rama de integración.

TL;DR

Su implementación de Scrum tiene algunos conceptos erróneos, que parecen estar basados ​​en cómo implementar la "Definición de Listo" de una manera colaborativa adecuada. Si soluciona esta falla de comunicaciones, sus esfuerzos continuos de integración deberían volverse mucho más fluidos.

Además, ayudará mucho a su equipo a centrarse en la naturaleza iterativa de las metodologías ágiles; la agilidad hace hincapié en el refinamiento del producto a lo largo del tiempo, más que en la ejecución perfecta de las "especificaciones" dentro de cada incremento. El Product Backlog es un documento vivo, y las historias en el backlog se agregan, cambian o eliminan al menos en cada iteración. No es un conjunto de requisitos de una sola pasada, y su equipo necesita aprovechar esa flexibilidad.

¿Cuándo se hace algo?

En Scrum, una historia de usuario o incremento se considera terminado cuando ha logrado su objetivo establecido y cumple con los criterios existentes que el Equipo Scrum en su conjunto (que incluye al Dueño del producto) ha acordado previamente.

Considere la siguiente historia de usuario:

Como cliente de navegación web,
quiero ver todo en la página en letra de 300 puntos
para no sufrir fatiga visual.

Esta historia estaría hecha cuando:

1. La fuente predeterminada del sitio web se había establecido en un tamaño ridículo.
2. El equipo está de acuerdo en que la implementación cumple con el objetivo de evitar la fatiga visual.

3. Se ha cumplido la actual "Definición de Listo", que se aplica a todas las historias del proyecto. Esta definición varía de un equipo a otro, pero puede incluir pruebas unitarias, pruebas de aceptación del usuario, empujar a un servidor de integración continua o abofetearse con caballa húmeda. Lo que.

   NB: El punto aquí es que el equipo (incluido el propietario del producto) está de acuerdo con la definición de antemano . No hay reconfiguración post facto de "Terminado".

4. Alguien en el equipo marca la historia como "terminada" en el Sprint Backlog.

Eso es. La historia ya está hecha. Puede o no hacerse bien , pero se considera completo a los efectos de Scrum. El propietario del producto debería haber estado involucrado durante todo el Sprint, por lo que si la función se ha descarrilado por completo, es probable que el problema sea la falta de participación del PO y debe abordarse durante la próxima retrospectiva del Sprint.

¿Qué pasa con las historias que no se hacen bien ?

Al final del Sprint, el equipo acumula puntos por todas las historias que todo el equipo (incluido el propietario del producto) acuerda que se completaron de acuerdo con la Definición de Terminado. Si las historias se completaron de esta manera, pero no son satisfactorias de alguna manera, eso es agua para el molino durante la Retrospectiva del Sprint y para otras reuniones de inspección y adaptación. No cambia el hecho de que las historias se realizaron de una manera acordada, un acuerdo en el que el propietario del producto era una parte activa, por lo que no hay "aceptación" de las historias que se realizarán.

Sin embargo, durante la Revisión del Sprint (mi exposición en negrita):

• El propietario del producto explica [a las partes interesadas] qué elementos de la cartera de productos se han "Terminado" y qué no se ha "Terminado". Este es un informe de estado, no una oportunidad para aceptar o rechazar historias.
• El Equipo de Desarrollo demuestra el trabajo que ha "Terminado" y responde preguntas sobre el Incremento. A menudo, este es un buen lugar para explicar fallas que, sin embargo, están "Terminadas" y para solicitar comentarios de las partes interesadas sobre cómo mejorarlas en una iteración futura.
• El propietario del producto analiza la cartera de productos tal como está. Él o ella proyecta las fechas probables de finalización en función del progreso hasta la fecha (si es necesario). Este es otro punto de inflexión en el que las partes interesadas pueden decidir si una característica imperfecta es "suficientemente buena" o si necesita ser reelaborada o agregada nuevamente a la Lista de Producto tal como está.
• Todo el grupo colabora en qué hacer a continuación, de modo que Sprint Review proporcione información valiosa para la planificación de Sprint posterior. Aquí es donde podría tener lugar una discusión limitada de las fallas, pero la mayoría de los problemas del proceso deben abordarse en la Retrospectiva de Sprint.

Luego, durante el refinamiento de la cartera de pedidos o la planificación de Sprint, el propietario del producto puede tomar las historias que se completaron pero que no entregaron el valor deseado y:

• Escribe nuevas historias para abordar cualquier deficiencia.
• Vuelva a colocar las historias en el Product Backlog, con suerte con más detalles o una mejor comprensión con el equipo de las metas y objetivos de la historia.
• Decida que las funciones, tal como se entregan, son "suficientemente buenas" o que no necesitan iterarse nuevamente.

Conclusión

En resumen, el propietario del producto no puede declarar por sí solo si una historia está terminada o no. Después de todo, la "definición de hecho" es una colaboración entre todos los miembros del Equipo Scrum.

Sin embargo, el propietario del producto (como el único custodio de la lista de pedidos del producto) puede determinar si una historia se puede marcar como completada en la lista de pedidos del producto o si es necesario volver a hacer elementos de la misma en otro Sprint. Sin embargo, probablemente no sea una buena idea volver a colocar la historia original en la parte superior del Product Backlog sin abordar los problemas subyacentes con la historia, el proceso Scrum o la comunicación del Equipo Scrum, por lo que el Scrum Master definitivamente debería ayudar en ese punto.

Esta es una buena pregunta, con la que luchan muchos equipos.

El propietario del producto toma su decisión sobre si una historia de usuario está "terminada" al final del sprint, durante la reunión de revisión del sprint.

No. El Dueño del Producto acepta las Historias de Usuario "terminadas" durante el Sprint.

Entonces, todo el ciclo de vida de la historia (por hacer, en progreso, terminado, empujado a dominar) ocurre antes de la revisión de Sprint. Y una vez que Story se empuja a la rama maestra, otras ramas deberían incorporarlo y solucionar los conflictos, si los hubiera.

La aceptación de Historias de usuario puede demorar un par de días, por lo que la reunión de revisión de Sprint no se lleva a cabo para aceptar Historias de usuario. Se lleva a cabo para comparar lo planificado con lo real y evaluar si se cumplió el objetivo del Sprint.