De l’estimation agile

Les estimations projets

Ma propre expérience

A la base de toute planification projet, il y a les estimations. Or estimer les charges et durées d’un projet informatique complexe à l’aide des méthodologies traditionnelles implique souvent une part importante de « A vue de nez », « à la boule de cristal », et autres techniques de magie noire, reposant au final essentiellement sur l’expérience du chef de projet à qui l’on confie généralement cette tâche.

Malgré cet état de fait, j’ai passé une grande partie de ma carrière à me confronter à ce type d’exercice, en tant que développeur, consultant, chef de projets, etc…

Rarement satisfait des résultats, au fil des ans, j’ai essayé d’affiner mes techniques pour rendre mes estimations plus efficaces.

• Tout d’abord de manière empirique, en consolidant l’historique des informations des projets passés, en les comparant aux données actuelles et en constituant des abaques
• Puis par des méthodes de modélisation standardisées tels que Cocomo ou encore par les « points de fonctions ».
• Enfin, je me suis posé des questions quant à l’utilisation de l’astrologie ou du vaudou…

Mon bilan…

Mais malgré tous mes efforts, une grande partie de mes estimations se révélaient inexactes :

• Soit la réalisation d’une fonction donnée prenait plus de temps qu’estimé initialement (dépassement de délai ou de charge)
• Soit pour terminer dans les temps, la fonction était amputée de certaines caractéristiques (réduction de périmètre)
• Soit la qualité de la livraison était inférieure à un certain seuil, générant des coûts de maintenance très élevés et de graves problèmes une fois en production.

En clair, je ne parvenais que très rarement à intégrer l’ensemble des facteurs coûts, périmètre et qualité.

Vous pourriez légitimement vous dire que je ne suis simplement pas compétent… Après tout, c’est possible, et par ailleurs, un peu de remise en cause ne fait pas de mal. Mais alors :

• Serais-je le seul à rencontrer ces difficultés ?
• Quand pour la dernière fois avez-vous vu un diagramme de Gantt se révéler juste sur la durée d’un projet… ?

Elargissons quelque peu notre horizon et allons voir ailleurs…

Quelques constats

« 25% des projets sont en retard »

Selon l’étude barométrique sur les entreprises et la gestion de leurs projets en France, les entreprises françaises sont majoritairement passées « en mode projet »

Cependant, malgré l’implication des Directions Générales, les entreprises ont beaucoup de mal à respecter leurs plannings prévisionnels. Les projets dérapent. Ce baromètre met en évidence des tensions importantes dans les entreprises et des objectifs parfois divergents, entre les exigences opérationnelles quotidiennes et le besoin de se projeter dans le futur.

Le taux de projets « terminés » dans les temps n’est par ailleurs pas tout à fait équitablement réparti :

• 65% des projets inférieurs à 3 mois
• 72% des projets de 3 à 6 mois
• 80% des projets de 6 à 12 mois

Cette disparité observée est assez naturelle, et peut s’expliquer par plusieurs facteurs, notamment :

• L’impact relatif des retards étant mathématiquement plus important sur les projets les plus courts.
• La marge de manœuvre et la capacité de réaction des équipes étant généralement plus importante sur les « grands » projets.
  

Ce que cachent ces chiffres

25% de retards, après tout ce n’est peut-être pas si mal. Mais en ne tenant compte que de la date de fin du projet comme axe d’observation, ces chiffres masquent souvent d’autres réalités moins avouables :

• Le périmètre initial n’a souvent pas été totalement tenu, car pour livrer, des arbitrages fonctionnels ont dû être réalisés à la dernière minute et des fonctionnalités essentielles sont manquantes, alors que certaines fonctionnalités moins utiles sont déjà intégrées dans le produit.
• L’équipe a livré le projet à temps, mis au prix d’efforts non soutenables dans la durée, ce qui génère une démotivation et un turnover important. Les coûts de la maintenance du projet n’en seront que plus élevés puisqu’il faudra y intégrer plus tard les coûts de montée en compétences fonctionnelles et techniques des nouveaux membres de l’équipe.
• Pour tenir les délais, le projet a été livré avec un niveau de qualité faible. Le ROI du projet finira par s’écrouler sous le poids d’une dette technique non remboursable.

Lorsque l’on rentre dans le détail de l’étude, les principales raisons des retards exprimés par les Clients sont :

• Le manque de compétences avérées ou disponibles
• Le manque de méthode sur les principes de planification

En prenant un peu de recul, on pourrait par ailleurs compléter cette liste avec notamment les manques :

• D’implication des utilisateurs
• De support du management
• De clarté dans les objectifs métiers
• …
  

Des problèmes connus, des causes identifiées… mais aucune réponse ?

