Wiki Agile - Modifications récentes [fr]

Le modèle INVEST - S comme stories Suffisamment petites, extenSibles

Fabrice Aimetti — Fri, 21 Aug 2026 11:36:44 GMT

← Version précédente		Version du 21 août 2026 à 11:36
Ligne 14 :		Ligne 14 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
			Le S du modèle INVEST est pour “Suffisamment petites”. J’utilise désormais ce S pour quelque chose d’autre qui je pense capture cette idée encore mieux : extenSible.<br/>
			<br/>
	http://www.les-traducteurs-agiles.org/2017/10/16/le-modele-invest-pour-des-stories-suffisamment-petites-extensibles.html		http://www.les-traducteurs-agiles.org/2017/10/16/le-modele-invest-pour-des-stories-suffisamment-petites-extensibles.html

Le modèle INVEST - I comme stories Indépendantes

Fabrice Aimetti — Fri, 21 Aug 2026 11:30:49 GMT

← Version précédente		Version du 21 août 2026 à 11:30
Ligne 14 :		Ligne 14 :
	Traduction :<br />		Traduction :<br />
	<br />		<br />
			Le modèle INVEST est un moyen mnémotechnique permettant de se rappeler des principales caractéristiques des user stories et il commence par un I comme Indépendant.<br/>
			<br/>
	http://www.les-traducteurs-agiles.org/2017/02/21/le-modele-invest-les-stories-independantes.html		http://www.les-traducteurs-agiles.org/2017/02/21/le-modele-invest-les-stories-independantes.html

LeSS - Transparence

Fabrice Aimetti — Wed, 12 Aug 2026 12:58:09 GMT

