Perplexité, complexité, vélocité

(Charles est un coach agile. Daniel est un développeur dans un projet agile. Un vendredi à 18h30, l’heure de la bière). Charles: Alors comment va votre projet ? Daniel: Hmm. Y a des hauts et des bas. Jusqu’ici on avait une courbe de vélocité en progrès, et puis là, soudain, le trou d’air. Le client nous refuse 4 scénarios sur les 7 prévus dans l’itération… C’est logique d’ailleurs, ses tests de recette ne passent pas. Charles: Qu’est-ce qui a changé ? Daniel: Difficile à dire. On n’a pas de problème majeur, plutôt des tas de petits soucis qui s’accumulent depuis des semaines. Du coup le manager nous revoit lundi pour mieux comprendre ce qui se passe. Il nous a dit “votre courbe de vélocité, je n’y crois pas”. Charles: Il a raison. Daniel: Bah voilà. Merci pour l’encouragement. A la tienne. Charles: Tchin! Tu me dis que la courbe de vélocité progresse et aussi que vous avez des tas de petits soucis qui s’accumulent depuis des semaines. Qu’est-ce que vous mesurez sous le terme “vélocité” ? Daniel: Simple: c’est la somme des points des scénarios utilisateurs terminés par l’équipe à la fin de chaque itération. Charles: Et ces points, comment vous les attribuez ? Daniel: Je ne t’apprends rien: on fait un planning poker en début d’itération. Charles: Comment ça se passe en ce moment le planning poker ? Daniel: Eh bien.. Gérald, tu sais, celui qui est arrivé le mois dernier, n’estime pas comme nous. Par exemple il vote 5 sur un scénario , en nous expliquant : “Il y a deux contrôles et une validation en base, c’est grosso modo la même complexité que l’écran xyz, qui était estimé aussi à 5”. Alors que pour réaliser ce scénario, on doit monter de version le framework LycwXml 2.3, et c’est coton, vu l’état du code existant, En plus, en l’absence de Jean-Mi, c’est Gérald, qui débute, qui va faire. C’est plutôt un scénario a 25 points en fait. Charles: Je vois. Comment ca c’est terminé ? Daniel: Le scrum master a fini par trancher: “Allez, disons 21. Comme ça, ça vous fera une bonne vélocité.” Charles: Oups!

Daniel: Tu penses que le scrum master n’aurait pas dû intervenir ? Charles: J’en sais rien. Ce qui me frappe, c’est qu’on dirait que vous essayez d’avoir une bonne vélocité. Daniel: Bah c’est le but, non? Une bonne vélocité, ça signifie que l’équipe fait bien son boulot. Charles: Tu veux dire que si elle augmente, c’est que l’équipe travaille mieux, c’est ça ? Daniel: Exactement. Charles: Et quand elle diminue, c’est que l’équipe fait moins bien son travail ? Daniel: Euh. C’est que l’équipe à des problèmes pour faire bien son travail. Charles: Et donc, dans ce scénario à 21 points, rappelle-moi ce qui entrait en ligne de compte dans l’estimation ? Daniel: Comme je t’ai dit: la montée de version du framework, l’état du code existant, l’absence de Jean-Mi. Charles: Des problèmes, en quelque sorte. Daniel: En quelque sorte. Charles: Voilà. Vous essayez d’avoir une bonne vélocité, tout en intégrant les problèmes dans l’estimation. Si on va par là, plus vous avez de problèmes, plus vos scénarios comptent de points… Daniel: Tu aurais un conseil, là ?

Charles: Eh bien, estimer le scénario comme l’a fait ton collègue, sur la base des fonctionnalités, en le comparant éventuellement à des scénarios précédents du même acabit, me paraît une bonne idée. Daniel: Mais ça ne nous dit pas forcément le temps qu’il faudra effectivement passer sur ce scénario. Charles: Exact, c’est une estimation “idéale” ou en “vitesse de croisière”. C’est pourquoi on la fait en points et non en JxH. Ce qu’on estime c’est la complexité fonctionnelle du résultat, et non l’effort à fournir. Daniel: Et comment on estime l’effort à fournir, dans ce cas ? Charles: Inutile. Daniel: Je ne comprends plus. Charles: Vous êtes 3 développeurs, donc par déduction vous consommez 15 JxH par itération. Ce n’est pas une information. Les points que vous collectez en fin d’itération, c’est de la quantité de fonctionnalités produites, et non de l’effort fourni. Donc ce qui doit entrer dans l’estimation, ce sont des points de complexité fonctionnelle, et non des efforts à fournir. Tu comprends ? Daniel: Ca marcherait mieux avec un exemple.

Charles: Imagine une équipe qui développe des écrans de saisie. Les écrans sont estimés à 5 points. A l’itération 1 l’équipe produit 2 écrans; sa vélocité est de 10. A l’itération 2, elle gagne en assurance et arrive à produire plus vite; sa vélocité est passée à 15. Daniel: Ok. Charles: A l’itération 3, elle est impactée par un changement portant sur du code qui a été copié/collé. Elle doit factoriser son code. Sa vélocité repasse à 10. A l’itération 4, elle trouve une librairie d’expressions régulières qui lui évite de coder à la main les contrôles de saisie. Elle produit alors 6 écrans, soit 30 points. Daniel: En gros, dès qu’elle s’outille, sa vélocité s’améliore. Charles: Pas forcément: à l’itération 5, elle découvre un nouveau framework d’écran de saisie qui lui permettrait d’économiser encore plus de temps et de lignes de code. Elle l’installe, le configure, se forme. Sa vélocité tombe à 0. Daniel: Ouch! Charles: A l’itération 6, elle a le framework en main et produit 10 écrans par itération! Sa vélocité passe à 50 points. Etc. Les chiffres sont schématiques, mais ce que cet exemple montre, c’est que lorsque l’équipe rencontre des problèmes, la vélocité baisse, lorsqu’elle les résoud, sa vélocité augmente. Ce qui change, c’est la vitesse de l’équipe, pas la richesse fonctionnelle des écrans. Daniel: Je crois que je comprend ce qui se passe chez nous. On a arrêté d’estimer seulement la taille des scénarios, et on a introduit dans l’estimation nos difficultés à les réaliser. Charles: D’où le fait que votre vélocité augmentait artificiellement… Daniel: …jusqu’au plongeon. Charles: Bon réveil!

Daniel: Il y a quand même un truc qui ne va pas dans cette façon d’estimer.. Charles: Sûrement. Tout ceux qui l’ont adopté ont d’abord rencontré des problèmes et des réticences. Daniel: Comment prendre en compte les tâches purement techniques dans le planning game, comme par exemple, installer des outils ou faire un gros refactoring ? Charles: A la fin des estimations, on se pose la question de l’engagement: “combien de scénarios pouvons-nous embarquer dans cette itération ?” Les développeurs peuvent dire : “dans l’itération précédente notre vélocité était de 25, on pourrait donc théoriquement réaliser tous les scénarios estimés, mais vu qu’on a des outils à installer et un gros refactoring à faire, on ne les produira pas tous.” Daniel: Et si le client insiste pour les avoir tous ? Charles: Il peut le vouloir mais ce n’est pas forcément ce qui arrivera. Il faut peut être négocier... Daniel: …mais au moins on négocie le périmètre par rapport à ce que doit faire l’équipe, et non la complexité des scénarios. Charles: Tu as tout compris. C’est la différence entre engagement et estimation. Daniel: Laisse, la bière est pour moi. Charles: Puisque tu insistes!