mardi 2 juillet 2013

Estimer : oui, mais pas tout de suite !


 Apprentissage incrémental


Quand on apprend une méthode, un sport, le solfège, une langue..., on commence par les bases, et on augmente progressivement le niveau de difficulté des apprentissages, au fur et à mesure qu'on a sécurisé les acquis précédents.

Quand une équipe apprend l'agilité, il me semble pertinent d'appliquer ce principe d'apprentissage progressif. D'ailleurs, c'est incrémental, c'est dans le thème !

Du coup, je me suis demandé quels sont les premiers apprentissages pour une équipe agile, et ceux qui peuvent attendre d'avoir sécurisé les bases.

De mon point de vue, les premières pratiques à mettre en œuvre sont celles qui ancrent les valeurs et principe de l'agilité (cf. le Manifeste Agile). Je choisirais donc :
  • les itérations courtes et les rétrospectives, qui permettent l'amélioration continue et l'adaptation
  • la présence du product owner dans l'équipe, les stand up meetings et le tableau partagé d'avancement des tâches (scrumboard, kanban,...), pour asseoir la collaboration et le feedback
  • les user stories et la priorisation du backlog produit, pour mettre la valeur du produit pour le client au centre des préoccupations de l'équipe
Et donc,  par soustraction, vous aurez compris que l'estimation ne fait pas partie des premiers apprentissages pour une équipe agile, de mon point de vue. J'entends hurler autour de moi, donc je vais m'expliquer.

A quoi sert l'estimation ?


L'estimation en planning game aide l'équipe à définir le périmètre sur lequel elle peut s'engager pour l'itération, pour peu qu'elle soit capable de calculer sa vélocité de façon fiable (par exemple, la moyenne de la vélocité des 3 dernières itérations).

L'estimation du backlog produit permet au product owner de piloter le projet : date de fin pour réaliser l'ensemble du backlog, ou quantité de périmètre à décaler à la release suivante pour tenir la date de livraison, ou... Et pour faire cela, il s'appuie là encore sur la vélocité de l'équipe, et il faut que son backlog produit soit suffisamment complet pour que ces prévisions aient du sens.

Donc on voit que l'estimation n'est efficace qu'une fois qu'on a une bonne idée de la vélocité de l'équipe, c'est-à-dire pas avant la fin de la deuxième itération.

Estimer à partir de la 3ème itération


Ah ben oui, je risque pas d'avoir la vélocité si l'équipe n'estime pas !!! Ne vous inquiétez pas, on va estimer, chaque chose en son temps ;-)

Mon idée est d'introduire les notions de complexité et de vélocité à la fin de l'itération 2. J'explique les avantages de ces mesures.

En général, au début d'un projet agile, il y a ce moment délicat où le coach (ou tout autre sachant) explique à l'équipe les principes de l'estimation relative des user stories. Il faut notamment expliquer que l'équipe doit choisir une user story de référence "pas trop petite ni trop grosse" et lui attribuer une estimation "moyenne", pour pouvoir ensuite comparer la complexité des autres US à celle de cette US de référence.
Si vous avez déjà essayé d'expliquer cela, vous avez déjà probablement l'habitude de voir le regard au mieux interrogatif, au pire vide et blanc des membres de l'équipe devant votre explication...

Le choix des user stories de référence est très simple : il s'agit des user stories des 2 premières itérations, qu'on estime a posteriori ! L'équipe peut appréhender la notion de complexité relative sur des user stories qu'elle maîtrise bien, puisqu'elles ont déjà été réalisées.

L'équipe estime alors les premières user stories restantes dans le backlog produit, et c'est plus facile parce que :
- on a une notion concrète de ce que représentent les points de complexité
- on connaît mieux le fonctionnel et l'environnement technique du produit, donc on comprend mieux la complexité de chaque user story

On calcule ensuite la vélocité moyenne sur les 2 premières itérations, et l'équipe peut s'engager plus facilement sur le périmètre de l'itération 3. L'équipe prendra un temps pour estimer l'ensemble du backlog (comme dans tout projet agile) et le product owner pourra construire le burndown chart de release et s'en servir pour piloter le projet.

En résumé :


Méthode :
- n'introduire l'estimation qu'au planning game de l'itération 3, avec les notions de complexité, de vélocité et d'indicateurs agiles
- utiliser les user stories des deux premières itérations comme user stories de référence, et les estimer a posteriori

Bénéfices :
- faciliter l'apprentissage de l'estimation et des indicateurs agiles
- faciliter le démarrage d'un projet agile en échelonnant dans le temps les apprentissages