Agile/PlanningGame

Un article de Agora2ia.


Voir aussi PlanningPoker


Sommaire

Présentation

En XP le client arrive avec un ensemble de scénarios utilisateurs suffisant pour couvrir selon lui plus d'une itération. Il expose ces scénarios aux développeurs.

Les développeurs posent les questions nécessaires pour s'approprier ces scénarios. Ils découpent alors chaque scénario en tâches qu'ils identifient puis estiment consensuellement. La durée d'une tâche ne devant pas dépasser 4 jours. Les développeurs doivent profiter de ce moment privilégié pour confronter et homogénéiser leur connaissance du métier et de l'application.

En sommant l'estimation de chacune des tâches composant un scénario on obtient la durée de chaque scénario.

Le client fera alors le tri parmi les scénario afin de sortir de l'itération les moins importants selon lui, et de prioriser les autres.

Dans le cas d'une itération qui fait suite à une livraison en recette, on pourra éventuellement inclure des tâches de "Traitement des retours de recette éventuels" d'une durée déterminée.


Déroulement

Avant

  • Identifier des stories de référence (la plus courte, la plus longue et une intermédiaire)
  • Ne pas créer les issues au préalable, et encore moins les tâches techniques : ce travail sera le résultat collaboratif de la séance. Par contre le ProductOwner aura fait avant le travail nécessaire à l'identification des issues et à répondre aux questions.


Au début

Partager avec l'équipe

  1. La vision business
  2. L'objectif particulier de l'itération
  3. Voire une démo de l'outil
  4. Faire le point sur le nombre story points disponibles dans l'itération à venir (pour savoir combien on va en estimer)


Puis faire un point sur l'itération passée :

  • Parcourir les issues qui ont le plus dérivé entre l'estimation et le réalisé
  • Pour chacune (ou seulement pour celles qui ont le plus dérivé), identifier pourquoi il y a eu cette dérive.
    • Ce travail peut être pré-maché par le propriétaire de chaque story au moment où il la clos pendant l'itération : il peut alors compléter la story en indiquant à chaud les raisons, selon lui, de la dérive.
    • Les principales raisons peuvent être recensées dans une liste, que l'on pourra ressortir en début de chaque planning game, juste avant d'estimer, afin de se remémorer les principales causes de mauvaise estimation


L'estimation

Le ProductOwner liste les UserStorys qui préssent pour le Sprint en citant le nom et la description, sans passer trop de temps. Cela permet de diffuser une vision globale du Sprint.

Puis on reprend les UserStorys une par une avec l'objectif de les estimer.

Cela peut se faire via la technique du PlanningPoker.

Cette étape se fait en ayant sous les yeux :

  • la DefinitionOfDone
  • la liste des causes de deviance dans les estimations (liste établie dans l'étape précédente).


Globalement

Un PlanningGame mal encadré peut s'eterniser. Le rôle du ScrumMaster y est donc primordial pour garantir une discpline de tous les instants.


Conseils

  • Impliquer les plus timides, en les invitants à reformuler ce qu'ils ont compris par exemple
  • Le PO est-il la bonne personne


En détail

Résumé

Commençons par revenir à l'objectif premier du planning game : fournir une estimation suffisamment juste au Client de ses User Stories pour qu'il puisse en retour donner une priorité à ces User Stories.

Mais le planning game est avant tout une cérémonie.

Au même titre qu'une rétrospective une cérémonie qui vise à remplacer un bilan de fin de projet par voie rédactionnelle, le planning game vise à assurer l'activité de plannification de façon collégiale.

Les deux mots à retenir sont :

  • Plannification
  • Collégial


Planification =

Pour pouvoir planifier, il faut d'abord estimer. Et qui mieux que les personnes amenées à développer sont les mieux placées pour estimer ?

Car une estimation n'est pas une valeur absolue : une tâche donnée n'a pas une estimation universelle, mais bien au contraire, son estimation va dépendre de nombreux facteurs : qui va la réaliser, quelles sont ses compétences, ses connaissances, techniques, fonctionnelles, applicatives...

Une fois les estimations établies, il faut transformer cet amas de durée en une succession de jalons amenant à une date de livraison : la plannification. Cela se fait grâce à un outil précieux : la vélocité. C'est le nombre de Story Points que l'on peut réaliser en une itération. N'ayez pas de craintes, cet outil, contrairement à un couteau, s'aiguise avec le temps ;)


Collégial

Si le planning game est une cérémonie c'est qu'il a une vocation, trop souvent inconsidérée : le partage de connaissance. Un transfert de connaissance à la fois :

  • Fonctionnel
  • Technique

Le planning game est (aussi) un moment de formation !

Vous doutez encore de son utilité ;o)

La responsabilité de chacun est de refuser de donner une estimation si il ne croit pas en cette estimation.

Cela va forcer les discussions, et donc l'échange de connaissance jusqu'à ce que la vision soit suffisemment partagée pour permettre l'estimation.


Granularité des estimations

Bien souvent se pose la question de savoir jusqu'où on pousse le découpage...

  • Est-ce qu'on fait que des User Stories ou aussi le découpage en tâches ?
  • Quelle est la taille maximale des User Stories ?
  • ...

Pour répondre à cette question, je me base sur la première phrase de cet article, à savoir l'objectif du planning game : tout est dans le mot "suffisamment" ;)

