Fabrice Aimetti le 17 août 2018 à 11:26

Fabrice Aimetti — Fri, 17 Aug 2018 11:26:24 GMT

← Version précédente		Version du 17 août 2018 à 11:26
Ligne 1 :		Ligne 1 :
	[[Category: Ken Schwaber]]		[[Category: Ken Schwaber]]
	[[Category: Portail Framework]]		[[Category: Portail Framework]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Ken Schwaber<br /> Source : [http://kenschwaber.wordpress.com/2012/05/25/waste-not/ Waste Not]<br /> Date : 25/05/2012<br />		Auteur : Ken Schwaber<br />
			Source : [http://kenschwaber.wordpress.com/2012/05/25/waste-not/ Waste Not]<br />
			Date : 25/05/2012<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 27/05/2012<br />		Traducteur : Fabrice Aimetti<br />
			Date : 27/05/2012<br />
	----		----
	''Traduction :''<br /> <span style="display: block; text-align: justify">Les gaspillages font obstacle à l'agilité. Non seulement ils vous ralentissent dans votre progression, mais ils vous privent de l'argent que vous auriez investi par ailleurs pour créer de la valeur.</span><br /> <span style="display: block; text-align: justify">J'ai donc évalué le gaspillage potentiellement généré par les notions de vélocité et de capacité. Certains utilisateurs de Scrum tentent de prédire le résultat du sprint à venir en utilisant la vélocité, la quantité de travail ou les items du backlog produit qu'ils prédisent pouvoir réaliser. Une pratique utilisée pour calculer la vélocité est d'inspecter les vélocités passées est de projeter la capacité de l'équipe.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ça me pose des questions. Lorsque nous commençons un projet ou une release, nous disposons évidemment d'un périmètre général, d'un coût prévisionnel et d'une échéance prévisionnelle. Nous progressons ensuite, sprint après sprint, en ajustant nos plans en fonction de la réalité du terrain. Nous pouvons aller plus rapidement ou plus lentement que prévu. Nous pouvons rencontrer de nouvelles opportunités ou de nouveaux défis. Nous pouvons réaliser qu'une partie de ce que nous avions prévu est de moindre valeur que certains besoins émergents.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Supposons que nous ignorions complètement la vélocité et la capacité. Lors de la réunion de planification du sprint, l'équipe de développement sélectionne des éléments du backlog produit et définit l'objectif du sprint. Pendant le sprint, l'équipe collabore avec le Product Owner pour supprimer certains éléments du backlog produit qu'elle ne pourra pas réaliser, ou au contraire pour ajouter des items du backlog produit qui respectent l'objectif et qui puissent être traités dans le temps restant. A la fin du sprint, l'équipe a fini ce qu'elle a fini. Lors de la revue de sprint, le Product Owner, l'équipe de développement et les parties prenantes inspectent et adaptent à partir de ce qui a été réalisé.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Nous utilisons des cycles de développement courts, avec une durée de sprint qui peut descendre à la semaine, ce qui nous permettra de régulièrement connaître notre état d'avancement par rapport à nos objectifs, engagements et prévisions. Je soupçonne, à moins que vous me convainquiez du contraire, que le temps que nous passons à nous préoccuper de vélocité et de capacité, est du gaspillage et que cela n'ajoute pas un grain de valeur.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ma pensée du jour,</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ken.</span>		Traduction :<br />
			<br/>
			<span style="display: block; text-align: justify">Les gaspillages font obstacle à l'agilité. Non seulement ils vous ralentissent dans votre progression, mais ils vous privent de l'argent que vous auriez investi par ailleurs pour créer de la valeur.</span><br /> <span style="display: block; text-align: justify">J'ai donc évalué le gaspillage potentiellement généré par les notions de vélocité et de capacité. Certains utilisateurs de Scrum tentent de prédire le résultat du sprint à venir en utilisant la vélocité, la quantité de travail ou les items du backlog produit qu'ils prédisent pouvoir réaliser. Une pratique utilisée pour calculer la vélocité est d'inspecter les vélocités passées est de projeter la capacité de l'équipe.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ça me pose des questions. Lorsque nous commençons un projet ou une release, nous disposons évidemment d'un périmètre général, d'un coût prévisionnel et d'une échéance prévisionnelle. Nous progressons ensuite, sprint après sprint, en ajustant nos plans en fonction de la réalité du terrain. Nous pouvons aller plus rapidement ou plus lentement que prévu. Nous pouvons rencontrer de nouvelles opportunités ou de nouveaux défis. Nous pouvons réaliser qu'une partie de ce que nous avions prévu est de moindre valeur que certains besoins émergents.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Supposons que nous ignorions complètement la vélocité et la capacité. Lors de la réunion de planification du sprint, l'équipe de développement sélectionne des éléments du backlog produit et définit l'objectif du sprint. Pendant le sprint, l'équipe collabore avec le Product Owner pour supprimer certains éléments du backlog produit qu'elle ne pourra pas réaliser, ou au contraire pour ajouter des items du backlog produit qui respectent l'objectif et qui puissent être traités dans le temps restant. A la fin du sprint, l'équipe a fini ce qu'elle a fini. Lors de la revue de sprint, le Product Owner, l'équipe de développement et les parties prenantes inspectent et adaptent à partir de ce qui a été réalisé.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Nous utilisons des cycles de développement courts, avec une durée de sprint qui peut descendre à la semaine, ce qui nous permettra de régulièrement connaître notre état d'avancement par rapport à nos objectifs, engagements et prévisions. Je soupçonne, à moins que vous me convainquiez du contraire, que le temps que nous passons à nous préoccuper de vélocité et de capacité, est du gaspillage et que cela n'ajoute pas un grain de valeur.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ma pensée du jour,</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Ken.</span>

Fabrice Aimetti : Page créée avec « Category: Ken Schwaber Category: Portail Framework
Auteur : Ken Schwaber
Source : [http://kensch... »

Fabrice Aimetti — Sun, 01 Jul 2018 09:44:41 GMT

Page créée avec « Category: Ken Schwaber Category: Portail Framework <div id="content_view" class="wiki" style="display: block"> Auteur : Ken Schwaber Source : [http://kensch... »

Nouvelle page

[[Category: Ken Schwaber]]
[[Category: Portail Framework]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Ken Schwaber Source : [http://kenschwaber.wordpress.com/2012/05/25/waste-not/ Waste Not] Date : 25/05/2012 
----
Traducteur : Fabrice Aimetti Date : 27/05/2012 
----
''Traduction :'' Les gaspillages font obstacle à l'agilité. Non seulement ils vous ralentissent dans votre progression, mais ils vous privent de l'argent que vous auriez investi par ailleurs pour créer de la valeur. J'ai donc évalué le gaspillage potentiellement généré par les notions de vélocité et de capacité. Certains utilisateurs de Scrum tentent de prédire le résultat du sprint à venir en utilisant la vélocité, la quantité de travail ou les items du backlog produit qu'ils prédisent pouvoir réaliser. Une pratique utilisée pour calculer la vélocité est d'inspecter les vélocités passées est de projeter la capacité de l'équipe. Ça me pose des questions. Lorsque nous commençons un projet ou une release, nous disposons évidemment d'un périmètre général, d'un coût prévisionnel et d'une échéance prévisionnelle. Nous progressons ensuite, sprint après sprint, en ajustant nos plans en fonction de la réalité du terrain. Nous pouvons aller plus rapidement ou plus lentement que prévu. Nous pouvons rencontrer de nouvelles opportunités ou de nouveaux défis. Nous pouvons réaliser qu'une partie de ce que nous avions prévu est de moindre valeur que certains besoins émergents. Supposons que nous ignorions complètement la vélocité et la capacité. Lors de la réunion de planification du sprint, l'équipe de développement sélectionne des éléments du backlog produit et définit l'objectif du sprint. Pendant le sprint, l'équipe collabore avec le Product Owner pour supprimer certains éléments du backlog produit qu'elle ne pourra pas réaliser, ou au contraire pour ajouter des items du backlog produit qui respectent l'objectif et qui puissent être traités dans le temps restant. A la fin du sprint, l'équipe a fini ce qu'elle a fini. Lors de la revue de sprint, le Product Owner, l'équipe de développement et les parties prenantes inspectent et adaptent à partir de ce qui a été réalisé. Nous utilisons des cycles de développement courts, avec une durée de sprint qui peut descendre à la semaine, ce qui nous permettra de régulièrement connaître notre état d'avancement par rapport à nos objectifs, engagements et prévisions. Je soupçonne, à moins que vous me convainquiez du contraire, que le temps que nous passons à nous préoccuper de vélocité et de capacité, est du gaspillage et que cela n'ajoute pas un grain de valeur. Ma pensée du jour, Ken.

Pas de gaspillage - Historique des versions

Fabrice Aimetti le 17 août 2018 à 11:26

Fabrice Aimetti : Page créée avec « Category: Ken Schwaber Category: Portail Framework Auteur : Ken Schwaber Source : [http://kensch... »

Fabrice Aimetti : Page créée avec « Category: Ken Schwaber Category: Portail Framework
Auteur : Ken Schwaber
Source : [http://kensch... »