La Définition du Fini - Historique des versions

Fabrice Aimetti le 10 août 2026 à 12:05

Fabrice Aimetti — Mon, 10 Aug 2026 12:05:19 GMT

← Version précédente		Version du 10 août 2026 à 12:05
Ligne 18 :		Ligne 18 :
	== Définition de "fini" ==		== 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.		La définition de "fini" (Definition of Done ~ DoD) correspond au moment où toutes les conditions, ou [https://www.liminalarc.co/2014/09/acceptance-criteria/ 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 ==		== User Stories ==
Ligne 59 :		Ligne 59 :
	== Résumé ==		== Résumé ==

	Tout comme la définition de "prêt", celle de "fini" revêt une importance capitale. Ne commencez jamais à travailler sur un sujet avant de vous être mis d’accord sur cette définition. Soyez cohérents. Soyez clairs. Assurez-vous d’avoir une compréhension partagée.		Tout comme la définition de [https://www.liminalarc.co/2015/07/definition-of-ready/ "prêt"], celle de "fini" revêt une importance capitale. Ne commencez jamais à travailler sur un sujet avant de vous être mis d’accord sur cette définition. Soyez cohérents. Soyez clairs. Assurez-vous d’avoir une compréhension partagée.

Fabrice Aimetti le 10 août 2026 à 12:03

Fabrice Aimetti — Mon, 10 Aug 2026 12:03:23 GMT

← Version précédente		Version du 10 août 2026 à 12:03
Ligne 21 :		Ligne 21 :

	== User Stories ==		== 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.<br/>		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.<br/>
	<br/>		<br/>
Ligne 32 :		Ligne 33 :

	== Fonctionnalités (features) ==		== 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.<br/>		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.<br/>
	<br/>		<br/>
Ligne 45 :		Ligne 47 :

	== Epics ==		== 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.<br/>		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.<br/>
	<br/>		<br/>
Ligne 53 :		Ligne 56 :
	* Déploiement vers l’environnement de production		* Déploiement vers l’environnement de production
	* Répond aux attentes définies du marché		* Répond aux attentes définies du marché

			== Résumé ==

			Tout comme la définition de "prêt", celle de "fini" revêt une importance capitale. Ne commencez jamais à travailler sur un sujet avant de vous être mis d’accord sur cette définition. Soyez cohérents. Soyez clairs. Assurez-vous d’avoir une compréhension partagée.

Fabrice Aimetti le 10 août 2026 à 12:01

Fabrice Aimetti — Mon, 10 Aug 2026 12:01:57 GMT

← Version précédente		Version du 10 août 2026 à 12:01
Ligne 31 :		Ligne 31 :
	* Le Product Owner accepte la User Story		* Le Product Owner accepte la User Story

	== Fonctionnalités ==		== 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.<br/>		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.<br/>
	<br/>		<br/>
Ligne 43 :		Ligne 43 :
	* Conforme aux exigences de conformité		* Conforme aux exigences de conformité
	* Fonctionnalité documentée dans la documentation utilisateur nécessaire		* 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.<br/>
			<br/>
			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é

Fabrice Aimetti le 10 août 2026 à 11:59

Fabrice Aimetti — Mon, 10 Aug 2026 11:59:30 GMT

← Version précédente		Version du 10 août 2026 à 11:59
Ligne 30 :		Ligne 30 :
	* Exigences non fonctionnelles respectées		* Exigences non fonctionnelles respectées
	* Le Product Owner accepte la User Story		* Le Product Owner accepte la User Story

			== Fonctionnalités ==
			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.<br/>
			<br/>
			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

Fabrice Aimetti le 10 août 2026 à 11:56

Fabrice Aimetti — Mon, 10 Aug 2026 11:56:23 GMT

← Version précédente		Version du 10 août 2026 à 11:56
Ligne 19 :		Ligne 19 :

	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.		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.<br/>
			<br/>
			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

Fabrice Aimetti : Page créée avec « Category: Portail ScrumMaster Catégorie:DoD Auteur : Derek Huether
Source : [https://www.liminalarc.co/2017/02/definition-of-done/ 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. Al... »

Fabrice Aimetti — Mon, 10 Aug 2026 11:53:31 GMT

Page créée avec « Category: Portail ScrumMaster Catégorie:DoD Auteur : Derek Huether Source : [https://www.liminalarc.co/2017/02/definition-of-done/ 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. Al... »

Nouvelle page

[[Category: Portail ScrumMaster]]
[[Catégorie:DoD]]
Auteur : Derek Huether 
Source : [https://www.liminalarc.co/2017/02/definition-of-done/ 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.