BLog posts

La planification d'un projet de développement informatique est une étape critique, car elle va globalement fixer les différentes tâches à accomplir, et une date prévisionnelle de fin de projet. À la base de toute planification se trouve l'évaluation de la durée ou de la complexité de réalisation des tâches identifiées dans le projet.

Les méthodes traditionnelles reposent généralement sur une estimation « à la louche ». Ce n'est pas sans raison qu'il est difficile de réaliser une estimation fiable et que 25% des projets informatiques prennent du retard.

L'utilisation d'une méthode agile d'estimation des temps de développement conduit non pas à un chiffrage exact, ce qui est irréalisable, mais à une valeur plutôt fiable par rapport à d'autres méthodes, et surtout, qu'il est possible de corriger au fur et à mesure de l'avancement.

Estimation des temps de développement agile

Les inconvénients du rétro-planning

Il est encore trop courant de voir la constitution d'un rétro-planning élevée au rang de méthode sûre pour l'estimation des temps de développement. Rappelons que généralement, la construction d'un rétro-planning consiste à :

identifier toutes les tâches d'un projet,

les prioriser,

les estimer grossièrement (souvent en heures ou en jours/homme)

et essayer de toutes les faire tenir dans un planning en partant de la date de livraison jusqu'à la date de démarrage du projet.

