Una definición de "Listo" en el caso de que varios equipos de desarrollo trabajen en un mismo producto

Una de las pruebas de scrum contiene la pregunta sobre la definición que mejor describe "Hecho" cuando varios equipos de desarrollo realizan un trabajo en un mismo producto.

Una respuesta adecuada indica que esos equipos de desarrollo deben tener una definición de "Listo" que pueda hacer que su trabajo combinado sea potencialmente liberable.

Lo que no está claro para mí de la respuesta adecuada a este cuestionario es:

¿Pueden los equipos tener diferentes definiciones de "Listo"? ¿En qué medida?

agile scrum
fuente

Piense en un equipo que lanza directamente un producto, así como el mismo trabajo utilizado por otros equipos.

Ian

O, por ejemplo, las versiones en inglés del software pueden enviarse antes de ser traducidas al francés.

Ian

Este tipo de confusión es la razón por la que nunca digo que se haga nada. En cambio, siempre digo exactamente lo que hicimos. Decidir si se hace algo es una negociación. No es una declaración. Independientemente de qué definición sigas.

candied_orange

Respuestas:

Cuando todos los equipos definen "Listo" de una manera que tiene en cuenta el trabajo realizado por otros equipos, entonces se asegura de que la funcionalidad esté completa.

Si cada equipo define "hecho" de manera diferente y solo espera que los otros equipos conozcan esa definición, se encontrará con varios problemas:

Cuando surge un problema de integración, ningún equipo querrá hacerse cargo de solucionarlo. Después de todo, se "hizo" cuando comenzaron a integrar las cosas, por lo que debe ser algo con el trabajo del otro equipo.
Cuando tienes más de un puñado de equipos, se hace difícil recordar la "definición de hecho" de todos, especialmente cuando hay diferencias entre los equipos.
No se garantiza que la definición de hecho incluya que el trabajo de integración funciona correctamente.

La respuesta aceptada establece claramente que las cosas no se hacen hasta que el trabajo de todos los equipos se integre y funcione correctamente. Debe ser liberable y, por lo tanto, capaz de ser aceptado por los usuarios finales en su totalidad.

Editar en respuesta a los comentarios: Esto no significa que todos los equipos tengan la misma definición de hecho. Significa que parte de la definición de hecho de cada equipo es el sistema más grande y otros componentes integradores no están rotos.

Greg Burghardt
fuente

Perdón, pero me parece que la respuesta correcta no dice nada acerca de tener la definición única de "Hecho". Además, no estoy seguro de que las peculiaridades de integración se deban incluir en él. ¿Diga si dos equipos trabajan en implementaciones completamente diferentes de la misma API dedicada para diferentes clientes? Sin embargo, formalmente todavía están trabajando en el mismo producto.

@Andremoniy, la respuesta correcta de hecho no dice nada sobre un solo DoD, pero sí significa que los DoD de todos los equipos deben tener un elemento común de que el producto en general sigue siendo funcional. Su ejemplo de diferentes equipos trabajando en diferentes implementaciones de una API no me convence de que eso podría llamarse un solo producto.

Bart van Ingen Schenau

@Andremoniy, tan pronto como un equipo depende del trabajo de otro equipo, los problemas de integración pueden (ocurrirán), incluso si las partes se implementan en diferentes ubicaciones. También es un problema de integración, por ejemplo, cuando un microservicio usa otro microservicio de una manera inesperada, posiblemente incorrecta.

Bart van Ingen Schenau

@Andremoniy: Tiene razón en que esos dos equipos no deberían usar el mismo DoD, pero pueden compartir la regla de que cualquier cambio no debe afectar negativamente al otro equipo (lo que se desencadenaría principalmente si el trabajo involucra cambios en la interfaz con la parte posterior -end servidor).

Bart van Ingen Schenau

@Andremoniy: Gracias por tus comentarios. He actualizado mi respuesta para abordar algunos de los problemas que mencionó.

Greg Burghardt

Me imagino una situación en la que un equipo define "Listo" como "Desarrollo realizado" (es decir, código fusionado para repositorio) mientras que otro lo define como "Pruebas realizadas" (es decir, código liberado a Q / A y probado).

Esto llevaría inherentemente a problemas serios porque el estado general del producto estaría en gran medida indefinido y, por lo tanto, sería difícil saber si realmente podemos liberarlo o no.

Pawel Gorczynski
fuente

¿Considera que la respuesta adecuada indica que todos los equipos deberían compartir la misma definición?

Sí, estoy de acuerdo en que debería haber una definición común por una razón simple: un proyecto complejo puede considerarse una estructura de árbol donde los subproyectos (por ejemplo, microservicios) construyen el producto en general (por ejemplo, MyCool ERP). Entonces, en un momento dado, desea saber si se puede lanzar una nueva versión del producto. Pero si tiene un DoD diferente para subcomponentes particulares, entonces esta información se vuelve extremadamente difícil de deducir.

Pawel Gorczynski