Les stratégies cachées des chiffrages commerciaux

Dans le cas de chiffrages effectués par un prestataire dans le cadre d’un appel d’offre, on pourrait estimer que le chiffrage est réalisé sur la base stricte du cahier des charges. Mais comment expliquer les disparités observées ?

Tout simplement par l’intention de celui qui porte l’estimation. Ainsi, pour des raisons de tactique commerciales ou d’organisation interne, les chiffrages peuvent revêtir différentes apparences :

• Répulsif : Le prestataire ne souhaite pas répondre mais il y est contraint, il va donc chercher à perdre. Par exemple car c’est un Client important pour lui et qu’il ne peut pas, ne pas  répondre, ou alors il ne dispose pas des ressources compétentes ou disponibles pour réaliser le projet, ou encore le cahier des charges est trop flou et le projet semble donc trop risqué pour prendre un engagement.
• Séduction : Le prestataire va chercher à « acheter » la référence quitte à perdre de l’argent. En cas de victoire, les projets suivants vont être très coûteux pour le Client puisque son prestataire sera obligé de se rattraper, directement sur le prochain chiffrage, ou indirectement en « sortant le carnet à avenants »…
• Ceinture / bretelle : Généralement généré par un cahier des charges imprécis, ou impliquant une prise de risques et de responsabilité importante pour le prestataire, le chiffrage sera « margé » à tous les étage et l’ensemble des charges surévaluées
• Expéditif : Le prestataire n’a tout simplement pas eu le temps d’analyser et de faire chiffrer le projet, une estimation plus qu’approximative est formulée
• Juste : C’est le chiffrage idéal, honnête, ayant anticipé les risques, intégré des marges de sécurité raisonnables… bref un fantasme…

A noter aussi une tendance courante dans le secteur des SSII, celle d’accepter de négocier avec le Client sur les charges, plutôt que d’accepter une remise commerciale qui impacterait trop fortement les primes…

Des facteurs humains qui brouillent les cartes

Mais alors que l’on parvient à comprendre par des logiques commerciales, pour des externes, les disparités de chiffrages et les facteurs commerciaux qui les influencent, on doit aussi tenir compte d’autres facteurs, psychologiques ou sociologiques, lorsque le chiffrage est réalisé par un interne :

• Trop souvent, le chiffrage réalisé par un développeur est perçu comme un engagement plutôt qu’une hypothèse à réévaluer dans la durée. Cette perception conduit à une tendance naturelle à la surévaluation.
• A l’inverse, la peur d’être perçu comme incompétent conduit souvent les moins expérimentés à une sous-évaluation des charges estimées, pour une simple question d’image professionnelle.
• Estimer en heures une tâche de plus d’une journée est une tâche humainement complexe
• Lorsqu’on estime un projet sur la base d’une spécification très détaillée, nous avons une tendance naturelle à utiliser des durées « atomiques », insécables, à savoir ½ ou 1 journée, pour chaque besoin formulé.

Ce que j’ai appris sur les estimations grâce aux méthodes agiles

Des hypothèses fausses ou inexactes dès le départ

Les méthodes classiques, dites « cycle en V » ou « Waterfall », reposent sur un certain nombre de postulats et postures :

• Plus le projet est spécifié en détail, plus le chiffrage réalisé sera proche de la réalité
• Planifier le travail, travailler selon le Plan
• Piloter l’avancement par rapport au Plan (effort/RAF)
• Contrôle centralisé
• Contraindre le changement
• Segmentation des responsabilités
• Fige les choix structurants tôt

Cela revient souvent à essayer de viser une cible en mouvement, sans tenir compte de ses éventuels changements de trajectoire.

Des projets compliqués et complexes ?

Les projets informatiques sont généralement compliqués (au sens mathématique), c’est à dire reposant sur un grand nombre de paramètres. Mais ils sont surtout complexes, c’est à dire qu’une variation infime d’un de ces paramètres, très imbriqués entre eux, a une influence relative très importante sur l’ensemble du système (du projet en l’occurrence).

Les principes de développement agiles embrassent ces réalités, et reposent sur les postulats suivants :

• La trajectoire du projet peut évoluer et est donc non prédictible
• L’apprentissage provient de l’expérimentation
• Amélioration continue
• Tolérance au changement
• Repousser les décisions irréversibles au plus tard pour conserver un maximum d’options
• Utiliser des Best Practices comme point de départ

En somme, l’agilité repose sur des principes similaires à ceux d’un missile, à savoir décoller puis ajuster sa propre trajectoire à chaque changement de trajectoire de la cible.

Le cône d’incertitude

Le cône d’incertitude est un terme de gestion de projets visant à décrire les différents niveaux d’incertitude rencontrés lors des différentes phases d’un projet.

