La stabilité d'abord... La vitesse ensuite ! - Historique des versions

Fabrice Aimetti le 16 août 2018 à 11:38

2018-08-16T11:38:36Z

← Version précédente		Version du 16 août 2018 à 11:38
Ligne 1 :		Ligne 1 :
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
	[[Category: Mike Cottmeyer]]		[[Category: Mike Cottmeyer]]
	~~<div id="content_view" class="wiki" style="display: block">~~ Auteur : Mike Cottmeyer<br /> Source : [http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed Stability first... then speed!]<br />		Auteur : Mike Cottmeyer<br />
			Source : [http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed Stability first... then speed!]<br />
	----		----
	Traducteur : Fabrice Aimetti<br /> Date : 30/09/2009<br />		Traducteur : Fabrice Aimetti<br />
			Date : 30/09/2009<br />
	----		----
	''Traduction :''<br /> <br /> <span style="display: block; text-align: justify">Beaucoup de gens souhaitent appuyer sur un bouton et magiquement devenir agile. Ils désirent bénéficier de tous les avantages sans avoir à fournir le gigantesque effort qui accompagne la transformation réelle de l'organisation. Les gens pensent que parce qu'ils lisent juste un livre ... ou ont pris quelques jours de formation ... qu'ils peuvent s'attendre à une productivité instantanée. Ils ne réalisent pas que les méthodes agiles vous montrent uniquement vos problèmes... c'est encore à vous de les régler...<br /> <br /> Je vais souvent voir cet a priori se manifester sous forme de questions du style "au bout de combien d'itérations puis-je espérer que la vélocité de mon équipe commence à augmenter ?". Il y a tellement de paramètres en jeu qu'il est difficile de répondre à une telle question. Y-a-t-il un Product Backlog priorisé ? Y-a-t-il un Product Owner affinant le backlog à disposition de l'équipe ? L'équipe est-elle multi-compétentes ? Sont-ils dédiés au projet ? Ont-ils tout ce dont ils ont besoin pour réussir ? Y-a-t-il des dépendances externes ?<br /> <br /> Toutes ces choses posent problème ... et vous n'êtes pas sûr de l'impact que la réponse aura sur la capacité de l'équipe à livrer.<br /> <br /> Ma recommandation est généralement de considérer la performance de l'équipe en trois phases. Le premier objectif est de mesurer la performance actuelle ... pour établir une référence. Puis, réfléchir à comment stabiliser ce niveau de performance... un niveau de performance stable est essentiel à l'exécution d'un projet agile dans des conditions prévisibles. Une fois que vous êtes stables ... maintenant vous pouvez commencer à réfléchir à comment aller de plus en plus vite. Adopter l'Agile est un processus d'apprentissage et vous ne pouvez pas améliorer un système lorsque vous ne comprenez pas ce qui est en panne dans ce système.<br /> <br /> Et c'est vraiment la clé ... Il ne s'agit pas d'obtenir une meilleure vélocité. Il s'agit de réparer les parties "en panne" dans votre organisation. Il s'agit d'examiner votre situation et de la confronter à la situation dans laquelle vous souhaiteriez vraiment être. Il s'agit de comprendre les obstacles qui sont sur votre chemin et les traiter de manière significative ... d'une manière qui permet vraiment réellement d'aider l'équipe à s'améliorer. Il s'agit de devenir plus efficace dans la création de valeur et d'améliorer réellement les processus qui permettent de créer de la valeur.<br /> <br /> Ce genre de réponses ne se traduit pas dans un baratin marketing. Combien de temps faut-il pour devenir agile ? Je ne sais pas ... combien d'itérations cela va-t-il prendre pour supprimer les obstacles organisationnels qui freinent l'équipe ? Combien d'itérations faudra-t-il jusqu'à ce que vous soyez prêt à réparer ce qui est vraiment en panne ? Combien d'itérations jusqu'à ce que nous soyons prêts à cesser de poser des étiquettes partout et à VRAIMENT commencer à transformer l'organisation ?<br /> </span>		Traduction :<br />
			<br />
			<span style="display: block; text-align: justify">Beaucoup de gens souhaitent appuyer sur un bouton et magiquement devenir agile. Ils désirent bénéficier de tous les avantages sans avoir à fournir le gigantesque effort qui accompagne la transformation réelle de l'organisation. Les gens pensent que parce qu'ils lisent juste un livre ... ou ont pris quelques jours de formation ... qu'ils peuvent s'attendre à une productivité instantanée. Ils ne réalisent pas que les méthodes agiles vous montrent uniquement vos problèmes... c'est encore à vous de les régler...<br /> <br /> Je vais souvent voir cet a priori se manifester sous forme de questions du style "au bout de combien d'itérations puis-je espérer que la vélocité de mon équipe commence à augmenter ?". Il y a tellement de paramètres en jeu qu'il est difficile de répondre à une telle question. Y-a-t-il un Product Backlog priorisé ? Y-a-t-il un Product Owner affinant le backlog à disposition de l'équipe ? L'équipe est-elle multi-compétentes ? Sont-ils dédiés au projet ? Ont-ils tout ce dont ils ont besoin pour réussir ? Y-a-t-il des dépendances externes ?<br /> <br /> Toutes ces choses posent problème ... et vous n'êtes pas sûr de l'impact que la réponse aura sur la capacité de l'équipe à livrer.<br /> <br /> Ma recommandation est généralement de considérer la performance de l'équipe en trois phases. Le premier objectif est de mesurer la performance actuelle ... pour établir une référence. Puis, réfléchir à comment stabiliser ce niveau de performance... un niveau de performance stable est essentiel à l'exécution d'un projet agile dans des conditions prévisibles. Une fois que vous êtes stables ... maintenant vous pouvez commencer à réfléchir à comment aller de plus en plus vite. Adopter l'Agile est un processus d'apprentissage et vous ne pouvez pas améliorer un système lorsque vous ne comprenez pas ce qui est en panne dans ce système.<br /> <br /> Et c'est vraiment la clé ... Il ne s'agit pas d'obtenir une meilleure vélocité. Il s'agit de réparer les parties "en panne" dans votre organisation. Il s'agit d'examiner votre situation et de la confronter à la situation dans laquelle vous souhaiteriez vraiment être. Il s'agit de comprendre les obstacles qui sont sur votre chemin et les traiter de manière significative ... d'une manière qui permet vraiment réellement d'aider l'équipe à s'améliorer. Il s'agit de devenir plus efficace dans la création de valeur et d'améliorer réellement les processus qui permettent de créer de la valeur.<br /> <br /> Ce genre de réponses ne se traduit pas dans un baratin marketing. Combien de temps faut-il pour devenir agile ? Je ne sais pas ... combien d'itérations cela va-t-il prendre pour supprimer les obstacles organisationnels qui freinent l'équipe ? Combien d'itérations faudra-t-il jusqu'à ce que vous soyez prêt à réparer ce qui est vraiment en panne ? Combien d'itérations jusqu'à ce que nous soyons prêts à cesser de poser des étiquettes partout et à VRAIMENT commencer à transformer l'organisation ?<br /> </span>

