L’estimation est au cœur de la gestion de projet informatique aujourd’hui. On l’utilise pour anticiper ce que sera le produit (le périmètre, les fonctionnalités), son coût (le budget) et sa date de livraison. Sans estimation, il semble difficile de lancer et de faire vivre un projet. Pourtant, une communauté grandissante, réunie autour de la bannière #NoEstimates, avance que l’estimation n’est plus nécessaire, ou plutôt qu’il existe des alternatives. Est ce que tout cela est bien sérieux ? Existe t-il réellement des alternatives efficaces ? Il semblerait bien. Voici une petite synthèse de ce que j’ai pu lire de plus intéressant sur le sujet.

Naissance du mouvement #NoEstimates

Ce mouvement est né sur Twitter grâce aux agi(li)tateurs Woody Zuill et Neil Killick. Les discussions (débats) sont facilement identifiables car estampillées #NoEstimates. Dans son article If you found estimates have no value, what would you do?, Woody pose la problématique de l’estimation au travers des questions suivantes : “Quel est le problème que nous essayons de résoudre avec l’estimation ? Quels sont les autres moyens de le résoudre ?”. Il a confronté des clients, des managers, des développeurs, des product owners à la question “Pourquoi avons-nous besoin d’estimer?” et compilé les réponses dans un nouvel article : Why do we need estimates?. Ces dernières mettent en évidence que l’estimation est principalement liée à la notion de décision.

Woody rappelle alors qu’il est difficile de réaliser des estimations précises pour les projets informatiques, notamment en raison du nombre d’inconnues relativement importantes (l’architecture n’a que peu de détails au début du projet, le périmètre est changeant). Il est donc délicat de faire reposer des décisions importantes sur des estimations peu fiables. Il souligne que nous donnons peut être trop d’importance aux décisions et que nous pouvons nous contenter de directions “approximatives” à condition d’être réactif à l’échec. Il nous encourage à minimiser l’importance des décisions pour laisser la place au cercle vertueux “erreur – apprentissage – ajustement” et à le pratiquer le plus souvent possible.

Comment estime-t-on les projets informatiques en général ?

L’estimation correspond à l’évaluation de la quantité de travail nécessaire au développement d’un logiciel. Elle est déterminée par le jugement humain et basée sur l’expérience. Pour obtenir une estimation, vous pouvez découper et détailler toutes les fonctionnalités de manière très précise afin de calculer la somme de toutes les tâches de développement et lui ajouter une marge pour les imprévus : bugs, absences, etc. Vous pouvez aussi réaliser des estimations en comparant le projet que vous voulez lancer à un projet similaire déjà réalisé (à l’aide d’abaques de chiffrage par exemple).

Quelles alternatives à l’estimation ?

On pourrait essayer de trouver d’autres outils d’aide à la décision, ou tout simplement lui donner moins d’importance. On s’engagerait dans ce cas sur des pistes incertaines auxquelles il serait possible de renoncer rapidement (donc à faible budget engagé) afin d’en explorer de nouvelles.

Est-il possible de donner moins d’importance à la décision? L’échec peut-être acceptable s’il intervient tôt dans le projet (donc à faible budget engagé) afin de réajuster la direction. Dans les discussion #NoEstimates, les exemples ci-dessous sont souvent cités comme alternatives:

Exemple 1 : La création de valeur seulement

Certaines entreprises mettent le focus sur le travail de la vision, un backlog priorisé, des cycles courts aux termes desquels le produit est présenté afin de recueillir du feedback. Elles n’exigent pas de leur équipe une estimation comme le montre ce retour d’expérience). Les projets grandissent selon deux axes: la santé du logiciel (qualité) et la vision du produit.

Ce modèle peut être critiqué en raison de sa gouvernance qui ne s’attarde pas sur les prévisions. Apple par exemple est assez silencieux sur le développement de ses nouveaux produits et ses estimations, mais les actionnaires ne s’en plaignent pas.

Exemple 2 : Engager peu d’argent au départ, livrer souvent.

Dans son article [What Price Estimation?], Neil Killick compare l’approche traditionnelle (négociation de contrat où le périmètre, le budget et la date de livraison doivent être fixés) à une méthode incrémentale, plus orientée partenariat. L’exemple suivant en détaille les modalités:

“Partez avec un budget (5.000 $), présentez votre vision produit à la société en charge du développement du site web et demandez-lui ce qu’elle peut faire avec ce budget sur une période donnée (5 semaines). La société pourra vous montrer son book de projets par exemple. Vous vous engagez avec elle et partez sur 5 itérations d’une semaine afin de vous assurer que la progression se fait dans le bon sens. La société vous donne accès à une version démo du site web mis à jour quotidiennement, ce qui vous permet de suivre l’avancée et de lui fournir un feedback rapidement. Si après une, deux ou trois semaines, vous n’êtes pas satisfait du produit, vous pouvez mettre fin au contrat, ce qui d’une part minimise le risque et d’autre part montre que la société qui s’engage est confiante sur la réalisation”.

Mes clients demandent des estimations !

“Mon boss ne me laissera jamais faire ça !”. La plupart des clients veulent des estimations, ça tient du bon sens. Mais au fait, qu’est ce qui motive l’estimation, est-il possible de répondre à ce problème autrement ? On peut se poser la question au cas par cas et analyser (en utilisant les “5-Why” par exemple) ce que les clients en attendent réellement (planning, garanties, financement, risque, etc.). Les exemples présentés plus haut correspondent à des environnement innovant où l’équipe (ou l’entreprise) a apporté une alternative répondant au besoin sous-jacent de la demande d’estimation du client. Ces méthodes n’écartent pas complètement l’estimation, mais elles ne la mettent plus au coeur de la prise de décision et le peu qui lui est consacré laisse la place à plus de temps et d’énergie pour la construction et le test logiciel.

Du scrum sans estimation ?

Doit-on dresser l’inventaire de toutes les fonctionnalités que va contenir le produit et pour chacune d’elles estimer le temps qu’elles prendront afin de calculer une date de disponibilité du produit fini? Étant donné que l’estimation est basée sur un périmètre fini, toute demande de changement de la part du client pendant la durée du développement remettra en question l’estimation initiale et conduira à un avenant au contrat avec un périmètre et une date de livraison différents.

A l’inverse, l’agilité autorise de la flexibilité et un design émergeant. Le client peut très vite avoir un prototype entre les mains et donner de nouvelles directions au produit à chaque itération. L’estimation “projet” a beaucoup moins de sens ici car la solution finale n’a pas été pensée dès le début du projet mais s’est dessinée au fur et à mesure des itérations. Néanmoins, l’équipe consacre du temps à estimer des user stories pour définir le périmètre fonctionnel du produit qu’elle va livrer à la fin du sprint (pour la démo notamment). L’estimation permettra également de faire émerger la vélocité de l’équipe qui est un indicateur de ce sur quoi peut s’engager l’équipe au prochain sprint en admettant que la vélocité lors de futures itérations sera à peu prés égale aux dernières constatées.

