Il s'agit d'Effort, pas de Complexité - Historique des versions

Fabrice Aimetti le 12 août 2018 à 08:08

2018-08-12T08:08:00Z

← Version précédente		Version du 12 août 2018 à 08:08
Ligne 1 :		Ligne 1 :
	[[Category: Mike Cohn]]		[[Category: Mike Cohn]]
	[[Category: Portail Exactimation]]		[[Category: Portail Exactimation]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Mike Cohn<br /> Source : [http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity It's Effort, Not Complexity]<br /> Date : 21/06/2010<br />		Auteur : Mike Cohn<br />
			Source : [http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity It's Effort, Not Complexity]<br />
			Date : 21/06/2010<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 30/06/2012<br />		Traducteur : Fabrice Aimetti<br />
			Date : 30/06/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">La semaine dernière, un client m'a posé la question suivante : "Quand mon équipe aura-t-elle terminé ce projet ?" C'est probablement la millionième fois qu'on me pose cette question concernant la [http://www.mountaingoatsoftware.com/topics/agile-project-management gestion de projet agile] que ce soit d'une manière ou d'une autre. On ne m'a jamais une seule fois posé la question : "Jusqu'à quel point mon équipe doit-elle réfléchir à développer le projet ?". Les clients, les chefs et les parties prenantes se préoccupent du temps que prendra un projet. Il ne se soucie pas du temps que nous passons à réfléchir pour livrer le projet, sauf si cela implique des risques de délais et de coûts. Je dis ça parce que je suis tombé sur un trop grand nombre d'équipes qui pensaient que les points de story étaient basés sur la complexité de la story / feature plutôt que sur l'effort pour la développer. De telles équipes renomment souvent le "point de story" en "point de complexité". Je suppose que cela sonne mieux. Cela fait peut-être plus sophistiqué même. Mais c'est faux. Le point de story ne traitent pas de la complexité à développer une fonctionnalité. Il traite de l'effort nécessaire pour développer une fonctionnalité.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Lors d'un cours il y a quelques années, on m'a donné un merveilleux exemple de cela. Supposez que l'équipe est composée d'un petit enfant et d'un chirurgien du cerveau. Leur backlog produit contient deux éléments : lécher 1000 timbres et réaliser une simple petite incision chirurgicale dans le cerveau, c'est tout. Ces éléments ont été choisis pour probablement avoir la même durée. Si vous n'êtes pas d'accord, ajustez le nombre de timbres à lécher dans l'exemple. En dépit de leurs complexités totalement différentes, on peut donner à ces deux éléments le même nombre de points de story, chacun ayant une durée à peu près équivalente à l'autre.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Cet exemple met en évidence un autre aspect de l'estimation en agilité, c'est-à-dire que nous supposons que nous avons en général la bonne personne pour réaliser le travail. Nous ne supposons pas que le petit enfant va finir l'école, faire médecine, se spécialiser pendant 7 ans et seulement à ce moment commencer la chirurgie du cerveau, et que pendant ce temps-là, nous avons un chirurgien du cerveau en train de lécher des timbres dans son coin. Bien sûr, la réalité est différente, et c'est des fois la "mauvaise" personne pour un travail qui le réalise, mais cela n'a jamais les effets dramatiques de notre exemple.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Donc, les points de story traitent de l'effort nécessaire. Soyez libre d'ajuster votre estimation de l'effort en vous basant sur des choses comme le risque et l'incertitude, mais rappelez-vous que les estimations sur les points concernent le temps qu'il faudra pour réaliser un travail. C'est justement ce dont nos clients, chefs et parties prenantes se préoccupent.</span>		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">La semaine dernière, un client m'a posé la question suivante : "Quand mon équipe aura-t-elle terminé ce projet ?" C'est probablement la millionième fois qu'on me pose cette question concernant la [http://www.mountaingoatsoftware.com/topics/agile-project-management gestion de projet agile] que ce soit d'une manière ou d'une autre. On ne m'a jamais une seule fois posé la question : "Jusqu'à quel point mon équipe doit-elle réfléchir à développer le projet ?". Les clients, les chefs et les parties prenantes se préoccupent du temps que prendra un projet. Il ne se soucie pas du temps que nous passons à réfléchir pour livrer le projet, sauf si cela implique des risques de délais et de coûts. Je dis ça parce que je suis tombé sur un trop grand nombre d'équipes qui pensaient que les points de story étaient basés sur la complexité de la story / feature plutôt que sur l'effort pour la développer. De telles équipes renomment souvent le "point de story" en "point de complexité". Je suppose que cela sonne mieux. Cela fait peut-être plus sophistiqué même. Mais c'est faux. Le point de story ne traitent pas de la complexité à développer une fonctionnalité. Il traite de l'effort nécessaire pour développer une fonctionnalité.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Lors d'un cours il y a quelques années, on m'a donné un merveilleux exemple de cela. Supposez que l'équipe est composée d'un petit enfant et d'un chirurgien du cerveau. Leur backlog produit contient deux éléments : lécher 1000 timbres et réaliser une simple petite incision chirurgicale dans le cerveau, c'est tout. Ces éléments ont été choisis pour probablement avoir la même durée. Si vous n'êtes pas d'accord, ajustez le nombre de timbres à lécher dans l'exemple. En dépit de leurs complexités totalement différentes, on peut donner à ces deux éléments le même nombre de points de story, chacun ayant une durée à peu près équivalente à l'autre.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Cet exemple met en évidence un autre aspect de l'estimation en agilité, c'est-à-dire que nous supposons que nous avons en général la bonne personne pour réaliser le travail. Nous ne supposons pas que le petit enfant va finir l'école, faire médecine, se spécialiser pendant 7 ans et seulement à ce moment commencer la chirurgie du cerveau, et que pendant ce temps-là, nous avons un chirurgien du cerveau en train de lécher des timbres dans son coin. Bien sûr, la réalité est différente, et c'est des fois la "mauvaise" personne pour un travail qui le réalise, mais cela n'a jamais les effets dramatiques de notre exemple.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Donc, les points de story traitent de l'effort nécessaire. Soyez libre d'ajuster votre estimation de l'effort en vous basant sur des choses comme le risque et l'incertitude, mais rappelez-vous que les estimations sur les points concernent le temps qu'il faudra pour réaliser un travail. C'est justement ce dont nos clients, chefs et parties prenantes se préoccupent.</span>

Fabrice Aimetti le 1 juillet 2018 à 10:55

2018-07-01T10:55:35Z

← Version précédente		Version du 1 juillet 2018 à 10:55
Ligne 1 :		Ligne 1 :
	[[Category: Mike Cohn]]		[[Category: Mike Cohn]]
	[[Category: Portail Exactimation]]		[[Category: Portail Exactimation]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : ~~[/Mike%20Cohn~~ Mike Cohn]<br /> Source : [http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity It's Effort, Not Complexity]<br /> Date : 21/06/2010<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cohn<br /> Source : [http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity It's Effort, Not Complexity]<br /> Date : 21/06/2010<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 30/06/2012<br />		Traducteur : Fabrice Aimetti<br /> Date : 30/06/2012<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">La semaine dernière, un client m'a posé la question suivante : "Quand mon équipe aura-t-elle terminé ce projet ?" C'est probablement la millionième fois qu'on me pose cette question concernant la [http://www.mountaingoatsoftware.com/topics/agile-project-management gestion de projet agile] que ce soit d'une manière ou d'une autre. On ne m'a jamais une seule fois posé la question : "Jusqu'à quel point mon équipe doit-elle réfléchir à développer le projet ?". Les clients, les chefs et les parties prenantes se préoccupent du temps que prendra un projet. Il ne se soucie pas du temps que nous passons à réfléchir pour livrer le projet, sauf si cela implique des risques de délais et de coûts. Je dis ça parce que je suis tombé sur un trop grand nombre d'équipes qui pensaient que les points de story étaient basés sur la complexité de la story / feature plutôt que sur l'effort pour la développer. De telles équipes renomment souvent le "point de story" en "point de complexité". Je suppose que cela sonne mieux. Cela fait peut-être plus sophistiqué même. Mais c'est faux. Le point de story ne traitent pas de la complexité à développer une fonctionnalité. Il traite de l'effort nécessaire pour développer une fonctionnalité.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Lors d'un cours il y a quelques années, on m'a donné un merveilleux exemple de cela. Supposez que l'équipe est composée d'un petit enfant et d'un chirurgien du cerveau. Leur backlog produit contient deux éléments : lécher 1000 timbres et réaliser une simple petite incision chirurgicale dans le cerveau, c'est tout. Ces éléments ont été choisis pour probablement avoir la même durée. Si vous n'êtes pas d'accord, ajustez le nombre de timbres à lécher dans l'exemple. En dépit de leurs complexités totalement différentes, on peut donner à ces deux éléments le même nombre de points de story, chacun ayant une durée à peu près équivalente à l'autre.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Cet exemple met en évidence un autre aspect de l'estimation en agilité, c'est-à-dire que nous supposons que nous avons en général la bonne personne pour réaliser le travail. Nous ne supposons pas que le petit enfant va finir l'école, faire médecine, se spécialiser pendant 7 ans et seulement à ce moment commencer la chirurgie du cerveau, et que pendant ce temps-là, nous avons un chirurgien du cerveau en train de lécher des timbres dans son coin. Bien sûr, la réalité est différente, et c'est des fois la "mauvaise" personne pour un travail qui le réalise, mais cela n'a jamais les effets dramatiques de notre exemple.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Donc, les points de story traitent de l'effort nécessaire. Soyez libre d'ajuster votre estimation de l'effort en vous basant sur des choses comme le risque et l'incertitude, mais rappelez-vous que les estimations sur les points concernent le temps qu'il faudra pour réaliser un travail. C'est justement ce dont nos clients, chefs et parties prenantes se préoccupent.</span>		''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">La semaine dernière, un client m'a posé la question suivante : "Quand mon équipe aura-t-elle terminé ce projet ?" C'est probablement la millionième fois qu'on me pose cette question concernant la [http://www.mountaingoatsoftware.com/topics/agile-project-management gestion de projet agile] que ce soit d'une manière ou d'une autre. On ne m'a jamais une seule fois posé la question : "Jusqu'à quel point mon équipe doit-elle réfléchir à développer le projet ?". Les clients, les chefs et les parties prenantes se préoccupent du temps que prendra un projet. Il ne se soucie pas du temps que nous passons à réfléchir pour livrer le projet, sauf si cela implique des risques de délais et de coûts. Je dis ça parce que je suis tombé sur un trop grand nombre d'équipes qui pensaient que les points de story étaient basés sur la complexité de la story / feature plutôt que sur l'effort pour la développer. De telles équipes renomment souvent le "point de story" en "point de complexité". Je suppose que cela sonne mieux. Cela fait peut-être plus sophistiqué même. Mais c'est faux. Le point de story ne traitent pas de la complexité à développer une fonctionnalité. Il traite de l'effort nécessaire pour développer une fonctionnalité.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Lors d'un cours il y a quelques années, on m'a donné un merveilleux exemple de cela. Supposez que l'équipe est composée d'un petit enfant et d'un chirurgien du cerveau. Leur backlog produit contient deux éléments : lécher 1000 timbres et réaliser une simple petite incision chirurgicale dans le cerveau, c'est tout. Ces éléments ont été choisis pour probablement avoir la même durée. Si vous n'êtes pas d'accord, ajustez le nombre de timbres à lécher dans l'exemple. En dépit de leurs complexités totalement différentes, on peut donner à ces deux éléments le même nombre de points de story, chacun ayant une durée à peu près équivalente à l'autre.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Cet exemple met en évidence un autre aspect de l'estimation en agilité, c'est-à-dire que nous supposons que nous avons en général la bonne personne pour réaliser le travail. Nous ne supposons pas que le petit enfant va finir l'école, faire médecine, se spécialiser pendant 7 ans et seulement à ce moment commencer la chirurgie du cerveau, et que pendant ce temps-là, nous avons un chirurgien du cerveau en train de lécher des timbres dans son coin. Bien sûr, la réalité est différente, et c'est des fois la "mauvaise" personne pour un travail qui le réalise, mais cela n'a jamais les effets dramatiques de notre exemple.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Donc, les points de story traitent de l'effort nécessaire. Soyez libre d'ajuster votre estimation de l'effort en vous basant sur des choses comme le risque et l'incertitude, mais rappelez-vous que les estimations sur les points concernent le temps qu'il faudra pour réaliser un travail. C'est justement ce dont nos clients, chefs et parties prenantes se préoccupent.</span>

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation
Auteur : [/Mike%20Cohn Mike Cohn]
Source : [h... »

2018-07-01T10:55:23Z

Page créée avec « Category: Mike Cohn Category: Portail Exactimation <div id="content_view" class="wiki" style="display: block"> Auteur : [/Mike%20Cohn Mike Cohn] Source : [h... »

Nouvelle page

[[Category: Mike Cohn]]
[[Category: Portail Exactimation]]
<div id="content_view" class="wiki" style="display: block"> Auteur : [/Mike%20Cohn Mike Cohn] Source : [http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity It's Effort, Not Complexity] Date : 21/06/2010 
----
Traducteur : Fabrice Aimetti Date : 30/06/2012 
----
''Traduction :'' La semaine dernière, un client m'a posé la question suivante : "Quand mon équipe aura-t-elle terminé ce projet ?" C'est probablement la millionième fois qu'on me pose cette question concernant la [http://www.mountaingoatsoftware.com/topics/agile-project-management gestion de projet agile] que ce soit d'une manière ou d'une autre. On ne m'a jamais une seule fois posé la question : "Jusqu'à quel point mon équipe doit-elle réfléchir à développer le projet ?". Les clients, les chefs et les parties prenantes se préoccupent du temps que prendra un projet. Il ne se soucie pas du temps que nous passons à réfléchir pour livrer le projet, sauf si cela implique des risques de délais et de coûts. Je dis ça parce que je suis tombé sur un trop grand nombre d'équipes qui pensaient que les points de story étaient basés sur la complexité de la story / feature plutôt que sur l'effort pour la développer. De telles équipes renomment souvent le "point de story" en "point de complexité". Je suppose que cela sonne mieux. Cela fait peut-être plus sophistiqué même. Mais c'est faux. Le point de story ne traitent pas de la complexité à développer une fonctionnalité. Il traite de l'effort nécessaire pour développer une fonctionnalité. Lors d'un cours il y a quelques années, on m'a donné un merveilleux exemple de cela. Supposez que l'équipe est composée d'un petit enfant et d'un chirurgien du cerveau. Leur backlog produit contient deux éléments : lécher 1000 timbres et réaliser une simple petite incision chirurgicale dans le cerveau, c'est tout. Ces éléments ont été choisis pour probablement avoir la même durée. Si vous n'êtes pas d'accord, ajustez le nombre de timbres à lécher dans l'exemple. En dépit de leurs complexités totalement différentes, on peut donner à ces deux éléments le même nombre de points de story, chacun ayant une durée à peu près équivalente à l'autre. Cet exemple met en évidence un autre aspect de l'estimation en agilité, c'est-à-dire que nous supposons que nous avons en général la bonne personne pour réaliser le travail. Nous ne supposons pas que le petit enfant va finir l'école, faire médecine, se spécialiser pendant 7 ans et seulement à ce moment commencer la chirurgie du cerveau, et que pendant ce temps-là, nous avons un chirurgien du cerveau en train de lécher des timbres dans son coin. Bien sûr, la réalité est différente, et c'est des fois la "mauvaise" personne pour un travail qui le réalise, mais cela n'a jamais les effets dramatiques de notre exemple. Donc, les points de story traitent de l'effort nécessaire. Soyez libre d'ajuster votre estimation de l'effort en vous basant sur des choses comme le risque et l'incertitude, mais rappelez-vous que les estimations sur les points concernent le temps qu'il faudra pour réaliser un travail. C'est justement ce dont nos clients, chefs et parties prenantes se préoccupent.

Il s'agit d'Effort, pas de Complexité - Historique des versions

Fabrice Aimetti le 12 août 2018 à 08:08

Fabrice Aimetti le 1 juillet 2018 à 10:55

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation Auteur : [/Mike%20Cohn Mike Cohn] Source : [h... »

Fabrice Aimetti : Page créée avec « Category: Mike Cohn Category: Portail Exactimation
Auteur : [/Mike%20Cohn Mike Cohn]
Source : [h... »