Estimation d'un prototype
Comment évaluer un prototype : il s'agit d'un livrable conçu pour l'apprentissage, et non pour une utilisation réelle. Comment éviter que ce prototype, destiné à être jeté, ne devienne le code de production que personne n'avait prévu.
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 réelle. 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 définitivement. Les équipes qui évaluent les prototypes de la même manière qu’elles évaluent les fonctionnalités obtiennent un chiffre qui finance un type de travail inadapté.
L’autre type d’échec est tout le contraire : on conçoit un prototype à petite échelle, on livre un produit qui « fonctionne juste assez », puis on le met 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 destiné aux clients, ou est-ce uniquement à usage interne ? »
Introduction : « Si la réponse est oui, est-ce qu’on jette tout 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 une réponse ?
- À usage interne uniquement, ou devant les clients ?
- Jeter par défaut — et l’équipe s’y engage-t-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 le budget du prototype dans le cadre de la solution, et considérez la mise en production comme un projet à part entière, afin que le principe du « tout jeter » ne devienne pas la norme par défaut.
Concevez un prototype en fonction de la réponse, et non de l’objet final — 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 liées au Planning Poker concernant l’intrusion de l’analyse dans l’histoire, ainsi que les autres exemples d’estimation concrets.