Estimation d'un prototype
Comment évaluer un prototype : il s'agit d'un livrable destiné à l'apprentissage, et non à une utilisation concrète. Comment éviter que ce prototype, initialement 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 cela. »
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 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 un budget pour le prototype 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 lorsque vous estimez 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’infiltration de l’investigation dans l’histoire, ainsi que les autres exemples d’estimation qui ont fait leurs preuves.