Quelques Réflexions sur la Planification Agile - Historique des versions

Fabrice Aimetti le 16 mai 2020 à 19:41

Fabrice Aimetti — Sat, 16 May 2020 19:41:58 GMT

← Version précédente		Version du 16 mai 2020 à 19:41
Ligne 6 :		Ligne 6 :
	----		----
	''<span class="s1">Traduction :</span>''<br /> <br />		''<span class="s1">Traduction :</span>''<br /> <br />
	==<Maths Agile==		==Maths Agile==
	<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />		<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />

Fabrice Aimetti le 16 mai 2020 à 19:41

Fabrice Aimetti — Sat, 16 May 2020 19:41:41 GMT

← Version précédente		Version du 16 mai 2020 à 19:41
Ligne 6 :		Ligne 6 :
	----		----
	''<span class="s1">Traduction :</span>''<br /> <br />		''<span class="s1">Traduction :</span>''<br /> <br />
	=<~~span class="s1">'''~~Maths Agile~~'''</span>~~=		==<Maths Agile==
	<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />		<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />

Ligne 13 :		Ligne 13 :
	# <span style="line-height: 1.5">taille du backlog / durée = vélocité</span>		# <span style="line-height: 1.5">taille du backlog / durée = vélocité</span>
	<br /> <span class="s1">En général, je suggère que l'agilité verrouille le temps et le coût, et que le périmètre en découle... mais ce n'est pas obligatoire. N'hésitez pas à déduire la durée en fixant le backlog et la vélocité. Vous pouvez même obtenir une vélocité en fixant le périmètre et la durée. Cette dernière hypothèse est la plus risquée, alors préparez-vous à mesurer, ajuster et négocier pendant tout le déroulement du projet.</span><br /> <br />		<br /> <span class="s1">En général, je suggère que l'agilité verrouille le temps et le coût, et que le périmètre en découle... mais ce n'est pas obligatoire. N'hésitez pas à déduire la durée en fixant le backlog et la vélocité. Vous pouvez même obtenir une vélocité en fixant le périmètre et la durée. Cette dernière hypothèse est la plus risquée, alors préparez-vous à mesurer, ajuster et négocier pendant tout le déroulement du projet.</span><br /> <br />
	==~~<span class~~=~~"s1">~~Limiter le TAF ~~</span>~~==		===Limiter le TAF===
	<span class="s1">(NdT : </span>TAF = Travaux A Faire = WIP = Work in Progress)<br /> <br /> <span class="s1">Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas.</span><br /> <br />		<span class="s1">(NdT : </span>TAF = Travaux A Faire = WIP = Work in Progress)<br /> <br /> <span class="s1">Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas.</span><br /> <br />
	==~~<span class~~=~~"s1">~~Cracher le backlog~~</span>~~==		===Cracher le backlog===
	<br /> <span class="s1">En règle générale, voilà ce que je demande au management qui est à côté de la plaque... donnez-nous trois sprints pour aider l'équipe à préparer le backlog et établir une vélocité, ensuite nous déciderons comment aller plus loin sur la base de ce que nous aurons obtenu. Nous commencerons par initialiser juste ce qu'il faut de backlog pour planifier un ou deux sprints et permettre à l'équipe de calculer sa vélocité.</span><br /> <br /> <span class="s1">Pendant que l'équipe commence à travailler et à calculer sa vélocité, le PO en bave pour créer le backlog. Je n'ai quasiment jamais vu un PO capable de créer un backlog tout seul. La plupart du temps, nous avons besoin de chefs produits, d'architectes et d'analystes pour disposer d'une vue globale. Et je demande donc systématiquement à ces personnes de travailler avec nous à temps plein - et aussi longtemps que nécessaire - pour obtenir le backlog.</span><br /> <br /> <span class="s1">J'ai eu une équipe de PO qui l'a fait pendant 8 semaines juste pour prendre de l'avance sur l'équipe et définir le contenu de la release. Au départ, l'équipe PO était concentrée sur le fait d'alimenter les équipes en maximisant la valeur métier adressée pendant les sprints... mais au fur et à mesure que le backlog a émergé, nous avons commencé à bien cerner l'application. En fait, si tout se passe bien, après plusieurs sprints nous obtenons une vision honorable de ce que nous avons à construire et la cadence à laquelle l'équipe peut finir le travail. Rendu à ce point, nous appliquons l'une des trois formules, traçons la feuille de route et c'est parti.</span><br /> <br />		<br /> <span class="s1">En règle générale, voilà ce que je demande au management qui est à côté de la plaque... donnez-nous trois sprints pour aider l'équipe à préparer le backlog et établir une vélocité, ensuite nous déciderons comment aller plus loin sur la base de ce que nous aurons obtenu. Nous commencerons par initialiser juste ce qu'il faut de backlog pour planifier un ou deux sprints et permettre à l'équipe de calculer sa vélocité.</span><br /> <br /> <span class="s1">Pendant que l'équipe commence à travailler et à calculer sa vélocité, le PO en bave pour créer le backlog. Je n'ai quasiment jamais vu un PO capable de créer un backlog tout seul. La plupart du temps, nous avons besoin de chefs produits, d'architectes et d'analystes pour disposer d'une vue globale. Et je demande donc systématiquement à ces personnes de travailler avec nous à temps plein - et aussi longtemps que nécessaire - pour obtenir le backlog.</span><br /> <br /> <span class="s1">J'ai eu une équipe de PO qui l'a fait pendant 8 semaines juste pour prendre de l'avance sur l'équipe et définir le contenu de la release. Au départ, l'équipe PO était concentrée sur le fait d'alimenter les équipes en maximisant la valeur métier adressée pendant les sprints... mais au fur et à mesure que le backlog a émergé, nous avons commencé à bien cerner l'application. En fait, si tout se passe bien, après plusieurs sprints nous obtenons une vision honorable de ce que nous avons à construire et la cadence à laquelle l'équipe peut finir le travail. Rendu à ce point, nous appliquons l'une des trois formules, traçons la feuille de route et c'est parti.</span><br /> <br />
	==~~<span class~~=~~"s1">~~Emergence ou Convergence~~</span>~~==		===Emergence ou Convergence===
	<br /> <span class="s1">Le temps de préparation que vous devez prendre par rapport à l'équipe repose grandement sur les objectifs métiers de la release à venir. Si vous êtes très incertain sur ce que vous avez besoin de construire, c'est sûrement mieux d'avoir un petit backlog et de rester très souple quant à la planification de la release. Essayer de prédire des choses que vous ne savez pas est un pur gaspillage. Dans ce cas, l'agilité contribue à faire émerger les besoins, donc les résultats attendus.</span><br /> <br /> <span class="s1">Toutes les entreprises ne sont pas d'accord sur cette démarche... certaines exigent de la stabilité et de la prédictibilité. Dans ce cas, l'équipe PO doit planifier bien en amont de l'équipe et s'ajuster au fur et à mesure que le produit est développé. Plus nous savons où nous allons, et ce que ça va coûter d'y aller, plus nous sommes en capacité d'établir le backlog et plus nous sommes certains des résultats que nous allons obtenir. Ici, l'Agilité soutient une vision convergente des résultats attendus en mettant l'accent sur la réduction des risques et la prédictibilité.</span><br /> <br /> <span class="s1">L'un des plus gros problèmes que j'entrevois pour les équipes qui débutent en agile, c'est qu'elles agissent comme si elles étaient dans une situation de grandes stabilité et prédictibilité, alors que leur produit nécessite une approche émergente : parce que les besoins ne sont pas bien compris, ou parce qu'il y a des risques techniques élevés ou encore une tonne d'inconnues sur la façon de mettre en oeuvre la solution. Quoi qu'il en soit, vous devez considérer que le projet est émergent jusqu'à ce que vous ayez acquis suffisamment de connaissances pour établir un planning réaliste.</span><br /> <br />		<br /> <span class="s1">Le temps de préparation que vous devez prendre par rapport à l'équipe repose grandement sur les objectifs métiers de la release à venir. Si vous êtes très incertain sur ce que vous avez besoin de construire, c'est sûrement mieux d'avoir un petit backlog et de rester très souple quant à la planification de la release. Essayer de prédire des choses que vous ne savez pas est un pur gaspillage. Dans ce cas, l'agilité contribue à faire émerger les besoins, donc les résultats attendus.</span><br /> <br /> <span class="s1">Toutes les entreprises ne sont pas d'accord sur cette démarche... certaines exigent de la stabilité et de la prédictibilité. Dans ce cas, l'équipe PO doit planifier bien en amont de l'équipe et s'ajuster au fur et à mesure que le produit est développé. Plus nous savons où nous allons, et ce que ça va coûter d'y aller, plus nous sommes en capacité d'établir le backlog et plus nous sommes certains des résultats que nous allons obtenir. Ici, l'Agilité soutient une vision convergente des résultats attendus en mettant l'accent sur la réduction des risques et la prédictibilité.</span><br /> <br /> <span class="s1">L'un des plus gros problèmes que j'entrevois pour les équipes qui débutent en agile, c'est qu'elles agissent comme si elles étaient dans une situation de grandes stabilité et prédictibilité, alors que leur produit nécessite une approche émergente : parce que les besoins ne sont pas bien compris, ou parce qu'il y a des risques techniques élevés ou encore une tonne d'inconnues sur la façon de mettre en oeuvre la solution. Quoi qu'il en soit, vous devez considérer que le projet est émergent jusqu'à ce que vous ayez acquis suffisamment de connaissances pour établir un planning réaliste.</span><br /> <br />
	==~~<span class~~=~~"s1">~~Ne pas savoir ce que vous ne savez pas~~</span>~~==		===Ne pas savoir ce que vous ne savez pas===
	<br /> <span class="s1">J'ai récemment rencontré des équipes où tout le monde débutait, était peu familier avec le produit et avec le code. Comment pouvez-vous établir un calendrier dans ce contexte ? La réponse courte est... que vous ne pouvez pas. C'est normal de ne pas savoir, par contre ce n'est pas normal de ne pas parvenir à le savoir. Dans ce cas, il vaut mieux avoir un plan pour le découvrir rapidement. Il n'est pas raisonnable de demander au métier d'investir à l'infini sans aucune stratégie pour arriver à le faire.</span><br /> <br /> <span class="s1">Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas.</span~~><br /> <br /~~>		<br /> <span class="s1">J'ai récemment rencontré des équipes où tout le monde débutait, était peu familier avec le produit et avec le code. Comment pouvez-vous établir un calendrier dans ce contexte ? La réponse courte est... que vous ne pouvez pas. C'est normal de ne pas savoir, par contre ce n'est pas normal de ne pas parvenir à le savoir. Dans ce cas, il vaut mieux avoir un plan pour le découvrir rapidement. Il n'est pas raisonnable de demander au métier d'investir à l'infini sans aucune stratégie pour arriver à le faire.</span><br /> <br /> <span class="s1">Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas.</span>

