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

samedi 14 janvier 2012

Mes deux cents : "Quelques mauvaises pratiques"

Ceux qui ont lu les quelques billets de mon blog auront bien senti que je suis très enthousiaste à propos de Scrum et d'Agile. C'est parceque j'ai connu des situations de mauvaises pratiques, et qui n'arrivaient plus dès lors que j'ai commencé à travailler sur des projets Scrum. Oui, j'ai connu du grand n'importe quoi avant de découvrir Scrum. Et voici quelques anecdotes :)

- J'avais 22 ans et j'étais plein de motivation et d'espoir pour le futur. Lors d'un projet de refonte, le chef de projet présente une solution pour la nouvelle interface et de façon naïve j'osais m'exprimer ainsi : "ah non, je suis pas d'accord sur cette solution". Réponse du chef de projet : un grand rire bruyant suivi de "non mais on te demande pas ton avis, on te demande de faire". J'étais renvoyé dans les cordes et je me suis vu me faire remettre en place : celle d'un ouvrier à qui on ne demande pas de penser. Vous vous rendez bien compte que se faire couper ainsi dans son élan coupe également toute motivation. J'étais passé dans ma tête d'une obligation de résultat à une obligation de moyen. Une équipe est une équipe car les gens sont différents et ont des idées différentes. Certains vont voir des solutions à des problèmes lorsque d'autres seront bloqués et vice-versa. C'est cette collaboration et cet apport d'idées de toutes parts qui fait la richesse de l'équipe. Il est inutile de croire qu'une personne peut avoir toutes les réponses. Et dans le cas de mon anecdote, c'est ce que le chef de projet pensait : sa solution était la bonne, quoiqu'en pensent les membres de l'équipe. La conséquence avec ce genre de management est que si moi ou un membre de l'équipe s'aperçoit d'une mauvaise pratique, un trou de sécurité ou tout autre problème, nous sommes encouragés à ne rien dire et ça tombe bien, c'est ce qu'on nous demande : implémenter une solution, même si elle est mauvaise. J'ai écrit de la m**** ? Ce n'est pas grave car c'est ce qu'on m'a demandé de faire et j'ai donc "réussi" ma mission :/ Ok, j'avais 22 ans à l'époque et ça ne se serait pas passé comme ça si ça arrivait aujourd'hui, je le reconnais ;)

- C'est une anecdote arrivée à des membres de mon équipe et à moi-même aussi. Les équipes ont souvent un outil d'intégration continue tel que Jenkins. Si celui-ci détecte que des tests unitaires ne passent pas à cause de régressions par exemple, il lance une alerte. Il s'avère que sur certains projets, c'est un outil qui sert de joujou à pointer la "nullité" des uns et des autres. "Machin, tu as cassé le build !" (traduction : "t'es vraiment une tâche !") comme si c'était le projet en entier que cette personne venait de planter... Comme le disait judicieusement un ancien collègue : "Ce n'est pas grave de casser le build ! L'important est de le réparer !" Et c'est bien cela qui importe : pourquoi avoir un outil de surveillance si l'on considère qu'il ne doit jamais passer à un autre état que "OK" ? Ce qui importe lorsque l'état du build est KO est de s'en rendre compte vite et d'intervenir au plus vite, et non de perdre son temps à dire à la personne en cause comme ce qu'il a fait est mal, etc...
- Ahlala, c'était toujours un moment particulier quand mon chef de projet me tendait une feuille avec un boulot à faire pour dans 3 jours. Une question qu'avait soulevée un collègue de cette mission me paraissait pourtant pertinente : "Mais qui a estimé cela à trois jours ?". Le chef de projet nous donna une réponse avec une telle confiance dans la voix qu'elle en semblait presque logique et légitime : "et bien il y a des concepteurs très expérimentés là qui ont pour rôle d'écrire les specs et de les estimer". Whoa! Heureusement qu'il y avait ces types pour nous dire combien de temps on allait mettre pour développer tel ou tel module. C'est pas grave s'ils ne connaissaient rien à Java et ne nous connaissaient pas non plus vu qu'ils ne nous ont jamais parlé en un an et demi. Vraiment, on se demande pourquoi on demanderait leur avis aux développeurs...

Bon je m'arrête là sinon on va croire que je n'ai rencontré que des galères dans ma vie... :P