En résumé, nos estimations deviennent plus sûres et fiables à mesure que la connaissance du sujet à estimer augmente.

Comment connaître à l’avance quelque chose que l’on n’a jamais fait ? (Ca a l’air tellement évident une fois présenté comme ça…)

C’est toute la philosophie de l’agilité qui se cache derrière ce simple constat.

• Afin de réduire l’incertitude sur les phases d’intégration, on pratique l’intégration continue pour s’y confronter le plus tôt et le plus souvent possible.
• Même logique pour les pratiques de TDD qui visent à pratiquer les tests, et intégrer la qualité, tout au long du processus de développement.

Les unités de chiffrage

Partant de là, afin de limiter les efforts conduisant à des estimations fausses, il convient de réduire la précision des estimations relativement à ce qui est connu sur le système à estimer.

Or dans un projet agile, les estimations portent sur différents niveaux d’exigence, nous utiliserons donc différentes unités, de précision différentes, adaptées à chacun de ces niveaux :

L’estimation en heures, plus besoin de la présenter, mais il convient de noter qu’elle ne sera utilisée que pour les estimations de tâches, qui elle mêmes ne devraient pas dépasser une journée.

L’estimation en story points est généralement recommandée pour les User Stories et parfois pour les Epics, et repose généralement sur la suite de fibonacci : 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…

L’estimation par les tailles de T-shirts est utilisée pour les exigences de plus haut niveau d’abstraction, comme les Epics ou parfois les User Stories importantes ou encore mal définies. Elle repose sur une suite semblable à celle-ci : XS, S, M, L, XL…

Pourquoi utiliser la technique d’estimation en points ?

Comme je l’ai déjà mentionné précédemment, estimer en heures une tâche de plus d’une journée est une tâche complexe.

On me demande souvent lors de formations ou de séances de coaching pourquoi on n’utilise pas simplement une estimation en heures.

Je demande alors aux personnes présentes de me dire, à tour de rôle, depuis combien de temps la session de formation a débuté sans regarder leur montre… Et là c’est le drame… Les estimations varient du tout au tout, et ce n’est pas un hasard.

Tout comme dans la théorie de la relativité d’Einstein, pour notre cerveau, le temps est une question de point de vue, de référentiel.

On peut tous le constater à la sortie d’un cinéma, le film vous aura paru plus ou moins long selon votre intérêt pour le film.

Les estimations en points sont donc une mesure strictement relative de la complexité, s’appuyant sur une référence invariante. La variabilité naturelle des estimations étant compensée sur le nombre de User Stories.

L’estimation en points permet donc de prendre en compte certains facteurs que vous ressentez, mais intangibles ou non mesurables en heures, comme la complexité.

Les points d’attention

Les techniques de chiffrages en groupe comme les plannings Poker sont désormais bien acceptées, et leur efficacité démontrée par la pratique. Ceci étant, l’ensemble de ce processus reposant sur une évaluation en points, plusieurs points d’attention  sont donc à prendre en considération :

• Veiller au maintien de la story de référence
• Tenir compte de l’impact de la progression de l’équipe quant à son évaluation de la complexité
• Réévaluer régulièrement le product backlog afin d’en suivre la variation

Par ailleurs, il faut veiller à ne pas être tenté de systématiquement chercher une correspondance directe entre charge et complexité. Ainsi, un développeur pourra estimer deux tâches respectivement 1 et 4 points de complexité et constater des charges respectives de 1 et 10 jours. Rien de surprenant car au final, ce qui croît proportionnellement avec la complexité, ce n’est pas la charge, mais bien l’incertitude de l’estimation.

Du courage…

« je ne sais  qu’une chose , c’est que je ne sais rien » disait courageusement Socrate.

Cette acceptation courageuse du principe d’incertitude par les méthodes agiles, repose sur :

• Au niveau macroscopique, le principe agile de faire « un peu de tout tout le temps » permet aux équipes de se confronter aux problèmes à venir très tôt dans le projet. On reproche d’ailleurs souvent à tort aux méthodes agiles un « surcoût » de charges de travail au début du projet, sans tenir compte des économies réalisées en fin de projet…
• Au niveau microscopique, une définition du « Done » très complète fournit une vision beaucoup plus réaliste des charges par unité d’œuvre. C’est à mon sens le point d’amélioration premier de l’agilité, permettre une évaluation complète des tâches, en y intégrant les différentes composantes du développement logiciel (Conception, tests, développements, refactoring, intégration…)

C’est ainsi, en améliorant le processus d’estimation, et en le rendant dynamique, que l’agilité améliore la capacité des équipes à planifier les projets, ou à reprendre en main des projets dont on a perdu la maîtrise.