Estimation d'un prototype

L’histoire dont le résultat attendu est « nous savons désormais ce qu’il faut construire », et non « nous l’avons construit ».

Un prototype est conçu pour l’apprentissage, et non pour une utilisation concrète. L’objectif est de répondre à une question (cette interaction semble-t-elle pertinente, cette approche est-elle évolutive, cette API tiendra-t-elle la route ?) suffisamment rapidement pour que vous puissiez changer de cap avant de vous engager. Les équipes qui évaluent les prototypes de la même manière qu’elles évaluent les fonctionnalités obtiennent un chiffre qui justifie un type de travail inadapté.

L’autre type d’échec est tout le contraire : estimer un prototype à petite échelle, livrer un produit qui « fonctionne juste assez », puis le mettre en production parce que le calendrier a évolué. Le prototype qui devient le produit final est le code le plus coûteux de la base de code, car personne n’a prévu les éléments qui n’y figurent pas.

Ce qui se dit dans la salle

Ingénieur : « Je peux mettre quelque chose sur pied en quelques jours. »

Introduction : « À quelle question essayons-nous de répondre ? »

PM : « Est-ce que cela sera diffusé auprès des clients, ou est-ce uniquement à usage interne ? »

Introduction : « Si la réponse est oui, est-ce qu’on le jette et on recommence à zéro ? »

Ingénieur : « Nous ne jetons jamais rien. »

Questions qu’il convient de se poser avant de voter

• À quelle question le prototype apporte-t-il une réponse, et comment saurons-nous que nous avons trouvé une réponse ?
• À usage interne uniquement, ou devant les clients ?
• C’est une stratégie « jetable » par défaut, et l’équipe s’y tient-elle ?
• En quoi consiste cette période délimitée, et que se passe-t-il à la fin de celle-ci ?
• Si cela fonctionne, quel est le parcours entre le prototype et le code de production ?

Le principe de l’ingénieur selon lequel « on ne jette jamais rien » constitue le véritable risque : prévoyez un budget pour le prototype en tant que solution, et envisagez la phase de production comme un projet à part entière, afin que le « tout jeter » ne devienne pas la norme par défaut.

Concevez un prototype en fonction de la réponse, et non de l’artefact, et planifiez la refonte avant que le calendrier ne vous y oblige.

Tout comme l’estimation d’un pic d’activité de recherche, le résultat attendu est la connaissance ; traitez-les de la même manière. Consultez les erreurs courantes au Planning Poker concernant l’intrusion de l’analyse dans la story, ainsi que les autres exemples d’estimation concrets.