Fabrice Aimetti le 10 juillet 2019 à 18:18

Fabrice Aimetti — Wed, 10 Jul 2019 18:18:37 GMT

← Version précédente		Version du 10 juillet 2019 à 18:18
Ligne 6 :		Ligne 6 :
	----		----
	''<span class="s1">Traduction :</span>''<br /> <br />		''<span class="s1">Traduction :</span>''<br /> <br />
	=<span class="s1">'''~~Math~~ Agile'''</span>=		=<span class="s1">'''Maths Agile'''</span>=
	<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />		<br /> <span class="s1">Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième.</span><br /> <br />

Fabrice Aimetti : Page créée avec « Category: Portail Planification Category: Mike Cottmeyer
Auteur : [https://twitt... »

Fabrice Aimetti — Tue, 17 Jul 2018 07:01:55 GMT

Page créée avec « Category: Portail Planification Category: Mike Cottmeyer <div id="content_view" class="wiki" style="display: block">Auteur : [https://twitt... »

Nouvelle page

[[Category: Portail Planification]]
[[Category: Mike Cottmeyer]]
<div id="content_view" class="wiki" style="display: block">Auteur : [https://twitter.com/mcottmeyer Mike Cottmeyer] Source : [http://www.leadingagile.com/2011/05/some-thoughts-on-agile-planning/ "Some Thoughts on Agile Planning"] Date : 10/05/2011 
----
Traducteur : Fabrice Aimetti Date : 18/05/2011 
----
''Traduction :'' 
='''Math Agile'''=
 Les principes mathématiques utilisés par une équipe agile sont assez simples. Vous pouvez découper les choses de plusieurs façons, mais à la fin de la journée, l'une des trois formules de base suivantes doit être vérifiée. C'est une question de temps, de coût et de périmètre... vous devez décider quelles sont les deux contraintes que vous souhaitez verrouiller, puis ensuite vous devez en déduire la troisième. 

# taille du backlog / vélocité = durée
# durée * vélocité = taille du backlog
# taille du backlog / durée = vélocité
 En général, je suggère que l'agilité verrouille le temps et le coût, et que le périmètre en découle... mais ce n'est pas obligatoire. N'hésitez pas à déduire la durée en fixant le backlog et la vélocité. Vous pouvez même obtenir une vélocité en fixant le périmètre et la durée. Cette dernière hypothèse est la plus risquée, alors préparez-vous à mesurer, ajuster et négocier pendant tout le déroulement du projet. 
==Limiter le TAF ==
(NdT : TAF = Travaux A Faire = WIP = Work in Progress) Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas. 
==Cracher le backlog==
 En règle générale, voilà ce que je demande au management qui est à côté de la plaque... donnez-nous trois sprints pour aider l'équipe à préparer le backlog et établir une vélocité, ensuite nous déciderons comment aller plus loin sur la base de ce que nous aurons obtenu. Nous commencerons par initialiser juste ce qu'il faut de backlog pour planifier un ou deux sprints et permettre à l'équipe de calculer sa vélocité. Pendant que l'équipe commence à travailler et à calculer sa vélocité, le PO en bave pour créer le backlog. Je n'ai quasiment jamais vu un PO capable de créer un backlog tout seul. La plupart du temps, nous avons besoin de chefs produits, d'architectes et d'analystes pour disposer d'une vue globale. Et je demande donc systématiquement à ces personnes de travailler avec nous à temps plein - et aussi longtemps que nécessaire - pour obtenir le backlog. J'ai eu une équipe de PO qui l'a fait pendant 8 semaines juste pour prendre de l'avance sur l'équipe et définir le contenu de la release. Au départ, l'équipe PO était concentrée sur le fait d'alimenter les équipes en maximisant la valeur métier adressée pendant les sprints... mais au fur et à mesure que le backlog a émergé, nous avons commencé à bien cerner l'application. En fait, si tout se passe bien, après plusieurs sprints nous obtenons une vision honorable de ce que nous avons à construire et la cadence à laquelle l'équipe peut finir le travail. Rendu à ce point, nous appliquons l'une des trois formules, traçons la feuille de route et c'est parti. 
==Emergence ou Convergence==
 Le temps de préparation que vous devez prendre par rapport à l'équipe repose grandement sur les objectifs métiers de la release à venir. Si vous êtes très incertain sur ce que vous avez besoin de construire, c'est sûrement mieux d'avoir un petit backlog et de rester très souple quant à la planification de la release. Essayer de prédire des choses que vous ne savez pas est un pur gaspillage. Dans ce cas, l'agilité contribue à faire émerger les besoins, donc les résultats attendus. Toutes les entreprises ne sont pas d'accord sur cette démarche... certaines exigent de la stabilité et de la prédictibilité. Dans ce cas, l'équipe PO doit planifier bien en amont de l'équipe et s'ajuster au fur et à mesure que le produit est développé. Plus nous savons où nous allons, et ce que ça va coûter d'y aller, plus nous sommes en capacité d'établir le backlog et plus nous sommes certains des résultats que nous allons obtenir. Ici, l'Agilité soutient une vision convergente des résultats attendus en mettant l'accent sur la réduction des risques et la prédictibilité. L'un des plus gros problèmes que j'entrevois pour les équipes qui débutent en agile, c'est qu'elles agissent comme si elles étaient dans une situation de grandes stabilité et prédictibilité, alors que leur produit nécessite une approche émergente : parce que les besoins ne sont pas bien compris, ou parce qu'il y a des risques techniques élevés ou encore une tonne d'inconnues sur la façon de mettre en oeuvre la solution. Quoi qu'il en soit, vous devez considérer que le projet est émergent jusqu'à ce que vous ayez acquis suffisamment de connaissances pour établir un planning réaliste. 
==Ne pas savoir ce que vous ne savez pas==
 J'ai récemment rencontré des équipes où tout le monde débutait, était peu familier avec le produit et avec le code. Comment pouvez-vous établir un calendrier dans ce contexte ? La réponse courte est... que vous ne pouvez pas. C'est normal de ne pas savoir, par contre ce n'est pas normal de ne pas parvenir à le savoir. Dans ce cas, il vaut mieux avoir un plan pour le découvrir rapidement. Il n'est pas raisonnable de demander au métier d'investir à l'infini sans aucune stratégie pour arriver à le faire. Mais c'est là qu'il y a un hic... lorsque que l'équipe a trop de travail et pas assez de temps pour le faire, il y a une dissonance entre le message de l'agilité et ce l'équipe constate sur le terrain. Nous pouvons toujours dire que le PO décide du "quoi" et que l'équipe décide du "comment" et du "combien", mais si le management fixe les trois variables alors l'équipe ne s'engagera pas.

Quelques Réflexions sur la Planification Agile - Historique des versions

Fabrice Aimetti le 16 mai 2020 à 19:41

Fabrice Aimetti le 16 mai 2020 à 19:41

Fabrice Aimetti le 10 juillet 2019 à 18:18

Fabrice Aimetti : Page créée avec « Category: Portail Planification Category: Mike Cottmeyer Auteur : [https://twitt... »

Fabrice Aimetti : Page créée avec « Category: Portail Planification Category: Mike Cottmeyer
Auteur : [https://twitt... »