Définition de fait pour de nombreuses équipes de Scrum
Nous avons récemment commencé à utiliser le cadre Scrum et nous sommes progressivement passés de 1 équipe à 5. Je fais le rôle de Master Scrum. Au cours des derniers mois, chaque équipe de développement a travaillé sur leur définition de FAIT (DOD) avec le propriétaire du produit. Chaque équipe a négocié son propre DOD. Il y a quelques différences entre chaque DODS.
Aujourd'hui, il y a 1 propriétaire de produit et 5 maîtres de Scrum et nous souhaitons utiliser un DOD unique pour toutes les équipes. Que proposez-vous que nous devrions faire pour harmoniser les DODS?
Propositions qui sont sorties de nos discussions:
- Chaque maîtres de Scrum travaille avec le propriétaire du produit pour créer un nouveau DOD qu'ils présenteront à leur équipe.
- Chaque équipe élit un représentant (développeur) qui collabore avec le propriétaire du produit pour créer un nouveau DOD qu'ils présenteront à leur équipe.
Dans les deux cas, ce serait un processus itératif afin que chaque équipe puisse fournir des commentaires et ajuster.
Merci d'avance!
Partager un noyau commun
Je pense que c'est raisonnable d'avoir un ensemble commun d'éléments principaux sur votre définition de votre définition, mais il doit être flexible. Ces articles communs devraient être clairement évidents et nécessaires à chaque équipe, au point où il n'ya tout simplement aucun argument selon lequel ils devraient être inclus.
Par exemple, chaque équipe devrait probablement avoir "des tests d'unités qui passent" comme un élément. Un autre bon candidat est "doit être vérifié à la version de la version" et "doit réussir tous les critères d'acceptation".
Autonomisation de l'équipe
Chaque équipe devrait être libre de modifier la leur Définition de faite sans avoir nécessité l'approbation d'un comité. Scrum est à propos de équipe autonomisation. En forçant une équipe à avoir une "définition du fait" conçu par une autre personne ou une autre équipe n'est pas l'autonomisation.
Par exemple, certaines équipes voudront peut-être avoir besoin d'un examen par des pairs, mais cela n'est peut-être pas approprié pour toutes les équipes. Certaines équipes pourraient nécessiter un rachat d'un expert en matière de convivialité, mais cela n'a généralement aucune pertinence pour une équipe travaillant sur un backend. Une équipe peut avoir des exigences de couverture de code plus strictes que d'autres, etc.
Scrum est tout à propos de l'équipe
Dans Scrum, Focus est sur le Team. Si cela signifie qu'il nécessite un peu plus de travail du propriétaire du produit ou du maître Scrum, alors soyez-le. Le rôle du maître Scrum est de Supprimer barrages routiers, pas les ajouter.
Chaque équipe a négocié leur propre DoD. Il y a quelques différences entre chaque DODS.
La cohérence a sa place, mais jusqu'à ce que vous identifiez les problèmes, il est difficile de trouver une solution.
L'avantage de Scrum/Agile est de laisser les équipes se gérer elles-mêmes. Si une équipe ne peut pas arriver à un consensus sur une question, il est bon de disposer de règles de gestion pouvant aider à réduire l'accent. En outre, comme les membres vont d'une équipe à une autre, il est agréable de savoir à quoi s'attendre dans l'espoir de s'adapter à tout de suite. Y a-t-il un problème ici, vous essayez de réparer ou d'éviter?
Donc, pour répondre à votre question, je pense que vous êtes sur la bonne voie pour tenter d'obtenir la contribution de chacun, mais vous devriez être prêt à découvrir qu'il existe un tel accord, que vous devriez oublier un seul DOD et laisser chaque équipe ajuster et évoluer leur propre signification au cours de ce projet car ils sont en forme.
Vous entrez dans le territoire de gestion hiérarchique de haut niveau, même si vous impliquez tout le monde. Soyez très prudent dans l'application d'une règle rigide à toutes les personnes dans toutes les situations. Il sera très difficile d'obtenir 5 équipes individuelles pour réviser en permanence le DOD chaque fois qu'il y a une exception.