Definición de Hecho para muchos equipos Scrum

7

Recientemente comenzamos a usar el marco de Scrum y gradualmente fuimos de 1 equipo a 5. Estoy haciendo el rol de Scrum Master. En los últimos meses, cada equipo de desarrollo trabajó en su definición de finalización (DoD) con el propietario del producto. Cada equipo ha negociado su propio DoD. Hay algunas diferencias entre cada DoD.

Hoy en día, hay 1 Product Owner y 5 Scrum Masters y queremos usar un DoD único para todos los equipos. ¿Qué propone que hagamos para armonizar los DoD?

Propuestas que surgieron de nuestras discusiones:

  • Cada Scrum Masters trabaja con el propietario del producto para crear un nuevo DoD que presentarán a su equipo.
  • Cada equipo elige un representante (Desarrollador) que trabaja con el Propietario del producto para crear un nuevo DoD que presentarán a su Equipo.

En ambos casos, este sería un proceso iterativo para que cada Equipo pueda proporcionar comentarios y ajustar.

Gracias de antemano!

    
pregunta PSenez 15.06.2016 - 13:06

4 respuestas

2

Insistir en imponer un proceso fijo a los equipos anula la idea de trabajar de manera ágil. Cada equipo debe ser libre de organizarse de una manera que le permita trabajar mejor. Si eso significa que cada equipo tiene su propia definición de hecho, entonces debería aceptarse como la mejor solución. Si, con el tiempo, los equipos se comunican entre sí y se conforman con una sola definición, entonces es genial. Si las definiciones diferentes continúan funcionando para ellos, entonces manténgalo así.

    
respondido por el David Arno 15.06.2016 - 13:34
2
  

Cada equipo ha negociado su propio DoD. Hay algunas diferencias   entre cada DoDs.

La consistencia tiene su lugar, pero hasta que usted identifica los problemas que causa la falta de ellos, es difícil encontrar una solución.

El beneficio de Scrum / Agile es permitir que los equipos se administren solos. Si un equipo no puede llegar a un consenso sobre un tema, es bueno tener algunas reglas de administración que podrían ayudar a limitar el enfoque. Además, a medida que los miembros pasan de un equipo a otro, es bueno saber qué esperar con la esperanza de encajar de inmediato. ¿Hay algún problema aquí que estés intentando arreglar o evitar?

Entonces, para responder a tu pregunta, creo que estás en el camino correcto al tratar de obtener la opinión de todos, pero debes estar preparado para descubrir que existe tal falta de acuerdo, que debes olvidarte de un solo DoD y dejar que Cada equipo ajusta y evoluciona su propio significado durante el curso de este proyecto según lo crea conveniente.

Te estás metiendo en el territorio de administración jerárquica / descendente aquí, aunque involucres a todos. Tenga mucho cuidado al aplicar una regla rígida a todas las personas en todas las situaciones. Será muy difícil lograr que 5 equipos individuales revisen continuamente el DoD cada vez que haya una excepción.

    
respondido por el JeffO 15.06.2016 - 13:43
2

Compartiendo un núcleo común

Creo que es razonable tener un conjunto común de elementos básicos en su definición de hecho, pero debe ser flexible. Estos elementos comunes deben ser claramente obvios y necesarios para cada equipo, hasta el punto en que simplemente no hay ningún argumento de que deban incluirse.

Por ejemplo, cada equipo probablemente debería tener "tiene pruebas de unidad que pasan" como un elemento. Otro buen candidato es "debe registrarse en el control de versiones" y "debe pasar todos los criterios de aceptación".

Empoderamiento del equipo

Cada equipo debe tener la libertad de modificar su propia definición de hecho sin requerir la aprobación de un comité. Scrum se trata de equipo empoderamiento. Forzar a un equipo a tener una "definición de hecho" que fue diseñada por otra persona o equipo no es poder.

Por ejemplo, algunos equipos pueden querer requerir una revisión por pares, pero tal vez no sea apropiado para todos los equipos. Algunos equipos pueden requerir la cancelación de un experto en usabilidad, pero eso generalmente no tiene relevancia para un equipo que trabaja en un backend. Un equipo puede tener requisitos de cobertura de código más estrictos que otro, y así sucesivamente.

Scrum tiene que ver con el equipo

En scrum, el foco está en el equipo . Si eso significa que requiere un poco más de trabajo por parte del propietario del producto o scrum master, que así sea. La función del scrum master es eliminar obstáculos, no agregarlos.

    
respondido por el Bryan Oakley 15.06.2016 - 16:38
2
  

Si hay varios equipos Scrum trabajando en el sistema o en la versión del producto, los equipos de desarrollo en todos los equipos Scrum deben definir mutuamente la definición de "Hecho".

     

Si "hecho" para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe definir una definición de "hecho" apropiada para el producto.

     

The Scrum Guide

Sin una definición común de "Hecho" para un producto , la calidad y su transparencia se verán afectadas negativamente. Los niveles organizativos de definición de Hecho deben ser mínimos, técnicos y, en ocasiones, proporcionados por la organización para que se puedan aplicar universalmente. La organización puede proporcionar estándares de codificación. La organización puede requerir compilaciones automatizadas mientras proporciona los recursos para crearla y mantenerla para cada producto. Cualquier parte de la definición de "Hecho" ya sea creada por la organización o por un Equipo de Desarrollo individual debe aportar valor.

    
respondido por el Alan Larimer 11.10.2016 - 14:12

Lea otras preguntas en las etiquetas

Comentarios Recientes

este tema trata de eliminarlo del vocabulario de una persona e incluso de sus organizaciones y del evento en su conjunto. Sienten que la pérdida tiene que ser aceptada y no les gusta que ningún equipo u organización pierda a sus jugadores. Bien hecho, este tema no tiene connotaciones negativas o efectos secundarios dañinos, por lo que se usa como una herramienta experimentada de líder / entrenador líder. Hecho para el tipo de organización donde hay PFN, las circunstancias mejoran los resultados de su jugador,... Lee mas