Les estimations sont-elles critiques pour le business ?

Grâce à mon premier article, j’ai eu la chance d’avoir des discussions très intéressantes avec certains collègues.

L’une des principales préoccupations concernait l’aspect obligatoire des estimations dans certaines situations, principalement pour arbitrer entre deux projets.

Tout d’abord, permettez-moi de clarifier ma pensée sur les estimations. Pour fournir une estimation fiable, les critères suivants doivent être réunis :

• L’équipe doit se connaître parfaitement, sachant précisément quelles sont les forces et faiblesses de chaque membre.
• Le codebase de l’équipe doit être soit vierge, soit sans défauts.
• Le produit doit être entièrement identifié et spécifié, et le Product Owner, en tant qu’expert du domaine, doit être sûr à 100% de ce que le produit final doit être.

Je posterai plus à ce sujet plus tard, mais à mon avis, ces conditions sont au mieux anti-agiles et au pire impossibles à obtenir.

Compte tenu de ce fait, il devient évident que dans notre travail quotidien, aucune estimation ne pourrait être réellement précise. Même si nous connaissons notre codebase, nous ne sommes jamais sûrs que nos hypothèses sont correctes. Peut-être devrons-nous complètement refactorer une zone de code qui n’a pas reçu le soin initial qu’elle méritait ?

Ce manque de précision fait des estimations un outil d’aide à la décision de faible fiabilité. Malheureusement, les estimations sont souvent considérées comme un outil de communication suffisant et justifient que les parties prenantes du produit n’aient pas besoin de travailler dans la même pièce. Je préférerais des équipes intégrées, où les experts du domaine, les devs, les product owners, les QAs et les Ops travaillent ensemble, au même endroit physique, ce qui facilite une boucle de feedback très courte et permet une construction véritablement collaborative du produit. Ce type d’équipe réussit souvent à identifier puis planifier des user-stories réalisables dans un sprint, en fonction des besoins business. La vélocité de cette équipe est désormais plus qu’une donnée managériale, mais aussi une donnée business orientée valeur : le nombre de user-stories mises en production par sprint.

Cette métrique est utile, car elle donne plus de visibilité sur ce qu’une équipe peut accomplir dans un futur proche, d’une manière bien plus fiable et tangible que les estimations traditionnelles en jours-homme.

Un autre effet dangereux des estimations vient d’un aspect psychologique : Nous, développeurs, avons souvent peur de l’échec. Quand une tâche donnée dépasse son estimation initiale, nous avons l’impression de vivre un échec. Ainsi, les estimations tendent à devenir un engagement, au moment même où nous les communiquons. Quand nous disons à l’équipe, ou aux managers, qu’une tâche donnée est réalisable en un jour, nous nous engageons implicitement à accomplir cette tâche en un jour. Et deux résultats sont possibles :

• l’estimation était trop optimiste : pour finir à temps, nous aurons naturellement tendance à baisser la qualité de notre code
• l’estimation était trop pessimiste : nous avons tendance à perdre le focus, et la productivité de l’équipe peut diminuer, d’une manière totalement imperceptible.

Mais nous, développeurs, nous sentons beaucoup moins coupables dans le second cas. Et alors ? Naturellement, nous avons tendance à ajouter une marge de sécurité quand nous donnons nos estimations afin d’éviter le premier cas. Et cette marge est ajoutée en pourcentage. Une pratique courante est d’ajouter 30% à l’estimation initiale. Oui, nous ajoutons littéralement un temps “je ne connais pas vraiment mon système aussi bien que je le voudrais” à une estimation non fiable, juste pour ne pas être en retard sur notre livraison, pour rendre nos managers heureux !

C’est pourquoi, à mon avis, les estimations ne devraient pas être utilisées comme outil d’aide à la décision.