Définition de « Fini » : Qu’est-ce que c’est et comment l’utiliser

Voici les principales caractéristiques d’une définition du « fait » efficace :

• Transparente : Chaque membre de l’équipe et les parties prenantes clés peuvent la voir, la lire et s’y référer à tout moment.
• Mesurable : Chaque critère est binaire. Le travail le respecte ou non, mais les seuils choisis pour des critères quantitatifs méritent réflexion. Un objectif de couverture de code de 80 % est binaire dans son application, mais le choix de 80 % plutôt que 70 % ou 90 % doit être fait de manière délibérée.
• Universellement comprise : Chaque membre de l’équipe Scrum doit pouvoir interpréter chaque point de la même façon.
• Constamment appliquée : La même liste de critères doit être utilisée pour chaque livrable et chaque élément du backlog produit. 
• Atteignable en un sprint : Les critères doivent être suffisamment réalistes pour pouvoir être respectés par l’équipe lors d’un seul sprint ou itération.

Dans les projets de développement logiciel, la définition du « fait » appartient généralement aux développeurs car ce sont eux qui doivent s’y conformer. Cela dit, le Product Owner et le Scrum Master devraient également contribuer.

Si votre organisation dispose de ses propres standards pour la définition du « fait », chaque équipe Scrum doit au minimum les respecter. Les équipes peuvent toujours ajouter des critères plus stricts par-dessus, mais ne peuvent pas descendre en-dessous du niveau d’exigence organisationnel.

Pourquoi la définition du « fait » est importante

Une définition du « fait » claire est essentielle car elle empêche que des travaux partiellement terminés ne passent entre les mailles du filet et offre une norme partagée de qualité.

Voici d’autres raisons pour lesquelles une définition du « fait » partagée est capitale :

• Agit comme une barrière qualité intégrée : Chaque élément doit franchir le même seuil avant d’être considéré comme terminé. Cela évite que des tâches inabouties s’intègrent à l’incrément produit et s’accumulent sous forme de dette technique.
• Élimine l’ambiguïté : Lorsque l’équipe partage une même définition, on évite les situations où des visions contradictoires impactent la rapidité ou la qualité du travail. Une définition du « fait » partagée, c’est moins de conflits, moins de surprises et des démonstrations plus claires.
• Améliore la prévision : Quand la définition du « fait » reste la même à chaque sprint, il est possible de prévoir la vélocité avec confiance et de planifier les livraisons sans ajouter de marges pour du travail à refaire.
• Renforce la confiance des parties prenantes : Lorsque les Product Owners, la direction ou les parties prenantes externes constatent que votre équipe fait respecter une norme de qualité clairement définie, ils ont confiance dans vos livrables. 
• Prévient le chaos lors de l’intégration : Si votre mode de travail exige que l’équipe intègre ses réalisations à un incrément partagé, une compréhension commune de la définition du « fait » est la base pour produire des incréments cohérents et livrables. 

Dirigez plus intelligemment à l'ère de l'IA

Rejoignez la communauté DPM pour accéder à du contenu exclusif, des modèles pratiques, des événements réservés aux membres et des conseils hebdomadaires en leadership – l'inscription est gratuite.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Email

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Comment créer une définition du « fait »

Voici les principales étapes pour définir la définition du « fait ».

1. Auditez votre flux de travail actuel : Cartographiez chaque étape que votre travail suit déjà avant d’atteindre la production. Parlez aux développeurs, testeurs, concepteurs et à toute autre personne qui intervient sur le travail. Vous découvrirez des étapes de qualité informelles à formaliser.
2. Identifiez les critères de qualité non négociables : Décidez des activités qui doivent absolument être réalisées pour chaque livrable. Celles-ci incluent généralement la relecture de code, les tests automatisés, la mise à jour de la documentation et les analyses de sécurité. Soyez honnête sur ce que vous sautez actuellement.
3. Élaborez la checklist de façon collaborative : Rassemblez toute l’équipe et discutez-la à l’aide d’un tableau blanc ou d’un document partagé où chacun peut ajouter, remettre en question, et affiner les éléments en temps réel. Une définition de fini créée par consensus tient beaucoup mieux sous pression qu’une qui a été votée malgré des objections.
4. Validez par rapport aux standards de l’organisation : Recoupez votre brouillon avec les politiques qualité de l’entreprise, les exigences réglementaires ou les normes du secteur que doit respecter votre produit. Si votre organisation possède déjà une définition de fini de base, partez de là et améliorez-la.
5. Rendez-la visible : Affichez la définition là où l’équipe travaille chaque jour. Cela peut signifier un poster au mur, un message épinglé sur Slack ou un panneau dans votre outil de gestion de projet.
6. Engagez-vous à la faire respecter : Une définition de fini qui est ignorée quand les délais sont serrés est pire que l’absence de normes, car elle crée un faux sentiment de qualité. 

Exemples de Définition de Fini

Voici quelques exemples de définitions de fini pour différents types de projet :

Définition de Fini pour les Projets de Développement Logiciel

