¿Cómo abordar la "definición de hecho" en Scrum?

La solución tradicional de Scrum sería preguntarle al equipo. Dado que el Equipo Scrum se organiza a sí mismo, gran parte de los métodos específicos para hacer las cosas deben dejarse en manos del equipo, con el Scrum Master entrenando al equipo para garantizar que se mantengan los valores, principios e intenciones de la Guía Scrum.

En la práctica, preferiría algún tipo de documentación liviana en lugar de asignarla a cada tarea o elemento de la cartera de productos en una herramienta de seguimiento de tickets. A menos que pueda automatizar mucho el proceso, parece que poner su definición de hecho en una herramienta de seguimiento de tareas o tickets agregaría muchos gastos generales y terminaría dificultando el trabajo de seguimiento. Una página wiki, o algo similar, puede bajar la información para que todo el equipo pueda consultarla, y se puede cambiar con el tiempo a medida que el equipo mejora su Definición de Listo con el tiempo.

Algo que agregaría para respaldar las otras respuestas aquí es que puede darse el caso de que la Definición de "Terminado" (DoD) no sea totalmente 'propiedad' del Equipo Scrum:

Cuando un elemento del Product Backlog o un Incremento se describe como "Terminado", todos deben entender lo que significa "Terminado"... Si la definición de "Terminado" para un incremento es parte de las convenciones, estándares o directrices de la organización de desarrollo, todos los Equipos Scrum deben seguirlo como mínimo... Si hay varios Equipos Scrum trabajando en el sistema o lanzamiento del producto, los Equipos de desarrollo en todos los Equipos Scrum deben definir mutuamente la definición de "Terminado". - La Guía oficial de Scrum

Sugeriría que "todos" los que estén interesados ​​en la calidad abarquen no solo a la organización de desarrollo, sino también a las partes interesadas. Por lo tanto, probablemente sea necesario hacer que el Departamento de Defensa sea accesible para todas las partes.

En una nota práctica, he encontrado un DoD en forma de lista de verificación muy útil. De esta manera, los elementos del Departamento de Defensa se pueden marcar cuando un miembro del Equipo Scrum verifica que un elemento del Sprint Backlog está "Terminado". Por lo tanto, tenga el DoD en un formato en el que pueda mostrarse fácilmente en una pantalla o imprimirse en una hoja de papel.

Primero, estoy de acuerdo con lo que otros dicen sobre el equipo que establece la definición de hecho. Necesita obtener esa aceptación y comprensión compartida si va a tener éxito en la implementación del DOD.

Hay dos formas en las que abordamos la definición de hecho. Una es desde la perspectiva del flujo de trabajo (a la Jira). Inicialmente comenzamos cuando el código completo estaba Listo, pero a medida que nuestras capacidades de implementación de CI mejoraron, lo trasladamos a En producción. Esto funciona para el 90 % de nuestro trabajo, que se basa en la codificación de un producto existente donde estamos modificando algo que ya está funcionando en producción.

Para SPIKES o Historias que están progresando a MVP, pero que no están listas para la producción, dedicamos más tiempo a documentar las Condiciones de aceptación (COA), ya que estas tareas no van a cumplir con la definición de flujo de trabajo de Hecho en producción.

Los ejemplos serían: Documentar los resultados de la investigación en la página Wiki. Diagramar la arquitectura del estado futuro y la aprobación del documento por parte de la CTO.

Si son entregables observables y concretos, entonces debería haber muy poca ambigüedad sobre si la tarea cumple o no con los criterios.

Hacerlo y lograr que se haga no son tareas (o subtareas) separadas.

Un backlog puede consistir en nada más que definición de hechos. A menudo es más vaga, y esta definición se crea en el sprint, luego se hace. Sin embargo, estas dos actividades no deberían aparecer como dos tareas.

Es posible que no esté de acuerdo con lo que se ve hecho. Puedo abogar por Test-Driven-Development, el resto del equipo puede abogar por algo menos riguroso. Gritar fuerte no funcionará. Por lo tanto, aceptaré la definición de los equipos, pero lo haré si se revisan las características. Si estamos revisando funciones con demasiada frecuencia, le mostraré al equipo que nuestra definición de hecho no funciona. (Puede haber otras razones para reevaluar la definición de hecho. Por ejemplo, el aumento de la deuda técnica y el miedo a la refactorización.

Agregar uno de los representantes de los clientes para conocer el progreso y validar la tarea realizada puede aumentar la transparencia y refinar la definición de Tarea finalizada.