La Définition du Fini
Auteur : Derek Huether
Source : Definition of Done
Date : 08/02/2017
Traducteur : Fabrice Aimetti
Date : 10/08/2026
Traduction :
Est-ce fini, est-ce vraiment fini, ou est-ce carrément fini ?
Si vous travaillez dans le domaine du développement d’applications, vous vous êtes déjà posé cette question. Alors, quelle est la définition de "fini" ? Lorsque vous posez cette question, il est important de tenir compte de votre rôle et de votre niveau hiérarchique au sein de l’organisation. Les équipes de développement, les équipes programme et les équipes portefeuille définissent le terme "fini" différemment. Ce dont nous sommes certains, c’est qu’il nous faut une définition claire de "fini" à chaque niveau de l’organisation.
Nous devons respecter la définition de "fini" pour garantir la qualité.
Définition de "fini"
La définition de "fini" (Definition of Done ~ DoD) correspond au moment où toutes les conditions, ou critères d’acceptation, auxquelles un produit logiciel doit satisfaire sont remplies et où celui-ci est prêt à être accepté par un utilisateur, un client, une équipe ou un système consommateur. Nous devons respecter la définition de "fini" pour garantir la qualité. Elle réduit les retouches en empêchant les user stories qui ne répondent pas à cette définition d’être transférées vers des environnements de niveau supérieur. Elle empêche ainsi que des fonctionnalités non conformes à cette définition ne soient livrées au client ou à l’utilisateur.
User Stories
L'utilisation la plus courante de la DoD se situe au niveau de l'équipe de développement. À ce niveau, "Fini" signifie que le Product Owner a revu et accepté la user story. Une fois acceptée, la user story « finie » contribue à la vélocité de l'équipe. Vous devez respecter tous les critères définis, sinon la user story n'est pas considérée comme finie.
Exemples de DoD pour les user stories :
- Tests unitaires réussis
- Code revu
- Critères d’acceptation respectés
- Tests fonctionnels réussis
- Exigences non fonctionnelles respectées
- Le Product Owner accepte la User Story
Fonctionnalités (features)
Le fait qu’une fonctionnalité soit "finie" à ce niveau peut signifier qu’elle remplit les conditions pour être intégrée à une version. Toutes les user stories ne doivent pas nécessairement être achevées. Cela signifie plutôt que la fonctionnalité est susceptible de répondre au besoin. Une fois acceptée, la fonctionnalité "finie" contribuera à la vélocité de la version. Encore une fois, vous devez respecter tous les critères définis, sinon la fonctionnalité n’est pas considérée comme finie.
Exemples de "Fini" pour une fonctionnalité :
- Critères d’acceptation respectés
- Intégrée dans un build "clean"
- Déployée dans un environnement de niveau supérieur
- Tests de régression automatisés réussis
- Tests fonctionnels au niveau de la fonctionnalité réussis
- Exigences non fonctionnelles respectées
- Conforme aux exigences de conformité
- Fonctionnalité documentée dans la documentation utilisateur nécessaire
Epics
Une epic "finie" à ce niveau peut correspondre à une priorité stratégique de l’organisation, à un élément du plan de portefeuille ou à tout autre ensemble de fonctionnalités répondant à un besoin du marché. Il n’est pas nécessaire que toutes les user stories ou fonctionnalités soient menées à bien. L'epic peut en effet suffire à elle seule à satisfaire le besoin. Une fois acceptée, l'epic finie sera prise en compte dans les calculs de débit afin de vérifier si l’offre est en équilibre avec la demande.
Exemples de critères de "fini" pour une epic :
- Exigences non fonctionnelles satisfaites
- Intégration bout en bout terminée
- Tests de régression réussis
- Déploiement vers l’environnement de production
- Répond aux attentes définies du marché