Voir la source de Quelques Réflexions sur la Planification Agile

[[Category: Portail Planification]]
[[Category: Mike Cottmeyer]]
<div id="content_view" class="wiki" style="display: block"><span class="s1">Auteur : </span>[https://twitter.com/mcottmeyer Mike Cottmeyer]<br /> <span class="s1">Source : </span>[http://www.leadingagile.com/2011/05/some-thoughts-on-agile-planning/ "Some Thoughts on Agile Planning"]<br /> <span class="s1">Date : 10/05/2011</span><br />
----
<span class="s1">Traducteur : Fabrice Aimetti</span><br /> <span class="s1">Date : 18/05/2011</span><br />
----
''<span class="s1">Traduction :</span>''<br /> <br /> 
=<span class="s1">'''Math 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 /> 

# <span style="line-height: 1.5">taille du backlog / vélocité = durée</span>
# <span style="line-height: 1.5">durée * vélocité = taille du backlog</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 /> 
==<span class="s1">Limiter le TAF </span>==
<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>==
<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>==
<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>==
<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 />