¿Cómo resuelvo que el Product Owner y el Team Lead dan requisitos contradictorios?

Digamos que un Product Owner que aprueba todo el trabajo antes de que pase a producción, escribe los requisitos como X.

El líder del equipo (desarrollador sénior) que aprueba todos los cambios de código dice hacer Y, que es contradictorio con X.

¿Cómo resuelve direcciones contradictorias entre dos personas, las cuales tienen autoridad sobre un proyecto?

¿Le ha señalado a alguno de ellos que hay una contradicción en los requisitos?
¿ Son estos requisitos técnicos o requisitos funcionales ? El propietario del producto es responsable de lo que hace el producto, el líder del equipo es responsable de cómo lo hace.

Respuestas (2)

Este es un caso en el que primero los metes a los dos en una habitación y los dejas discutir.

En un flujo de trabajo ágil, el propietario del producto define los requisitos. El líder del equipo tiene voz mientras se prepara la historia ( al igual que todos los miembros del equipo ), pero una vez que la historia está en el sprint, los requisitos no deben cambiar .

Si los dos no pueden llegar a un acuerdo/entendimiento, hable con su gerente , ya que este puede ser un problema que no puede resolver usted mismo.

Sin embargo, por el momento, parece que el líder de su equipo debe recordar que el propietario del producto define los requisitos y depende del equipo en su conjunto hacer que suceda (implementar).

Nota : si existe una razón técnica por la que un requisito deba cambiarse, debe discutirse con el propietario del producto antes de codificar .

Es posible que en Scrum los requisitos cambien durante un sprint como resultado de las cosas aprendidas durante el sprint, y tampoco es necesariamente algo malo.
@Erik estuvo de acuerdo como una excepción y no como la norma.
@Erik, por definición, desea que los requisitos para los elementos que se van a crear durante el sprint se establezcan en piedra; de lo contrario, esos requisitos aún no se comprenden lo suficientemente bien como para que este elemento se tome en un sprint. Uno de los puntos principales en scrum es que todo es fluido hasta el sprint, por lo que puede estar razonablemente seguro de que realmente puede entregar un incremento que cumpla con los requisitos. Si los requisitos cambian, debe volver a evaluar si podrá cumplirlos o no, lo que le quita tiempo a la creación del incremento.
@Cronax No, no lo haces. Si sucede algo extraño y tiene que elegir entre cambiar los requisitos y crear algo incorrecto, querrá cambiar los requisitos. Como dice Neo, debería ser una excepción, pero aún así es mejor que la alternativa cuando sucede.
@Erik, digo que no desea que ese sea un procedimiento operativo estándar porque en ese momento nunca estará seguro de si puede o no entregar un sprint. De hecho, diría que en lugar de simplemente tomar con calma los requisitos cambiantes, el procedimiento deseado sería detener por completo el sprint y, si la característica sigue siendo la forma más importante y adecuada de agregar valor, refinarla lo suficiente y luego comenzar una nuevo sprint. El equipo se compromete con la acumulación de sprint, cuando cambia los requisitos, ya no está haciendo lo que se comprometió.
Si necesitamos discutir esto más a fondo, sugeriría que lo moviéramos a un chat.
Los equipos de @Cronax no se han comprometido con los retrasos de sprint desde 2011 :)
@Erik, la palabra compromiso fue mal elegida, el concepto sigue en pie: sin un alcance acordado, nunca podrá entregar un sprint exitoso.

Haces lo que dice el líder de tu equipo. Se lo señalas, pero al final hay una cadena de mando, y estás en un equipo y él es el líder del equipo y, siempre que puedas señalar que planteaste el problema, es su trabajo. su responsabilidad y por lo tanto también su fracaso.

Tenga en cuenta que los comentarios de verificación son un lugar excelente y no modificable para señalar cómo este cambio contradice los requisitos del propietario del producto, pero lo exige el líder del equipo.

¿Cómo resuelvo que el Product Owner y el Team Lead dan requisitos contradictorios?
RespuestasAquíPolítica de privacidad1y, 0v