Estamos construyendo una característica bastante grande e importante en un Equipo Scrum. El PM quiere colocar esta función en una rama separada y no implementarla durante 1 o 2 meses para que los usuarios puedan probarla correctamente antes del lanzamiento. Me parece extrañamente cascada.
¿Qué opinas? ¿Está bien en ágil hacer algo así? ¿O como Scrum Master debería sugerir dividir la función en partes más pequeñas y lanzarla con frecuencia?
Como Scrum Master, su responsabilidad es asegurarse de que su equipo siga el marco Scrum. La mejor manera de hacerlo es explicar las consecuencias de no seguir Scrum y cómo afectará a la organización.
Scrum habla de un Incremento potencialmente liberable al final de cada sprint. El valor de este enfoque es que:
El enfoque que se ha propuesto con 1 o 2 meses de pruebas de aceptación fuera de los sprints no generará un incremento potencialmente liberable. De hecho, podría ser un problema; si se descubren problemas importantes durante las pruebas de aceptación, el progreso que parece haber sido realizado habrá sido engañoso.
Como mencionas, dividir la función y lanzarla con más frecuencia es un mejor enfoque. Recomendaría sugerir esto y explicar por qué es la mejor manera de hacerlo.
Su equipo produce un incremento de producto potencialmente entregable al final de cada sprint. Si esto se somete luego a pruebas de aceptación y se libera realmente depende del cliente.
Por supuesto, divide la característica principal en elementos de la cartera de productos que se pueden manejar dentro del marco de Scrum, por lo que tomará varios sprints hasta que se complete, pero el cliente puede optar por no iniciar las pruebas de aceptación antes de que la característica en su totalidad esté disponible. .
La situación es similar a la fase inicial de un proyecto. Nadie espera que su equipo tenga un producto completo que cumpla con todos los requisitos al final del sprint 1 o 2. Los usuarios pueden experimentar con los incrementos que se producen durante cada sprint, pero las pruebas de aceptación para una primera versión solo pueden comenzar cuando el producto es realmente capaz. para cumplir con una parte razonable de los requisitos establecidos.
Un posible enfoque adicional a considerar, que podría tomarse junto con las admirables sugerencias aquí para dividir la función, es 'liberar' secciones de la función pero con un 'interruptor' para permitir que la función se apague o solo se encienda. para usuarios específicos/en circunstancias específicas cuando se publiquen las primeras partes de este. Esto puede ayudar si tiene una cadencia de entrega regular y necesita implementar esto en vivo con el resto del código, pero lo entregará en bits. Ayudaría a evitar la necesidad de una rama de función de larga duración separada, y permitiría eliminar el riesgo de los lanzamientos al permitir solo a usuarios específicos usar esta funcionalidad en vivo a medida que esté disponible.
En Scrum, el equipo trabaja para proporcionar el producto entregable como resultado de cada Sprint. Se recomienda utilizar el mismo timebox en cada Sprint (1 a 4 semanas).
Según el comunicado, PM quiere colocar la función en una rama separada y permitir que los usuarios la prueben durante 1 o 2 meses. Claramente, es una entrega de producto del equipo de Scrum (suponiendo que el equipo de Scrum ya haya probado al final) y el equipo de Scrum parece no participar en la aceptación.
Las pruebas de aceptación deben realizarse en la reunión de revisión de Sprint de cada Sprint. Si el equipo de Scrum está tratando el producto como entregado antes de una extensa prueba de aceptación y el equipo lo desmantela o lo traslada a otro sprint con características diferentes y el resultado de la prueba se agrega en el backlog para la futura planificación del Sprint, es posible que no sea Anti-Scrum.
Sarov
Łukasz Kupiec