Il est presque certain que l'estimation des temps de développement sera erronée, car elle est biaisée par l'obligation de respecter une date de fin de projet. Le résultat risque d'être catastrophique, parce que la variable d'ajustement en cours de projet sera bien souvent le temps de réalisation qui sera revu à la baisse (alors qu'il y avait déjà une marge d'erreur non négligeable dans l'évaluation), et non les ressources fournir pour respecter les délais. Il en découlera immanquablement une surcharge de travail des équipes et une démotivation à plus ou moins long terme, avec tous les problèmes de turn-over et de perte de connaissances du projet que cela engendrera.

Le planning poker agile

Une estimation agile des temps de développement sera très différente. Pour commencer, elle ne sera pas exprimée en heures ou en jours/homme, mais en points de complexité. Il est en effet très difficile, voire illusoire d'espérer estimer précisément une tâche en heures au-delà d'une journée. Il est généralement possible de dire qu'une tâche peut être réalisée en 2, 4, 6 ou 8 heures, mais au-delà, c'est très risqué.

Avec une méthode agile, on utilisera souvent la technique du planning poker. Cette réunion, qui ne devra pas durer plus d'une demi-journée (entre deux et trois heures grand maximum) va réunir l'ensemble de l'équipe de développement, accompagnée du product owner qui pourra apporter certains éclairages sur les demandes du client et sur les priorités de réalisation. Chaque fonctionnalité demandée est passée en revue et les participants peuvent poser des questions et demander des précisions. Chacun peut décider du nombre de points qu'il souhaite attribuer et toutes les estimations sont révélées au même moment (comme au poker). Si la même estimation ressort, elle est conservée. S'il y a de trop grandes différences, à leur tour, les intervenants pourront expliquer comment ils sont arrivés à cette estimation. Il est alors possible de faire un second tour afin d'obtenir une estimation approuvée par le plus grand nombre.

Typiquement, lors d'un planning poker, les valeurs utilisées pour estimer la réalisation d'une tâche sont non linéaires et suivent la suite de Fibonacci : 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, « ? » et infini. Plus la valeur est petite et moins la tâche sera complexe et longue à réaliser. Si l'on obtient des valeurs trop élevées, ou qu'il est impossible de réaliser une estimation, c'est généralement parce que la tâche est trop complexe et qu'elle devra être découpée en sous-éléments qui feront alors chacun l'objet d'une estimation à part.

Au fur et à mesure de l'avancement des itérations, il sera possible d'estimer de façon relativement fiable la valeur de l'effort qu'est capable de réaliser l'équipe de développement (appelée aussi vélocité, exprimée en nombre de points), et par conséquent, de savoir quelles fonctionnalités pourront être intégrées à l'itération suivante.

Méthode simplifiée d'estimation des temps de développement

L'exercice du planning poker n'est pas toujours simple à réaliser, surtout pour une équipe débutante. Dans ce cas, il peut être intéressant d'utiliser une autre méthode que les points pour les estimations. Chaque développeur devra simplement dire si la fonctionnalité étudiée lui prendrait:

moins de deux heures,

moins de deux jours

ou moins de deux semaines à réaliser complètement.

Cela permet d'obtenir une estimation assez large. Toutes les tâches identifiées comme prenant de plus de deux jours à plus de deux semaines devraient être redécoupées. Lorsque l'équipe sera plus expérimentée, il sera possible d'utiliser la méthode classique des points.

Les principales erreurs à éviter

1- Une séance trop longue

La première erreur à éviter est de vouloir trop en faire. Inutile de vouloir absolument estimer l'ensemble des fonctionnalités présentes dans le backlog produit. Mieux vaut prévoir plusieurs séances d'estimation des temps de développement agile plutôt que d'épuiser l'équipe dans des réunions interminables. Quoi qu'il arrive, l'attention baisse au bout d'une heure, et la fatigue est suffisante au bout de deux heures pour que la réunion perde de son efficacité. Le planning poker aura lieu de préférence le matin lorsque tout le monde est reposé et surtout pas en début d'après-midi durant la digestion.

2- Se limiter aux fonctionnalités courantes

S'il ne faut pas faire trop long, il ne faut pas faire trop court non plus. Il ne faut pas arrêter le planning poker parce que les fonctionnalités estimées atteignent la vélocité de l'équipe. Il est important de conserver un stock de fonctionnalités estimées, même si elles ne rentreront pas dans la prochaine itération. D'une part, le product owner peut choisir de modifier les priorités de réalisation en fonction des estimations, et d'autre part, il faut connaître les points attribués à un maximum de fonctionnalités de façon à pouvoir les inclure dans l'itération courante si les développements vont plus vite que prévu ou qu'une nouvelle contrainte entraîne la modification des priorités.

3- Considérer une estimation juste

L'une des plus grosses erreurs à éviter est de penser qu'une estimation est forcément juste. Une estimation reste ce qu'elle est et il est possible que des contraintes qui n'avaient pas été identifiées jusque-là ou qu'un changement de priorisation entraîne la réévaluation d'un chiffrage (souvent à la hausse, plus rarement à la baisse).

4- Une mauvaise communication

Pour que le planning poker soit productif, il faut que chacun puisse s'exprimer librement. L'animateur de la réunion (généralement le scrum master) devra donc veiller au respect des temps de parole et encourager ceux pour lesquels la prise de parole en public n'est pas naturelle à participer activement.

5- Des fonctionnalités mal définies

Il faut que les fonctionnalités passées en revue soient claires. Si une fonctionnalité nécessite une longue explication, c'est généralement qu'elle a été mal pensée dès le départ. Dans ce cas, mieux vaut la mettre de côté et la retravailler, il ne sera pas possible d'obtenir une estimation fiable si tout le monde ne la comprend pas de la même manière.

6- Mal définir la fonctionnalité de référence

L'estimation des temps de développement agile par points nécessite de procéder à partir de repère. C'est-à-dire qu'une fonctionnalité, parfaitement connue de toute l'équipe, va servir d'étalon. C'est à partir d'elle que seront estimées toutes les autres. Il est donc important de définir des fonctionnalités de référence, de plusieurs tailles différentes, représentatives de celle que l'on peut trouver dans le projet et surtout, et de ne pas en changer à chaque itération. Ce n'est qu'en conservant les mêmes références tout au long du projet qu'il sera possible d'obtenir des estimations fiables et stables.

7- Utiliser les heures/homme au lieu des points

Enfin, il peut être tentant pour les équipes plus habituées à utiliser des méthodes classiques et qui découvrent les méthodes agiles d'essayer de convertir les points en heures ou en jours/homme. Les points représentent à la fois la complexité d'une fonctionnalité et l'effort à fournir pour la réaliser. Ils n'ont pas d'unité. Il n'y a pas de conversion possible et toute tentative sera irrémédiablement vouée à l'échec.

Pour conclure sur l'estimation des temps de développement agile

Vous l'aurez compris, l'estimation des temps de développement agile est plus fiable qu'avec une méthode classique, car elle ne tient compte que de la complexité et de l'effort à fournir et non d'une date de livraison figée. L'estimation est directement réalisée par l'équipe de développement en collaboration avec le product owner, qui a la connaissance du métier du client. Cette estimation engage donc l'équipe de développement qui en prend la responsabilité, ce qui entraîne également une plus grande implication de ses membres.

L'outil de gestion de projet en ligne Nutcache fournit tout ce dont vous avez besoin pour organiser et mener à bien un planning poker. N'hésitez pas à tester gratuitement la solution complète durant 14 jours.