(No)Estimates !

C’est un combat quotidien pour le développeur d’aujourd’hui : donner des estimations précises du travail que nous faisons, ou que nous devrons faire. Quand avez-vous réussi pour la dernière fois à donner une estimation vraiment précise ? Vous savez, celle qui correspond parfaitement à la quantité de travail à faire, dans le délai exact, avec une vision claire de ce que vous deviez accomplir ? Ça fait un moment, n’est-ce pas ?

Comment pouvons-nous faire mieux ?

Il y a plusieurs raisons pour lesquelles on nous demande d’estimer une tâche, une story ou même un projet.

1) La tâche/story est déjà définie, et l’équipe doit s’assurer que son objectif correspondra bien à l’ambition (et l’engagement) de l’équipe d’ici la fin du sprint.

C’est une situation compliquée, qui implique que vous avez à la fois un budget fixe et un périmètre fixe. Dans ce cas particulier, estimer les tâches/stories est une pure perte de temps. Vous feriez mieux de vous concentrer sur la partie la plus critique du travail, l’analyser, la concevoir, la coder, mais faire du planning poker ou des exercices similaires ne repoussera certainement pas la deadline ni n’étendra le budget.

2) Le Business/Management a besoin d’arbitrer les prochaines priorités

Dans ce cas, les “gens de l’autre côté” veulent au mieux calculer le ROI. Rien de mal à cela, évidemment, mais cela indique qu’ils ont un budget limité. Alors, pourquoi ne pas demander directement le budget et essayer de construire la meilleure solution possible avec eux ? Au pire, le Business/Management manque de vision, alors ils essaient de sélectionner les projets/fonctionnalités les moins chers. Oui, vous avez bien lu. Certaines organisations planifient en fonction du coût plutôt que de la valeur… Si cela se produit dans votre entreprise, ne restez pas inactif, essayez d’impliquer l’équipe produit, montrez-leur comment une équipe de développeurs passionnés peut les aider à améliorer leurs résultats en leur livrant de la valeur de manière incrémentale (et oui, un environnement de Continuous Integration peut beaucoup aider, tout comme un processus de Continuous Delivery). Invitez-les à des ateliers de collaboration (avez-vous déjà entendu parler de l’EventStorming ?) pour prouver que vous êtes capable de parler et de comprendre leur “langage”, leur problème. Les estimations ne seront plus nécessaires, car les parties prenantes du projet seront ravies de demander des changements et de voir qu’elles font partie de l’équipe qui construit réellement leur produit.

3) Le Management a besoin d’anticiper les dates de livraison, pour se coordonner avec d’autres départements/clients

C’est, à mon avis, la meilleure raison pour avoir besoin d’estimations. Une campagne média pour promouvoir un nouveau site web doit être planifiée longtemps avant son lancement effectif, par exemple, et le lancement du site web doit être le plus proche possible de cette date. Mais dans ce cas, le périmètre ne peut pas être fixe. Le développement est un processus exploratoire. La seule façon de fournir une estimation extrêmement précise d’un projet est essentiellement de découper chaque fonctionnalité en un ensemble de très petites tâches. Mais pour y parvenir, vous devrez explorer votre domaine et comprendre comment organiser le logiciel. C’est impossible à faire sans le coder…

Alors, la prochaine fois que quelqu’un vous demande des estimations, demandez-lui pourquoi il en a besoin. En comprenant ses besoins comme vous comprenez son domaine métier, vous construirez une relation basée sur la confiance.