jeudi 26 janvier 2012

La première vélocité

La vélocité est un concept un peu surprenant au premier abord. Cependant, il suffit de participer quelques temps à un projet Scrum pour bien comprendre son fonctionnement. Mais qu'en est-il de la première vélocité affectée à l'équipe de développement pour le début de la phase de développement ? Est-ce une valeur arbitraire fixée par la méthodologie ? Est-ce le coach Agile qui évalue l'équipe sur des critères objectifs et donne son évaluation de la vélocité de départ ? C'est ce que j'ai voulu savoir sur cette valeur de départ qui, bien que destinée à varier au fil du temps, donne le premier étalon de la capacité de développement d'une équipe.
Le constat que j'ai pu faire était qu'il y avait de multiples écoles en la matière. Chacune possède des attraits et je vais tenter de les décrire au mieux. Déterminer laquelle est la meilleure ne relève cependant pas de ce billet, et je pense surtout que le débat n'a pas lieu : chacun devrait choisir selon les spécificités de la société et de l'organisation où on intervient.

Pour ceux qui veulent fonctionner encore un peu avec le concept de jour/homme
Une méthode pour une équipe qui aborde pour la première fois le côté abstrait des points d'histoire est de faire un choix arbitraire pour l'équipe : par exemple, 1 point = 1 heure de travail. Cela permet aux gens habitués au concept de jour/homme de faire des estimations de leurs premières tâches en se basant sur une capacité de travail connue d'eux. Ainsi la vélocité est égale à la somme des points d'histoire pour le temps total d'un sprint (10 jours ou 80 heures) et donc on obtiendra une première vélocité pour l'équipe. Par contre, l'étape importante au cours des sprints suivants est de se soustraire de cette égalité ! Sinon, comment justifier que la vélocité puisse varier d'un sprint au suivant vu que le nombre de jours et d'heures restent le même ?

La vélocité atteinte lors du sprint 1 devient la vélocité étalon des sprints suivants
C'est un sprint qui est un peu difficile à faire avaler aux managers : on part en roue libre pendant un sprint, donc 10 jours... La capacité de travail n'est pas connue, donc le planning n'est pas faisable avant la prochaine rétrospective (argh!). Au bout de cette période, on obtient une valeur de vélocité qui donnera une base pour le planning poker suivant.

Affecter 2 points arbitrairement à une user story très simple et s'en servir comme étalon
Il s'agit de choisir dans le backlog de produit une user story très compréhensible de tous les membres de l'équipe. Comme chacun sait combien de temps il mettra pour la faire, on lui affecte 2 points. Les autres user story seront estimées par l'équipe relativement à cette user story étalon.

Estimer une multitude de user story divisées en tâches élémentaires
C'est une technique se rapprochant des deux méthodes précédentes, un petit mixte quoi. Il s'agit de prendre une bonne quantité de user story de façon à être sûr qu'il y en a bien plus que ce qu'on pourra terminer dans le sprint. Ce processus est quelque peu long car il faut diviser toutes les US en tâches la plus élémentaire possible de façon à avoir une estimation ne dépassant pas 5 points, quelle que soit la valeur que représente 1 point pour l'équipe. Ce découpage unitaire très poussé doit permettre d'estimer des US en se basant sur des tâches unitaires. A la fin du sprint, on obtient une vélocité assez juste.

Estimer une quantité limitée de tâches non cruciales à faire pendant le sprint 0
C'est un peu un mixte des méthodes dont je viens de parler, mais appliquer au sprint 0. Une possibilité est d'utiliser ce sprint zéro pour travailler sur des tâches de petite taille et qui serviront d'étalons pour l'estimation lors du planning poker en début de sprint 1. Un sujet qui génère des débats est bien ce sprint zéro. A quoi sert-il ? Entre autres à mettre en place les postes de travail, l'environnement d'intégration, etc... Dans notre cas, on peut consacrer un peu de temps de ce sprint zéro à faire du développement. Pas forcément quelquechose de crucial, d'ailleurs, c'est probablement déconseillé. Mais implémenter quelques fonctionnalités pour avoir l'opportunité de valoriser en points du vécu (c'est le point important) et s'en servir comme échelle après.

Enfin, une technique originale par Claude Aubry
Il nomme cette méthode "l'estimation par similitude d'effort". En gros, il s'agit de regrouper des user story par taille (basée donc sur l'effort estimé pour chaque story), d'ordonner ces groupes et d'affecter ensuite les valeurs de points provenant de la suite de Fibonacci (1, 2, 3, 5, 8, 13...) aux différents groupes dans l'ordre dans lequel ils sont : les US du premier groupe seront affectées de 1 point, le deuxième groupe 2 point, etc... La méthode est appliquée plutôt en formation pour gagner du temps, mais je voulais la citer car je trouvais que c'est une façon intéressante d'estimer quand on ne sait pas par quel bout commencer.

Finalement, une des critiques qu'on essuie lorsqu'on présente le concept de vélocité est l'incertitude sur les délais et le planning que les gens ressentent vis à vis de cette façon d'estimer. Oui, c'est du macro-planning et nous sommes incapable de donner une date précise de mise en production au client (dans un premier temps). Mais ne soyons pas hypocrites, ce n'est pas comme si on était plus juste en cycle en V, on est plus précis, ah, ça oui : "cette application sera livrée le 6 mars". Sauf que tout le monde sait pertinemment que la date de MEP ne sera pas respectée, ou alors avec beaucoup de concession sur ce qui sera livré... La question est : pourquoi vouloir être précis si on sait qu'on ne sera pas juste ? Avec le calcul de la vélocité, vos estimations se font de plus en plus précises au fil des sprints et la date annoncée pour la MEP sera bien plus juste (je fais la distinction entre juste et précis) vu l'expérience accumulée au fil du temps. La date de MEP est annoncée plus tard mais aura un écart moindre (voir aucun écart) avec la réalité. Et surtout, l'honnêteté aura été de reconnaitre notre incertitude du début et notre confiance plus tard, au lieu de s'engager sur un délai qu'on ne sait pas s'il sera tenable et ensuite de trouver des excuses pour justifier des retards comme cela arrive fréquemment sur du cycle en V. C'est comme quand vous faites construire votre maison par un promoteur, il vous annonce une date de livraison très précise qui ne tient pas compte des aléas (pluie, gel, etc...). Pourtant, ce sont des choses qui ont des grandes probabilités d'arriver alors pourquoi les ignorer ? Et à l'approche de la date de livraison de la maison, vous recevez une lettre listant les jours non travaillés pour telle ou telle cause. Résultat : le client n'est pas content et le constructeur rush les finitions pour minimiser le retard... \o/

A lire, les articles que j'ai consultés pour concocter ce billet :
http://www.aubryconseil.com/post/L-estimation-par-similitude-d-effort
http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/21/Estimation-Agile-et-Cone-d-incertitude
http://www.scrumdesk.com/effort-vs-time/
http://scrummethodology.com/scrum-sprint-zero/
http://stackoverflow.com/questions/5076452/how-to-set-up-story-points-and-first-sprint-capacity-for-scrum

1 commentaire:

  1. Je trouve la méthode de Claude, basée sur la suite de Fibonacci, incroyablement géniale.

    Si, en plus, on s'intéresse aux études liant cette suite au fonctionnement des groupes (et au cerveau humain, et à l'apprentissage cognitif, et aux merveilles de la nature, etc.) alors on ne peut que l'adopter.

    RépondreSupprimer