← Version précédente		Version du 12 août 2026 à 12:58
(2 versions intermédiaires par le même utilisateur non affichées)
Ligne 12 :		Ligne 12 :
	* la croyance en la magie et		* la croyance en la magie et
	* l'ère de tout rendre opaque.		* l'ère de tout rendre opaque.
	<br /> La transparence est fortement liée à la [~~http://less.works/less/framework/definition~~-~~of-done.html~~ Définition du Fini]. Définir formellement la signification du "fini" réduit la variabilité et la probabilité du travail non fini, la mesure non ambigüe ("fini" ou "pas fini") de l'état d'avancement augmente la transparence.<br /> <br /> Avoir une Définition du Fini imparfaite génère du [~~http://less.works/less/framework/definition~~-~~of-done.html~~ Travail non fini] dans votre système. Ce travail non fini génère également un manque de transparence. Il comporte des risques. Par exemple, des tests de performance non finis reportent le risque de constater que le système n'est pas performant au moment de livrer la version, là où ça fait le plus mal.<br /> <br />		<br /> La transparence est fortement liée à la [[LeSS_-_La_Définition_du_Fini\|Définition du Fini (fr)]]. Définir formellement la signification du "fini" réduit la variabilité et la probabilité du travail non fini, la mesure non ambigüe ("fini" ou "pas fini") de l'état d'avancement augmente la transparence.<br /> <br /> Avoir une Définition du Fini imparfaite génère du [[LeSS_-_La_Définition_du_Fini\|Travail non fini (fr)]] dans votre système. Ce travail non fini génère également un manque de transparence. Il comporte des risques. Par exemple, des tests de performance non finis reportent le risque de constater que le système n'est pas performant au moment de livrer la version, là où ça fait le plus mal.<br /> <br />

La Définition du Fini

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

← Version précédente		Version du 10 août 2026 à 12:05
(4 versions intermédiaires par le même utilisateur non affichées)
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 ==

			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

			== 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/>
			<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

			== 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é

			== Résumé ==

			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.

La Définition du Fini

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.

Un conseil pour une équipe avec un nouveau chef qui ne connaît pas le Lean et qui souhaite plutôt nous faire passer à l'Agilité ?

Fabrice Aimetti — Fri, 31 Jul 2026 09:21:56 GMT

← Version précédente		Version du 31 juillet 2026 à 09:21
Ligne 4 :		Ligne 4 :
	[[Catégorie: Michael Ballé]]		[[Catégorie: Michael Ballé]]
	Auteur : Michael Ballé<br/>		Auteur : Michael Ballé<br/>
	Source : [https://www.lean.org/balle/DisplayObject.cfm?o=4983 ~~ANY ADVICE FOR A TEAM WITH A NEW BOSS WHO DOESN’T KNOW LEAN BUT WANTS US TO SWITCH TO AGILE INSTEAD~~?]<br/>		Source : [https://www.lean.org/balle/DisplayObject.cfm?o=4983 Any advice for a team with a new boss who doesn’t know lean but wants us to switch to agile instead?]<br/>
	Date : 08/07/2019<br/>		Date : 08/07/2019<br/>
	----		----

Métaposition

Fabrice Aimetti — Fri, 31 Jul 2026 09:08:34 GMT

@@ Ligne 10 : / Ligne 10 : @@
 ''Traduction :''<br />
 <br />
 [[Fichier:Metaposition Cungi's Bike FR.jpg|border|link=|800px]]
 ----
 [[Fichier:Metaposition Cungi's Bike EN.jpeg|border|link|800px]]

Métaposition

Fabrice Aimetti — Fri, 31 Jul 2026 09:06:07 GMT

Page créée avec « Catégorie:Portail_Coach'Agile Catégorie:Supervision Auteur : Michel Moral Source : [https://www.linkedin.com/in/michel-moral-msc-phd-8a86425 One skill that a coach, and even more so a supervisor, must acquire is "metaposition"] Date : 28/07/2026 ---- Traducteur : Fabrice Aimetti Date : 31/07/2026 ---- ''Traduction :'' border|link=|800px ---- Fichier:Metaposition... »

Nouvelle page

[[Catégorie:Portail_Coach%27Agile]]
[[Catégorie:Supervision]]
Auteur : Michel Moral 
Source : [https://www.linkedin.com/in/michel-moral-msc-phd-8a86425 One skill that a coach, and even more so a supervisor, must acquire is "metaposition"] 
Date : 28/07/2026 
----
Traducteur : Fabrice Aimetti 
Date : 31/07/2026 
----
''Traduction :'' 
 
[[Fichier:Metaposition Cungi's Bike FR.jpg|border|link=|800px]]
----
[[Fichier:Metaposition Cungi's Bike EN.jpeg|border|link|800px]]

Fichier:Metaposition Cungi's Bike EN.jpeg

Fabrice Aimetti — Fri, 31 Jul 2026 09:05:46 GMT

Fabrice Aimetti a téléversé Fichier:Metaposition Cungi's Bike EN.jpeg

Nouvelle page

Fichier:Metaposition Cungi's Bike FR.jpg

Fabrice Aimetti — Fri, 31 Jul 2026 09:04:58 GMT

Fabrice Aimetti a téléversé Fichier:Metaposition Cungi's Bike FR.jpg

Nouvelle page

Les 3 maçons

Fabrice Aimetti — Fri, 31 Jul 2026 08:31:45 GMT

← Version précédente		Version du 31 juillet 2026 à 08:31
(7 versions intermédiaires par le même utilisateur non affichées)
Ligne 10 :		Ligne 10 :
	Traduction :<br/>		Traduction :<br/>
	<br/>		<br/>
			Vous n’avez pas besoin d’une vision produit. Mais certaines équipes sont complètement transformées par une telle vision.<br/>
			<br/>
			Une vision produit remplit deux fonctions :
			# L’alignement : clarifier ce que vous construisez
			# L’inspiration : susciter l’adhésion de chacun
			<br/>
			Vous pouvez obtenir l’alignement grâce à un document stratégique. Vous pouvez puiser l’inspiration auprès d’un grand leader.<br/>
			<br/>
			Mais une vision produit remplit ces deux fonctions à la fois. Et pour certaines équipes, c’est ce qui permet à tout de s’imbriquer parfaitement.<br/>
			<br/>
			L’exemple classique est l’histoire des trois maçons (image de [https://www.linkedin.com/company/sketchplanations/ Sketchplanations]).<br/>
			<br/>
			"Que faites-vous ?"<br/>
			* "Je pose des briques" (tâche)
			* "Je construis un mur" (objectif)
			* "Je crée une cathédrale" (vision)
			<br/>
			Même travail. Une énergie complètement différente.<br/>
			<br/>
			Les visions produit ont mauvaise réputation, car elles peuvent paraître vagues et creuses. Une mauvaise vision vaut pire que pas de vision du tout.<br/>
			<br/>
			Le problème, c’est que la plupart des visions se résument à une seule phrase : "Nous donnons aux équipes les moyens de donner le meilleur d’elles-mêmes."<br/>
			<br/>
			Cela n’apporte presque jamais rien d’utile. C’est trop abstrait pour fédérer qui que ce soit et trop fade pour inspirer qui que ce soit.<br/>
			<br/>
			Une bonne vision est visuelle.<br/>

			Il y a quelque chose dans le fait de voir l’expérience de l'utilisateur qui fait tilt... ah, oui je comprends."
			– [https://www.linkedin.com/in/jmiddlesworth/ Jeff Middlesworth]

			Je suis un grand adepte de ce que j'appelle les "Visiontypes" : vision + prototype. Il s'agit de storyboards, de maquettes ou de prototypes légers qui montrent à quoi ressemble réellement l'expérience client.<br/>
			<br/>
			Ils fonctionnent parce que :
			* Les gens peuvent voir et toucher l'avenir, et pas seulement en prendre connaissance par écrit
			* Ils vous obligent à prendre des décisions concrètes concernant l'expérience
			* Ils sont faciles à consulter lors de la planification, des revues de conception et des séances plénières
			* Ils mettent en évidence les lacunes dans votre réflexion que les mots seuls masquent
			<br/>
			Il y a bien sûr des recoupements avec la stratégie, les OKR et d'autres outils. Parfois, une stratégie rigoureuse et des objectifs clairs suffisent.<br/>
			<br/>
			Mais envisagez une vision lorsque :
			* Votre équipe travaille bien mais manque de conviction quant à la direction à prendre
			* Plusieurs équipes doivent œuvrer ensemble vers un avenir commun
			* Les parties prenantes ne cessent de tirer dans des directions différentes
			* Un document stratégique existe mais personne ne s’y réfère
			<br/>
			Une stratégie s’adresse à la raison.<br/>
			Une vision s’adresse au coeur.<br/>
			Les meilleures équipes produit possèdent les deux.<br/>
			<br/>
			[[Fichier:The 3 bricklayers FR.png\|border\|link=\|1000px]]
			----
			[[Fichier:The 3 bricklayers EN.jpeg\|border\|link=\|1000px]]

Fichier:The 3 bricklayers EN.jpeg

Fabrice Aimetti — Fri, 31 Jul 2026 08:19:15 GMT

Fabrice Aimetti a téléversé Fichier:The 3 bricklayers EN.jpeg

Nouvelle page

Fichier:The 3 bricklayers FR.png

Fabrice Aimetti — Fri, 31 Jul 2026 08:18:45 GMT

Fabrice Aimetti a téléversé Fichier:The 3 bricklayers FR.png

Nouvelle page

Les 3 maçons

Fabrice Aimetti — Fri, 31 Jul 2026 08:18:27 GMT

Page créée avec « Category: Portail Product Owner Category: Vision Auteur : Ed Biden Source : [https://www.linkedin.com/posts/edbiden_you-dont-need-a-product-vision-but-some-activity-7487809174773583872-1FhH You don't need a product vision] Date : 29/07/2026 ---- Traducteur : Fabrice Aimetti Date : 31/07/2026 ---- Traduction :  »

Nouvelle page

[[Category: Portail Product Owner]]
[[Category: Vision]]
Auteur : Ed Biden 
Source : [https://www.linkedin.com/posts/edbiden_you-dont-need-a-product-vision-but-some-activity-7487809174773583872-1FhH You don't need a product vision] 
Date : 29/07/2026 
----
Traducteur : Fabrice Aimetti 
Date : 31/07/2026 
----
Traduction :