À l’intérieur des jalons de fin et début de l’itération, on définit ce que l’on va y faire. Lors-que l’itération débute, les stories retenues sont détaillées, à leur tour, pour estimer les acti-vités à réaliser. Au sein d’une release, seule l’itération qui débute est planifiée en détail.
Il s’agit, à présent, lors d’une nouvelle réunion de planification (iteration ou sprint plan-ning meeting) avec l’ensemble de l’équipe et le représentant du client, de lister les activités techniques (par exemple, implémenter les composants techniques, faire de la persistance en base de données…), nécessaires pour réaliser les stories affectées à l’itération.
Généralement, dans une première partie de cette réunion, quelques heures sont consa-crées à la compréhension des attentes du client et à la définition des critères d’évalua-tion ; les stories sont décrites sur des fiches bristol que l’on peut s’échanger et compléter facilement ; ensuite, dans une deuxième partie, l’équipe détaille les travaux à réaliser, recense les activités et estime le temps nécessaire à leur réalisation en heures (ideal hours) ou en points.
Toutes les activités sont concernées : analyse, conception, développement, test, documenta-tion… indispensables à l’implémentation complète d’une fonctionnalité, potentiellement livrable (potentially shippable) à la fin de l’itération. Une fonctionnalité n’est considérée comme ache-vée (done) que lorsqu’elle a été validée par le client et documentée. On ne différencie pas ces différentes disciplines, intégrées, par essence, dans une activité.
Quel est le principe du jeu de poker ou planning poker ?
C’est le principe du planning game dans XP, adapté pour Scrum par Mike Cohna.
Lors d’une séance de « jeu de poker », toute l’équipe est réunie ; chaque participant se voit confier un jeu de cartes, qui comportent chacune une valeur : par exemple, 0, 1, 2, 3, 5, 8, 13, 20, 40 et 100. Ces valeurs correspondent au nombre de story points ou de ideal days qui seront affectés à une user story.
Une présentation de chaque user story est faite par le product owner à l’équipe, puis une discussion s’ensuit sur les détails de cette story. Chacun estime ensuite la taille de la story et présente une carte avec la valeur retenue correspondante. Les divergences d’estimation sont alors débattues et analysées jusqu’à ce qu’un consensus soit trouvé.
L’avantage est que cette démarche d’estimation est, elle aussi, consensuelle, conviviale, rapide, permettant à chacun de s’exprimer et de justifier son chiffre pour mieux s’engager ensuite.
NB : C’est encore la valeur relative qui est importante et non la valeur absolue.
Une équipe peut avoir recours à cette technique de « jeu » lors du lancement du projet (au cours de deux ou trois réunions de deux ou trois heures, par exemple), puis au moment de la planification d’une release ou d’une itération.
a. Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005.
Gestion de projet – Vers les méthodes agiles
136
Si le nombre total de points ainsi calculé correspond à la vélocité estimée de l’itération, l’équipe peut s’engager collectivement auprès du client sur le résultat à atteindre et l’achèvement des activités correspondantes.
À l’issue de cette réunion de planification, l’ensemble de l’équipe dispose d’un sprint ou iteration backlog, c’est-à-dire un sous-ensemble du product backlog initial qui ne comporte que les tâches des stories qui seront implémentées dans cette itération. Il résulte de la formalisation des échanges de la réunion qui ont souvent lieu autour d’un tableau blanc et de Post-it. Il est important de noter que dans le product backlog on liste des fonctionnalités, alors que dans le sprint ou iteration backlog, on bascule vers les acti-vités correspondant aux fonctionnalités implémentées.
La vélocité estimée par l’équipe, c’est-à-dire sa capacité à prendre en charge x points, est une vélocité cible hypothétique lors d’une première expérience ; ensuite, elle est basée sur la vélo-cité réelle constatée sur l’itération précédente ou une moyenne calculée sur la vélovélo-cité des itérations précédentes.
Il est à noter que ces activités ne sont pas nominatives.
Cas pratique
Poursuivons notre exemple avec le sprint backlog de notre projet, dérivé du product backlog initial (voir chapitre 3, figure 3-9). La figure 4-11 nous en présente un extrait.
Figure 4-11
Exemple d’un sprint backlog (extrait)
Dans notre exemple, les cas d’utilisation et les exigences de haut niveau ont été détaillés et les tâches correspondantes listées. On peut suivre l’avancement d’une tâche par son statut (colonne Statut) et voir si elle est démarrée, en cours de réalisation, achevée ou annulée. L’effort nécessaire a été estimé pour chaque activité ; il représente une charge globale de 30 jours ; l’itération durera neuf jours et le reste à faire sera réévalué chaque jour puis reporté dans la colonne correspondante.
Sprint Backlog
Indexation d'une portion de document source ND 3
Typage et enregistrement d'une indexation ND 0,5
Suppression d'une indexation ND 1
Création d'un nouveau terme de référence ND 2
Typage d'un terme de référence ND 0,5
Association de synonymes à un terme de référence ND 1
Suppression de synonymes ou termes de référence ND 1
Ajouter une remarque éditoriale ND 2
Modifier les paramètres d'une remarque éditoriale ND 0,5
Modifier et versionner une remarque éditoriale ND 1
Interface de connexion des composants applicatifs ND 4
Intégration "to do list" ND 3
Gestion de l'authentification ND 3
Gestion des menus dynamiques ND 2
Paramétrage des recherches ND 3
Paramétrage des raccourcis clavier ND 2,5
Bureau métier Caractéristiques produit
Reste à faire estimé
Planifier son projet
CHAPITRE 4
137
Le tableau blanc et les Post-it : cela fait un peu artisanal, alors qu’il existe de nombreux outils de planification !
1) La réponse du coach Pascal Pratmarty, consultant indépendant et ingénieur expérimenté en développement logiciel.
Je ne pense pas qu’il y ait une quelconque opposition entre les outils « moder nes » de planifi-cation et les supports d’information tangibles tels que le tableau blanc ou les Post-it.
Les murs offrent un espace de partage, d’échange et de rassemblement autour des activités courantes ou à très court terme :
– L’accessibilité d’un tableau de bord permet à l’équipe de sentir l’avancement concret dans l’itération et de décider des priorités.
– Les techniques de brainstorming (comme le mind-mapping) sur tableau blanc libèrent un réel potentiel de créativité dans une équipe.
– Les Post-it se révèlent d’excellents supports dans le quotidien pour alimenter un « radiateur d’information » (renforcé par une convention sur les couleurs à utiliser, en fonction de la nature et/ou la priorité).
Selon mon expérience, les outils informatiques sont très complémentaires, en offrant de bons moyens logistiques pour la traçabilité du projet et la planification à moyen terme.
L’essentiel reste pour chaque équipe de construire et faire vivre le système qu’elle juge le plus simple et efficace en utilisation quotidienne.
2) La réponse de Dominic Williams, coach XP.
En effet, et il faut l’assumer. Tout l’enjeu de ces techniques est de changer radicalement d’atti-tude face à la planification. La planification ne doit pas être si complexe qu’on a besoin de la puissance de calcul d’un ordinateur pour la gérer. Le plan ne doit pas être si sacré qu’on a besoin d’une sauvegarde électronique. La planification ne doit pas se faire seul face à un écran et tournant de fait le dos aux autres personnes de l’équipe, ni même avec un « maître » qui manipule l’outil pendant que les autres regardent ce qu’affiche un vidéoprojecteur. Enfin, le plan ne doit pas être oublié aussitôt qu’il est fait ou mis à jour.
Le côté artisanal de ces outils sert donc à créer les conditions nécessaires à une planification simple, rapide, collective, qui reflète la réalité et qui reste à tout moment affichée aux yeux de l’équipe et de tout visiteur.
Le besoin légitime de communiquer ce plan au-delà de l’équipe et/ou sous une forme plus traditionnelle ne justifie pas d’abandonner les tableaux, fiches et Post-it. Il faut simplement prendre le temps supplémentaire pour retranscrire le plan au format demandé.
3) La réponse de Jean Tabaka, agile coach, Rally Software Development, Colorado.
Les petites équipes agiles (moins de 10 personnes) qui travaillent en un même lieu avec une vraie accessibilité peuvent tirer profit des outils de communication très simples. Alistair Cockburn fait référence à la « communication osmotique » lorsqu’il met en avant les valeurs des équipes qui sont très proches et qui s’appuient sur des outils simples de comm unication.
Les équipes sont plus transparentes lorsqu’elles se parlent en face à face que quand elles s’échangent l’information dans des e-mails ou des documents. En plus, cela prend moins de temps pour les collaborateurs de partager leurs informations s’ils sont tous devant un tableau blanc. Déplacer les Post-it favorise la circulation rapide des idées, soit pour prioriser ou pour classer ou encore ordonnancer.
☞
Gestion de projet – Vers les méthodes agiles
138
Avec le backlog de l’itération, l’équipe a son « plan de route » et peut ainsi démarrer les travaux.
Voici un exemple (figure 4-12) d’une petite équipe sur site qui a tiré profit du tableau blanc et des Post-it durant une réunion de planification d’une release.
Le product owner, le scrumMaster, les développeurs et les testeurs s’attachent tous à définir les items, à les déplacer, tout en discutant. Ils s’appuient sur leurs hypo-thèses et les idées qu’ils débattent plutôt que sur un document écrit une semaine auparavant qui n’est peut-être plus valable ou fidèle aux attentes du client.
En même temps, l’équipe utilise des outils pour enregistrer électroniquement ses décisions. Des outils de planification
spéci-fiques pour les projets agiles, comme les outils Rally, aident l’équipe à enregistrer ses conversa-tions et consolider l’information quotidienne sur l’état des items dans le product backlog, le burndown chart, le reste à faire pour tous les items qui sont planifiés et la charge de travail de chaque membre de l’équipe.
Les équipes qui sont délocalisées doivent quant à elles davantage s’appuyer sur ce genre d’outils, même pour leurs réunions de planification. Par exemple, une équipe en Californie, à Sunnyvale, construit son plan d’itération en réunissant tous ses membres devant le tableau blanc avec des Post-it. Lorsqu’elle a terminé son travail de recensement des tâches et d’esti-mation, l’équipe enregistre l’information dans un outil de collaboration en ligne. Ensuite, une équipe de Bangalore, en Inde, est en mesure de prendre connaissance du travail de l’équipe de Sunnyvale et d’ajouter ses propres tâches et ses estimations. Les collaborateurs peuvent aussi partager leurs préoccupations ou autres problèmes. Ils peuvent le faire après avoir, eux aussi, utilisé leur propre tableau blanc et des Post-it, et enregistré leurs décisions dans l’outil de partage.
Dans ce cas, les deux types d’outils sont complémentaires. L’un ne remplace pas l’autre ; mais les deux sont là pour aider l’équipe à agir de façon collaborative et sans gaspillage.
Voici un autre exemple (figure 4-13) d’une réunion de planification de release lors de laquelle quatre équipes doivent coordonner leurs plans. Elles ont recours au tableau et aux Post-it tout en utilisant leur outil élec-tronique en ligne pour avoir accès à un maximum d’information disponible avec la plus grande interactivité et la meilleure colla-boration.
Planifier son projet
CHAPITRE 4