¿Puede Gate cada Agile Sprint para brindar comodidad a las partes interesadas en Waterfall?

Un breve resumen de los hechos:

  • Compañía multinacional

  • Gestión de proyectos de cascada tradicional

  • Agile/Scrum siendo utilizado para el Diseño/Prueba/Construcción (>25 Sprints)

  • Las puertas de cascada tradicionales deben estar aprobadas para progresar

  • Las partes interesadas quieren una mini-puerta para sujetar cada sprint para medir
    el cumplimiento del cronograma

¿Puede funcionar este enfoque y qué artefactos deberían ser suficientes para la Gobernanza en cascada?

"Las puertas de cascada tradicionales deben aprobarse para progresar" ¿Significa esto, por ejemplo, que todos los requisitos deben recopilarse y aprobarse antes de comenzar con el análisis/diseño? Además, ¿tiene un propietario del producto designado o acude a un comité de gestión de cambios para aprobar los cambios?
Hay un Product Owner designado, sin embargo, para cambios importantes tenemos un Comité de Cambios como parte del proceso Waterfall.

Respuestas (2)

Esto es básicamente de lo que se trata Sprint Reviews en Scrum. Al comienzo de cada sprint, el equipo se compromete a entregar un incremento de producto funcional y desplegable que incluye una cierta cantidad de elementos pendientes. Y al final de cada sprint, el equipo demuestra a las partes interesadas las nuevas funciones que han completado.

En Scrum (y en los enfoques ágiles en general), la única medida real de progreso es el software que funciona. En mi experiencia, la mayoría de las partes interesadas pueden sentirse bastante felices mostrándoles un software funcional e implementable en lugar de (o encima de) documentos, gráficos y promesas de resultados futuros. YMMV: es posible que sus partes interesadas deseen ver algunos documentos, como informes de prueba, documentación del usuario, etc., además de la demostración del producto, así que esté abierto a la negociación.

Desafortunadamente no puedo votar por ti, pero te lo agradezco mucho. Has confirmado lo que yo pensaba que era el caso. Gracias.
@ Venture2099 ¿por qué no puedes votar esta respuesta? Lo supiste aceptar.
No tenía la repetición necesaria en ese momento, pero ahora la tengo; gracias por etiquetarme en esto y recordármelo.

Vota por Péter para la entrada en Sprint Review

He estado en un entorno similar tradicionalmente no ágil. Basado en mi experiencia, para responder a sus preguntas

¿Puede funcionar este enfoque?

  • Sí, podría funcionar.

    Pero depende de cuán disponibles estén las partes interesadas para la revisión y aprobación. Cualquier retraso en las aprobaciones podría generar retrasos en el progreso y la planificación de los próximos sprints.

    También depende de su comprensión de Agile, lo que permite a las partes interesadas tomar decisiones correctas sobre qué artefactos son opcionales para la gobernanza en cascada y ver qué artefactos en Scrum los reemplazan.

    Y la otra cosa que quiero enfatizar es que las partes interesadas están principalmente preocupadas por el " cumplimiento del cronograma ", lo que podría comunicarle al equipo que completar las tareas es la mayor prioridad, mientras que la realidad podría estar lejos de esto.

¿Qué artefactos deberían ser suficientes para la Gobernanza en cascada?

  • Diferentes organizaciones tienen diferentes metodologías de cascada probadas en el tiempo y requieren diferentes artefactos para la gobernanza. Así que realmente depende del proceso que esté siguiendo su organización. Los artefactos definidos en scrum (Product Backlog, Sprint Backlog y cualquier otro informe similar) deberían ser suficientes para una gestión exitosa del proyecto .

    dado que el requisito suele estar al final de la organización, un buen punto de partida es consultar al equipo del proceso (espero que su organización tenga uno basado en el resumen que ha proporcionado, sus partes interesadas también podrían dar su opinión sobre esto :)) & trate de identificar qué artefactos en su modelo de gobierno se pueden reemplazar con artefactos scrum y cuáles son opcionales.

Espero que esto ayude

+1 por mencionar la disponibilidad de las partes interesadas para la revisión: este es de hecho un punto crítico que no debe asumirse ciegamente. Con respecto a completar las tareas actuales, en un buen Scrum, el OP selecciona los elementos más valiosos actualmente para cada sprint, por lo que completarlos a tiempo genera el mejor valor para el dinero de las partes interesadas.
Como se indicó anteriormente, no tengo el representante para votarlo, pero su respuesta fue extremadamente útil.
No hay problema... sería genial si pudiera mantenerme informado sobre cómo fue, ejecutar Scrum (inicialmente) en entornos tradicionalmente estrictos orientados a cascada es (en mi humilde opinión) más desafiante que hacer lo mismo en un entorno ad-hoc. Algunas partes interesadas generalmente no están contentas con dejar de lado los artefactos tradicionales del proyecto a los que están acostumbrados (especialmente cuando se trata de informes). ¡Buena suerte!
¿Puede Gate cada Agile Sprint para brindar comodidad a las partes interesadas en Waterfall?
RespuestasAquíPolítica de privacidad1y, 0v