Peut-on se passer des sessions de planning poker, de T-shirt sizing ou autres techniques d’estimation et rester efficace? L’article [#NoEstimates – Doing Scrum Without Estimates] propose quelques pistes.

Design émergeant : développer un logiciel est assez imprévisible et peu répétable. Il ne s’agit pas de pièces qui s’assemblent au fur et à mesure comme celles d’une automobile (périmètre  fixé à l’avance) mais plutôt d’un design qui émerge au fil des fonctionnalités. On peut faire l’exercice d’estimer la quantité de travail pour un lot de fonctionnalités fixées à l’avance ainsi que la date de la livraison mais il y aura toujours des inconnues qui mèneront soit à une sous-estimation, soit à une sur-estimation ou bien à la cible avec de la chance; et il serait maladroit de changer le périmètre en cours de route car cela fausserait l’estimation de départ. Démarrer un projet avec un périmètre de fonctionnalités variable va influencer la date de livraison. Ce n’est pas un problème si le client en est conscient car il pourra manœuvrer : orienter le développement vers les fonctionnalités qui ont le plus de valeur à chaque itération et déclencher la livraison quand le produit lui parait satisfaisant.

La vision est la clé : pour développer un produit, le travail sur la vision est essentiel. On pourra se référer à l’article [Vision produit et story map, des outils très efficaces pour le product owner] pour plus d’information. Dans cet exercice, on s’intéresse principalement aux objectifs de haut niveau, pas aux détails. Ce n’est donc pas le moment de décortiquer chaque fonctionnalité pour estimer le travail qu’elle va représenter. On s’intéressera plus aux différents jalons qui feront du produit un succès. Il est d’ailleurs tout à fait possible de challenger ces fonctionnalités durant le développement en fonction du feedback utilisateur.

Supprimer les inconnues : en développement logiciel, il est difficile de tout prévoir. On peut essayer de persister dans cette voie en s’interrogeant sur ce qui pourrait rendre l’estimation plus efficace ou bien attaquer le problème sous un autre angle: supprimer les inconnues. Le product owner peut fixer une date de livraison basée sur un budget et/ou bien une contrainte de temps (ex: nous avons un budget de 30 000 euros pour lancer une application pour l’Open d’Australie 3 jours avant l’évènement). La date de livraison est connue, le périmètre de fonctionnalité n’a pas besoin d’être défini dès le départ (seul le travail sur la vision est important). Les itérations successives contribueront à apporter le plus de valeur à l’application jusqu’à la livraison.

Temps passé à estimer = gaspillage ? Estimer des user stories prend du temps, même en utilisant l’eXtreme Quotation. Est ce que le temps passé à estimer est rentable? Aidera t-il le product owner à privilégier une user story plutôt qu’une autre, sachant que le coût estimé de développement est plus faible? Le product owner aura plutôt tendance à dresser une liste des user stories ordonnées par valeur. Certes, il est possible de tenir compte du coût de développement pour privilégier une user story peu prioritaire mais aussi peu coûteuse pour compléter le sprint. Pour simplifier, on demanderait à des personnes de consacrer du temps à déterminer quelles user stories moins prioritaires peuvent passer devant d’autres plus prioritaires sous prétexte de compléter un sprint? Mike Cohn rappelle dans cet article que l’objectif du sprint planning est de sélectionner un ensemble d’éléments du product backlog sur lequel l’équipe va travailler durant le sprint et de s’assurer qu’il y a eu suffisamment d’échanges, de discussions pour être prêt à y travailler. Trop s’attarder sur les taches et leur estimation conduit l’équipe à passer trop de temps en sprint planning. L’essentiel est que lorsque l’équipe commence une user story, elle dispose bien de toutes les informations pour y travailler. La clarification pourra avoir leur lors du sprint planning en s’appuyant sur le backlog priorisé et pendant le sprint. Concernant la démo de fin de sprint, elle peut s’effectuer à l’aide des nouvelles fonctionnalités issues du backlog ordonné par valeur de user story.

Mes user stories deviennent INVST ? Si mes user stories n’ont plus besoin d’être estimées, elles ne sont plus INVEST? Le critère INVEST reste l’un des meilleurs pour qualifier une bonne user story. Le terme Estimable résonne avec le fait qu’une user story doit porter avec elle suffisamment d’information pour qu’on comprenne le sens et les enjeux de son intégration au sein de l’application.

#NoEstimates, de bonnes idées

Le débat autour de l’estimation est intéressant et de nombreux agilistes ont pris part à la discussion, soit pour la défendre ou soit pour grossir le mouvement #NoEstimates. On pourra comprendre les arguments mis en avant par ce mouvement mais que répondre à son patron ou bien ses clients qui demandent une estimation?

Posent-ils la bonne question? On peut, comme à l’habitude, leur fournir une estimation qui leur servira à prendre des décisions business importantes. Il est malheureusement difficile d’établir une estimation fiable en développement logiciel en raison de sa faible prédictibilité, de la capacité de l’équipe (hypothèses basées sur une taille d’équipe fixe, qui se révélera fausse lors d’une absence ou d’un départ) et des changements de priorités. Si les prévisions sont dépassées, on se retournera facilement vers celui qui les a émises, voire vers l’équipe de développement.

On peut aussi travailler avec chaque client sur leur besoin d’estimation (que permet l’estimation de leur coté ?) et identifier une alternative. On pourra toujours donner de la visibilité en calculant un temps de cycle des user stories et une estimation sommaire basée sur sa place dans la file d’attente (voir cet article pour plus de détail). On considère ici le poid moyen d’un élément de travail, ainsi qu’une limite fixe du travail en cours (WIP).

Les idées du mouvement #NoEstimates méritent notre attention. On y trouve des alternatives intéressantes à l’estimation qui peuvent être appliquées dans certains contextes.Si vous avez l’impression que l’estimation n’apporte pas de valeur à votre projet, ça vaut la peine de les expérimenter.

De votre coté, avez-vous mis en place des alternatives à l’estimation ? Qu’est ce qui l’a motivé ? Qu’avez-vous appris ?

photo credit: DVIDSHUB via photopin cc