Les projets logiciels font face à une grande variété de risques qualité : bugs, failles de sécurité, régressions de performance et échecs d’intégration. La définition de fini pour une équipe logicielle doit couvrir tout le processus du code jusqu’à l’état publiable.

Cela peut ressembler à :

• Tous les codes écrits et relus par au moins un autre développeur
• Tests unitaires validés avec le seuil de couverture convenu
• Tests d’intégration au vert dans le pipeline CI/CD
• Aucun bug ouvert de sévérité critique ou élevée
• Documentation technique mise à jour pour refléter les changements
• Code fusionné dans la branche principale
• Le product owner a révisé et accepté le travail
• Les seuils de performance convenus sont respectés

Définition de Fini pour les Projets Marketing 

Le travail marketing comporte souvent des dimensions de conformité, de marque et de mesure qui diffèrent du logiciel. 

Voici à quoi pourrait ressembler la définition de fini pour un projet marketing :

• Contenu relu et approuvé par l’équipe juridique
• Checklist SEO complétée, incluant les méta-descriptions, textes alternatifs et liens internes
• Tous les assets téléchargés dans le CMS et correctement formatés
• Suivi analytique configuré et vérifié dans l’environnement de préproduction
• Dernière relecture effectuée par un second membre de l’équipe
• Checklist de lancement de campagne validée par le chef d’équipe

Définition de Fini pour les Projets de Design 

Les équipes de design ont besoin d’une définition de fini qui fasse le lien entre l’intention créative et la transmission technique. Sans cela, les designs arrivent en développement incomplets, avec des spécifications manquantes, des comportements responsives non validés, ou des lacunes d’accessibilité découvertes trop tard.

Voici un exemple de définition de fini pour un projet de design :

• Design vérifié selon les standards d’accessibilité WCAG 2.2
• Fichier de transmission préparé dans l’outil convenu avec tous les specs, assets et annotations
• Validation des parties prenantes reçue et documentée
• Composants du design system mis à jour si de nouveaux patterns ont été introduits
• Comportement responsive validé sur tous les points de rupture convenus

Définition de Fini vs Critères d’Acceptation

La définition de fini représente la norme de qualité au niveau de l’équipe, tandis que les critères d’acceptation sont des exigences fonctionnelles au niveau de la fonctionnalité.

Considérez la définition de terminé comme la base qui s'applique universellement, et les critères d’acceptation comme propres à chaque sprint backlog ou élément du backlog produit. Un élément du backlog produit est terminé lorsqu’il satisfait à la fois à ses critères d’acceptation et à la définition de terminé de l’équipe.

Pièges et erreurs courants

Voici quelques erreurs fréquentes à éviter lors de la définition de vos définitions de terminé :

• Sauter des étapes pour aller plus vite : Sous la pression des délais, les équipes omettent souvent des critères comme la revue de sécurité, les tests d’accessibilité ou la documentation. Cela crée une dette technique cachée qui réapparaît plus tard sous forme de bugs, de reprises ou de problèmes de conformité.
• Rendre la liste trop détaillée : Une définition de terminé trop minutieuse devient une corvée bureaucratique. Si votre checklist comporte 30 éléments et que les développeurs passent plus de temps à cocher des cases qu’à produire du logiciel, c’est trop. Soyez suffisamment précis pour être pertinent, mais assez général pour rester pratique.
• Modifier la définition de terminé pour chaque story : Le but même de la définition de terminé est la cohérence. Les conditions propres à une fonctionnalité doivent figurer dans les critères d’acceptation (comme les critères d’acceptation donnés-quand-alors), pas dans la définition de terminé.
• Ne jamais la réexaminer : Une définition de terminé doit évoluer au fil de la maturité de vos pratiques, des changements d’outils ou de l’évolution du produit. Je recommande de la revoir en rétrospective au moins une fois par trimestre, et de l’ajuster quand l’équipe identifie des lacunes ou des points de friction.
• Ne pas la faire respecter : Une définition qui est écartée dès qu’une personne influente la demande ne sert à rien. Le rôle du Scrum master est de protéger la définition, même lorsqu’un acteur souhaite livrer quelque chose qui ne répond pas aux exigences. Si les critères sont régulièrement contournés, l’équipe perd confiance dans la norme et cesse de la prendre au sérieux.
• Confondre "terminé" avec "déployé" : La définition de terminé détermine si un incrément est publiable, pas s’il a été mis en production. Un élément du backlog produit peut être terminé sans être déployé. N’ajoutez « déployé en production » à votre définition de terminé que si votre équipe contrôle réellement tout le processus de mise en production de bout en bout.
• Négliger d’y faire référence : De nombreuses équipes possèdent une définition de terminé sur le papier, mais si elle n’a pas été consultée depuis sa création il y a six mois, elle ne sert pas vraiment de référentiel qualité.

Et maintenant ?

Développez vos processus agiles et vos méthodes de travail grâce à des outils pratiques, des modèles et des conseils d’experts avec une adhésion gratuite à DPM, et renforcez les systèmes qui permettent à vos équipes de livrer un travail de qualité de manière cohérente.