Comment faire pour chiffrer un projet sans se tromper ? DSI de Banque Robeco, Florence Arizzi, toujours à l’affût de solutions efficaces, simplifiées et novatrices, incite largement ses équipes à, sans cesse, s’enquérir des toutes dernières innovations en matière de méthodologie.
L’un de ses collaborateurs, Grégory Ganeau, responsable des études et du développement, auteur de cet article, fait la démonstration de l’efficacité de l’approche Planning Poker (*). Résultat : tout le monde est en phase sur le chiffrage d’un projet…
Depuis plusieurs années, nous estimons naturellement la charge de nos projets en jours-hommes. Pour cela, nous nous basons sur notre expérience et/ou nous appuyons sur celles d’experts du domaine concerné.
Ces estimations se sont généralement révélées fausses, de façon si systématique que les quelques fois où l’on était proche du résultat, cela ressemblait plus à un coup de chance qu’à l’aboutissement d’une réflexion bien menée. Nous avons finalement trouvé un nom, issu de la mythologie sino-japonaise, à cette méthode : la méthode « Koudpo ».
Les principes de la méthode Koudpo, pratiquée depuis de longues années chez Robeco, et dans nombre de DSI, sont les suivants :
- Les spécifications sont suffisamment précises et bien pensées pour être appliquées à la lettre, et tout est réalisé comme cela était prévu.
- Les développeurs étant tous strictement identiques en tout point de vue, un jour-homme de l’un vaut un jour-homme de l’autre. Par conséquent, en partant du principe que tout se déroule comme prévu, le chiffrage de départ est définitif.
- L’estimation est faite en jours-hommes, avec l’hypothèse qu’il s’agit de jours idéaux : ainsi, les journées sont d’égale durée et le développeur ne travaille que sur une tâche. Il n’est jamais dérangé et dispose toujours, sous la main, de toutes les informations nécessaires et suffisantes à l’accomplissement de sa tâche. Il ne fume pas, ne fréquente pas la machine à café et son régime alimentaire lui permet de rester concentré de manière égale tout au long de la journée.
- Disciple du magicien Gérard Majax, celui qui fait l’estimation s’appuie sur le passé pour prédire l’avenir. Ce qui est normal, dans la mesure où, comme les individus ne changent pas, les projets non plus, l’environnement non plus…
Cela prête à sourire, mais représente cependant les bases sur lesquelles nous appuyons nos estimations. Ce qui explique les écarts constatés entre le prévisionnel (présenté comme tel, mais considéré comme définitif par la hiérarchie) et la réalité.
Les méthodes agiles proposent une autre approche, avec des éléments intéressants. Concernant l’estimation, elle n’est pas réalisée en jours-hommes mais en points. Prenons l’exemple d’une fonctionnalité estimée à deux jours-hommes par le chef de projet : dans la réalité, elle sera réalisée en trois jours-hommes par un junior s’il s’y attelle en début de projet.
Le même junior la réalisera en 1,5 jour-homme en fin de projet, car il aura acquis plus de maîtrise du contexte fonctionnel et technique. Pour la même fonction, un développeur plus expérimenté y consacrera deux jours-hommes (un jour-homme pour développer et un autre pour tester toutes les possibilités et mettre à jour sa documentation… ce qu’oubliera le junior !).
Pourtant, la quantité de travail reste la même, quelle que soit la personne et quel que soit le moment.
Donc, avec une approche agile, on chiffre en points et de façon relative. Ainsi, une fonction qui coûte deux points nécessitera deux fois plus de travail qu’une fonction qui coûte un point. Un scénario simple est pris comme « mesure étalon » et chaque scénario est donc estimé en fonction des autres. Le chiffrage d’un scénario n’est revu que si son périmètre change.
Le développement est réalisé par « sprint » : on définit un nombre de jours suffisamment important pour pouvoir réaliser quelques scénarios, mais pas trop afin d’éviter toute dérive. Dans l’idéal, deux semaines de délai, soit dix jours.
Ensuite, le coût en jours-hommes est calculé en mesurant la vélocité de l’équipe à la fin de chaque sprint. Exemple : la charge consommée pour le sprint est de vingt jours et l’on constate que l’on a réalisé dix-huit points, la vélocité de l’équipe est donc de 0,9 point/jour. Ce ratio nous permet de définir le coût global du projet en jours-hommes. Il sera réévalué après chaque sprint ce qui permettra d’affiner le chiffrage global.
La première étape de l’estimation consiste donc à organiser une réunion de planification afin de donner des « poids » en points pour le développement de chaque scénario. Lors de la réunion, le « product owner » (directeur de produit) représente l’utilisateur.
L’équipe a pour responsabilité de lui donner des quantifications afin qu’il sache que telle fonctionnalité coûte dix unités et qu’une autre fonctionnalité ne coûtera que deux unités. À noter que nous ne parlons pas de jours-hommes pour l’instant.
Et c’est là qu’intervient le Planning Poker. Mettons-nous en situation.
Vous réunissez votre équipe de cinq développeurs dans une salle. Vous demandez à tout le monde « combien de temps pour développer le scénario X ? ».
Monsieur A pense qu’il sait exactement ce qu’il faut faire, donc il pense que trois jours sont nécessaires. Monsieur B et Monsieur C sont plus prudents. Messieurs D et E ne participent pas activement à la conversation et n’écoutent pas.
Bref, c’est Monsieur A qui prend la parole et qui vous répond : « Je pense que trois jours sont nécessaires. »
L’équipe est influencée par la première personne qui s’exprime. C’est un risque important, car en fait on voit que B et C pensaient que cette fonction demanderait davantage de temps à développer. Ainsi, B et C réduisent largement leur estimation tandis que D et E s’alignent tout simplement sur A.
Nous risquons de perdre de l’information ici et leurs doutes doivent être exprimés.
Reprenons la même scène avec le Planning Poker.
Le principe est de donner à chacun de vos équipiers un jeu de cartes spécial. Vous distribuez un jeu complet à chacun de vos équipiers.
Les cartes ne se suivent pas, elles sont basées en partie sur la « suite de Fibonacci », dont le principe est qu’un terme de la suite est la somme des deux précédents (0, 1, 1, 2, 3, 5, 8, 13, 21 …). Cette approche présente trois avantages :
- accélérer le processus de chiffrage en limitant les possibilités ;
- éviter de rechercher inutilement la précision sur les estimations les plus élevées ;
- encourager l’équipe à découper les scénarios les plus conséquents en scénarios plus simples.
Une estimation importante (supérieure à 20 par exemple) signifie souvent que le scénario n’est pas maîtrisé ou mal compris. Il est inutile de perdre du temps afin de savoir s’il coûte 19, 20 ou 25 points, il s’agit simplement d’un scénario lourd à réaliser et le fait de choisir 21 suffit à s’en rendre compte. Dans ce cas, le scénario devra être « découpé » en scénarios plus petits.
L’unité n’est pas le nombre de jours-hommes, mais le nombre de points. Il est important de donner un jeu à chaque personne de l´équipe. Ensuite, la séance se déroule de la manière suivante : une personne détaille le scénario, et l’équipe lui pose des questions afin d’affiner la demande pendant environ trois minutes. Puis la phase du vote commence. Chacun prend une des cartes et la pose devant lui face cachée.
Cette fois, chacun pense librement et activement. Monsieur D et Monsieur E sont également obligés de participer. Lorsque que chacun a sélectionné une de ses cartes, on retourne toutes les cartes en même temps et le résultat du premier vote est discuté par l’équipe.
On observe qu’entre Monsieur A et Monsieur C, une discussion s’impose à propos du scénario. Après quelques discussions, Monsieur A réalise qu’il a oublié une partie du développement et qu’il faut l’inclure. Monsieur C réalise qu’avec la proposition de Monsieur A, en effet, il est possible de réaliser plus rapidement la fonction et que, par conséquent, son estimation est un peu trop pessimiste.
Après trois minutes, chaque membre de l’équipe propose une nouvelle estimation, en reprenant sa carte et en sélectionnant une nouvelle carte, ou la même s’il n’a pas changé d’avis.
Voilà maintenant un chiffrage réaliste et réalisable de la demande initiale. Plus important, les développeurs ont largement partagé leur vision de la solution envisagée, quel que soit leur domaine de compétence. Et tout le monde y a participé. Ce qui est aussi efficace en termes d’échanges et de communications.
Dans le Planning Poker, il existe quelques cartes spéciales :
- la carte « ? » représente le fait que vous n’avez vraiment aucune idée sur la question ;
- la carte « tasse de café » est le joker pour signaler que vous voulez faire un break.
Cette méthode a été utilisée la première fois chez Robeco pour le chiffrage des deux premiers sprints d’une application. La « mayonnaise » a plutôt bien pris et tout le monde a participé activement au chiffrage, quel que soit son domaine de compétence. Autre point positif, tout le monde était en phase sur le chiffrage !
Cet article a été écrit par Grégory Ganeau, responsable des études et développement, Banque Robeco.