En effet, l'objectif est de "donner des estimations suffisamment justes". Donc, si vos estimations sont juste, à savoir proche du réalisé, c'est que votre granularité est suffisante.

Par exemple, j'ai encadré une équipe de développeurs mobiles : dans ce contexte, l'ajout d'une fonctionnalité consiste souvent en l'ajout d'un écran, et selon les cas, cela peut se faire en une journée. Nous avons donc une User Story bien définie d'une durée de 1 jour : pourquoi découper en tâche technique ?

A l'autre extrémité, j'ai travaillé de nombreuses années dans le domaine de l'informatique de gestion, et plus particulièrement dans le domaine bancaire. Là, il est fréquent de rencontrer des fonctionnalités qui contiennent plusieurs écrans complexes, avec consolidation de données provenant d'autres systèmes, en lecture et en écriture, au sein d'une application N tiers, distribuée. J'espère vous avoir convaincu que dans ce contexte, une User Story complète plusieurs semaines. Dans ce cas, on va commencer d'abord par scinder cette Epic (ou épopée) en plusieurs User Stories. Certains des ces "sous" stories (pour ne pas dire toutes) resteront assez complexes et longues pour nécessiter un découpage en tâches techniques. Cela permet tant d'estimer plus justement que d'identifier ce qu'il faut faire pour des membres de l'équipes qui n'aurait une vision suffisamment claire.

Pour ma part, le Bad Smell en terme de taille d'estimation, la limite maximale est 4 jours (ou 5 si vous jouez avec la suite de Fibonacci d'un planning poker ;). Pourquoi 4 ?... Car cela correspond à une petite semaine, et j'ai du mal à croire que l'esprit humain puisse sereinement appréhender toute la dimension d'une tâche qui commencerait le lundi à la première heure pour se terminer le jeudi soir avant l'entrainement de foot.


Pré-définition des issues

J'ai souvent vu des équipes qui commençaient l'agilité débuter les planning game avec User Stories déjà définie au préalable par le Product Owner (créée dans JIRA), voire même parfois le découpage en tâches techniques réalisé, sous le prétexte sincère de vouloir gagner du temps.

C'est pour moi le même raisonnement que dire je ne vais pas m'entrainer mais directement courir mon 400 mètres pour gagner du temps.

Quand vous cherchez à expliquer quelque chose à quelqu'un, et que cela passe par un schéma, il est recommandé de construire le schéma en direct avec le ou les interlocuteurs, et non pas d'arriver avec un schéma tout fait. Cela afin de favoriser l'échange d'information et l'appréhension du message par l'autre.

Dans un planning game c'est pareil.

Le fait de construire "collégialement" la User Story avec l'équipe permet d'en partager la vision.

Quant au fait de pré-découper en tâches, il se peut tout simplement qu'au final, le découpage soit tout autre.

Ce qui ne veut pas dire que le Product Owner doit venir sans avoir préparé la réunion, bien au contraire !


Maturité d'équipe

Mais vous pouvez oublier tout ce que vous venez de lire dans ce chapitre, car la seule règles est qu'il n'y a pas de règles... ;)

Ce que je veux dire avec cette assertion provocante, est que tout dépend de la maturité de votre équipe, tant sur le plan de la mise en œuvre de l'agilité que ne serait-ce même que de son fonctionnement en équipe (depuis combien de temps).

Si vous votre équipe a été récemment formée, ou qu'elle commence depuis peu l'agilité, il est conseillé d'être "jusqu-au-bout-iste", d'appliquer les règles avec zèle, et de découper les stories en tâches les plus petites possibles.

Et, à mesure que la dynamique d'équipe se met en place, à mesure que vous appréhendez les mécanismes agiles, vous pourrez prendre quelques raccourcis, et cela tant que les estimations resteront proches du réalisé. Cela vous permettra de raccourcir la durée de vos séances d'estimation, et donc de maximiser votre investissement. Car oui, le planning game est un investissement. Le taux horaire de chacun des participants multiplié par la durée de la séance est le coût. La liste des User Stories estimées au plus juste et ordonnées est le gain. Si nous passons deux jours à produire des estimations erronées, cela devient une perte !

La prochaine étape est de faire en sorte que les estimations soient tirées vers le bas. Par expérience, si on estime à trois jours une stories qui peut être faite sereinement en deux jours, il sera pris trois jours pour la réaliser. L'estimation correspondant exactement au réalisé, on pourrait croire que tout va pour le mieux dans le meilleur des mondes, alors qu'en fait le temps de réalisation n'est pas optimal ! L'entreprise perd donc de l'argent. J'y reviendrait plus tard.


Le Product Owner

D'autres points problématiques tournent autour du rôle de Product Owner :

  • Doit-il être mobilisé sur place pendant toute la durée du Planning Game ?
  • Est-ce que ca doit être le client ou est-ce que ca peut être quelqu'un d'autre ?

J'y reviendrait plus tard.


Règles

On pourrait donc résumer le planning en quelques règles qui permettent converger vers un bon fonctionnement :

  • Pas d'issue de plus de 4 jours
  • Il est interdit de donner une estimation si on ne sent pas capable de la tenir.
  • Donc, poser des questions pour pouvoir estimer.