Fabrice Aimetti le 17 juillet 2018 à 07:25

2018-07-17T07:25:40Z

← Version précédente		Version du 17 juillet 2018 à 07:25
Ligne 1 :		Ligne 1 :
	[[Category: Portail Planification]]		[[Category: Portail Planification]]
			[[Category: Mike Cottmeyer]]
	<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cottmeyer<br /> Source : [http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed Stability first... then speed!]<br />		<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cottmeyer<br /> Source : [http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed Stability first... then speed!]<br />
	----		----

Fabrice Aimetti : Page créée avec « Category: Portail Planification
Auteur : Mike Cottmeyer
Source : [http://blog.versionone.com/blog/ve... »

2018-07-17T07:25:22Z

Page créée avec « Category: Portail Planification <div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cottmeyer Source : [http://blog.versionone.com/blog/ve... »

Nouvelle page

[[Category: Portail Planification]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Mike Cottmeyer Source : [http://blog.versionone.com/blog/versionone/0/0/stability-first-then-speed Stability first... then speed!] 
----
Traducteur : Fabrice Aimetti Date : 30/09/2009 
----
''Traduction :'' Beaucoup de gens souhaitent appuyer sur un bouton et magiquement devenir agile. Ils désirent bénéficier de tous les avantages sans avoir à fournir le gigantesque effort qui accompagne la transformation réelle de l'organisation. Les gens pensent que parce qu'ils lisent juste un livre ... ou ont pris quelques jours de formation ... qu'ils peuvent s'attendre à une productivité instantanée. Ils ne réalisent pas que les méthodes agiles vous montrent uniquement vos problèmes... c'est encore à vous de les régler... Je vais souvent voir cet a priori se manifester sous forme de questions du style "au bout de combien d'itérations puis-je espérer que la vélocité de mon équipe commence à augmenter ?". Il y a tellement de paramètres en jeu qu'il est difficile de répondre à une telle question. Y-a-t-il un Product Backlog priorisé ? Y-a-t-il un Product Owner affinant le backlog à disposition de l'équipe ? L'équipe est-elle multi-compétentes ? Sont-ils dédiés au projet ? Ont-ils tout ce dont ils ont besoin pour réussir ? Y-a-t-il des dépendances externes ? Toutes ces choses posent problème ... et vous n'êtes pas sûr de l'impact que la réponse aura sur la capacité de l'équipe à livrer. Ma recommandation est généralement de considérer la performance de l'équipe en trois phases. Le premier objectif est de mesurer la performance actuelle ... pour établir une référence. Puis, réfléchir à comment stabiliser ce niveau de performance... un niveau de performance stable est essentiel à l'exécution d'un projet agile dans des conditions prévisibles. Une fois que vous êtes stables ... maintenant vous pouvez commencer à réfléchir à comment aller de plus en plus vite. Adopter l'Agile est un processus d'apprentissage et vous ne pouvez pas améliorer un système lorsque vous ne comprenez pas ce qui est en panne dans ce système. Et c'est vraiment la clé ... Il ne s'agit pas d'obtenir une meilleure vélocité. Il s'agit de réparer les parties "en panne" dans votre organisation. Il s'agit d'examiner votre situation et de la confronter à la situation dans laquelle vous souhaiteriez vraiment être. Il s'agit de comprendre les obstacles qui sont sur votre chemin et les traiter de manière significative ... d'une manière qui permet vraiment réellement d'aider l'équipe à s'améliorer. Il s'agit de devenir plus efficace dans la création de valeur et d'améliorer réellement les processus qui permettent de créer de la valeur. Ce genre de réponses ne se traduit pas dans un baratin marketing. Combien de temps faut-il pour devenir agile ? Je ne sais pas ... combien d'itérations cela va-t-il prendre pour supprimer les obstacles organisationnels qui freinent l'équipe ? Combien d'itérations faudra-t-il jusqu'à ce que vous soyez prêt à réparer ce qui est vraiment en panne ? Combien d'itérations jusqu'à ce que nous soyons prêts à cesser de poser des étiquettes partout et à VRAIMENT commencer à transformer l'organisation ?

La stabilité d'abord... La vitesse ensuite ! - Historique des versions

Fabrice Aimetti le 16 août 2018 à 11:38

Fabrice Aimetti le 17 juillet 2018 à 07:25

Fabrice Aimetti : Page créée avec « Category: Portail Planification Auteur : Mike Cottmeyer Source : [http://blog.versionone.com/blog/ve... »

Fabrice Aimetti : Page créée avec « Category: Portail Planification
Auteur : Mike Cottmeyer
Source : [http://blog.versionone.com/blog/ve... »