Une définition de «Terminé» dans le cas où plusieurs équipes de développement travaillent sur un même produit

12

L'un des tests Scrum contient la question de la définition décrivant le mieux "Terminé" lorsque plusieurs équipes de développement effectuent un travail sur un même produit.

Une bonne réponse indique que ces équipes de développement doivent avoir une telle définition de "Terminé" qui peut rendre leur travail combiné potentiellement libérable.

Ce qui ne ressort pas clairement de la bonne réponse à ce quiz, c'est:

  • les équipes peuvent-elles avoir différentes définitions de "Terminé"? Dans quelle mesure?
agile scrum
la source
Pensez à une équipe qui publie directement un produit ainsi qu'au même travail utilisé par d'autres équipes.
Ian
Ou par exemple les versions anglaises du logiciel peuvent être livrées avant d'être traduites en français.
Ian
Ce genre de confusion est la raison pour laquelle je ne dis jamais que quelque chose est fait. Au lieu de cela, je dis toujours exactement ce que nous avons fait. Décider si quelque chose est fait est une négociation. Pas une déclaration. Quelle que soit la définition que vous suivez.
candied_orange

Réponses:

16

Lorsque toutes les équipes définissent «Terminé» d'une manière qui prend en compte le travail effectué par d'autres équipes, vous vous assurez que la fonctionnalité est complète.

Si chaque équipe définit «fait» différemment et s'attend simplement à ce que les autres équipes connaissent cette définition, vous rencontrerez plusieurs problèmes:

  • Lorsqu'un problème d'intégration survient, aucune équipe ne voudra se charger de le résoudre. Après tout, cela a été "fait" quand ils ont commencé à intégrer les choses, donc ça doit être quelque chose avec le travail de l'autre équipe.

  • Lorsque vous avez plus d'une poignée d'équipes, il devient difficile de se souvenir de la «définition du fait» de tout le monde - surtout lorsqu'il y a des différences entre les équipes.

  • La définition de fait n'est pas garantie d'inclure que le travail d'intégration fonctionne correctement.

La réponse acceptée indique clairement que les choses ne se font que lorsque le travail de toutes les équipes est intégré et fonctionne correctement. Il doit être libérable et donc pouvoir être accepté par les utilisateurs finaux dans son intégralité.

Modifier en réponse aux commentaires: cela ne signifie pas que chaque équipe a la même définition de fait. Cela signifie qu'une partie de la définition de fait de chaque équipe est le système plus grand et les autres composants d'intégration ne sont pas cassés.

Greg Burghardt
la source
Je vous demande pardon, mais il me semble que la bonne réponse ne dit rien sur la définition unique de "Terminé". De plus, je ne suis pas sûr que des particularités d'intégration doivent y être incluses. Dire si deux équipes travaillent toutes deux sur des implémentations complètement différentes de la même API dédiée à différents clients? Cependant, formellement, ils travaillent toujours sur le même produit.
2
@Andremoniy, la bonne réponse ne dit en effet rien sur un seul DoD, mais cela signifie que les DoD de toutes les équipes doivent avoir un élément commun que le produit global reste fonctionnel. Votre exemple de différentes équipes travaillant sur différentes implémentations d'une API ne me convainc pas que cela pourrait être appelé un seul produit.
Bart van Ingen Schenau
2
@Andremoniy, dès qu'une équipe dépend du travail d'une autre équipe, des problèmes d'intégration peuvent (vont) se produire, même si les pièces sont déployées à différents endroits. C'est également un problème d'intégration, par exemple, lorsqu'un micro-service utilise un autre micro-service d'une manière inattendue, peut-être incorrecte.
Bart van Ingen Schenau
2
@Andremoniy: Vous avez raison de dire que ces deux équipes ne devraient pas utiliser le même DoD, mais elles peuvent partager la règle selon laquelle les modifications ne doivent pas affecter négativement l'autre équipe (ce qui se déclencherait principalement si le travail implique des modifications de l'interface avec l'arrière) -serveur final).
Bart van Ingen Schenau
1
@Andremoniy: Merci pour vos commentaires. J'ai mis à jour ma réponse pour répondre à certaines des questions que vous avez soulevées.
Greg Burghardt
6

Je pourrais imaginer une situation, où une équipe définit "Terminé" comme "Développement Terminé" (c'est-à-dire le code fusionné pour le repo) tandis que l'autre le définit comme "Test Terminé" (c'est-à-dire le code publié en Q / A et testé).

Cela conduirait intrinsèquement à de graves problèmes car l'état global du produit serait largement indéfini et il serait donc difficile de dire si nous pouvons réellement le publier ou non.

Pawel Gorczynski
la source
Considérez-vous que la bonne réponse consiste à dire que toutes les équipes devraient partager la même définition?
Oui, je suis d'accord qu'il devrait y avoir une définition commune pour une raison simple - Un projet complexe peut être considéré comme une structure arborescente où des sous-projets (par exemple des microservices) construisent le produit global (par exemple MyCool ERP). Donc, à un moment donné, vous voulez savoir si une nouvelle version du produit peut être publiée. Mais si vous avez un DoD différent pour des sous-composants particuliers, ces informations deviennent extrêmement difficiles à déduire.
Pawel Gorczynski