2006, agilité timide

Les formations que j’ai faites cette année, pour mes clients industriels ou pour mes étudiants :

Lors des revues d’itération de vendredi, une discussion a commencé sur les fournitures relatives à la gestion de projet. Les équipes doivent-elles fournir une liste des risques, un relevé des heures passées, un bilan de l’itération ? Sous quelle forme cela doit-il être élaboré ? Ces informations doivent-elles être écrites ou présentées oralement lors de la revue ?

Lors du séminaire du 8 décembre, Benoit est revenu sur ses doutes -dont il m’avait déjà fait part- dans la technique d’estimation en points. A partir des relevés individuels de charges sur les tâches, il a calculé les heures passées sur les histoires. Il a constaté que des histoires estimées à 2 points ont finalement pris plus de temps à développer que des histoires à 3 points. Il a mesuré que pour 2 histoires avec le même nombre de points, il pouvait y avoir des variations du simple au double dans les heures passées. Il a calculé qu’un point ça faisait en moyenne 1,25 h/j mais que la variance était importante. Cela le pousse à mettre en doute la technique d’estimation en points.

Voici quelques commentaires après le séminaire de vendredi dernier. Encourageants ! Et des sujets à débattre pour une prochaine fois.

Pour essayer Eclipse Project Framework Composer, j’avais pris comme exercice le “processus” Scrum, comme raconté dans ce billet et celui-ci.

Je me suis pris au jeu, j’ai complété la description de Scrum et j’ai continué en ajoutant l’utilisation d’Icescrum avec des “tool mentors”.

Un résumé du rôle, appelé Product Owner dans Scrum et Customer dans XP

Le directeur de produit [1] est le représentant du “métier” dans le projet.

La planification agile permet de s’adapter à la situation courante : à tout moment on donne la priorité à ce qui apporte le plus de valeur.

Une release est une série de sprints. Mais quand arrête t-on de faire des sprints pour finir la release ? A la lecture du premier article de Scrum(1996), voilà comment on décide :

quand les variables de temps, de concurrence, d’exigences, de cout et de qualité concourent à sortir une release.

Que penser de ces variables ?

Qu’est ce qui fait la différence avec la fin de release où on livre vraiment le produit ?

Avec les méthodes Agiles, on cherche à obtenir un produit partiel potentiellement livrable- pour reprendre la formulation Scrum- à la fin de chaque itération. Lors de la revue de fin d’itération, l’équipe fait une démonstration de ce produit. Et après ?

Les présentations de Scrum, notamment les courtes, mettent particulièrement en évidence la notion de sprint. On comprend que la livraison du produit (complet) se fait suite une série de sprints et on pourrait croire que le backlog de produit a une vie uniquement liée à cette suite de sprints. En fait la vie du produit, et donc de son backlog, va bien au delà.

Après une série de sprints, il y en a une autre, puis encore une autre, jusqu’à la fin de vie du produit. J’ai pris l’habitude d’appeler une série de sprints une release. La release est le chainon manquant entre le produit et le sprint.

Récemment une discussion sur le forum Scrum : comment expliquer à un DSI DG ce qu’est Scrum en 100 mots. Le point de vue est celui d’un ScrumMaster qui parle pour son équipe. Voilà ce que ça donne en français, avec mes adaptations, mais en restant dans l’esprit du texte anglais :

Nous avions aujourd’hui une séance d’estimation pour le projet IceScrum2.0. Une cinquantaine d’histoires d’utilisateur déjà réalisées dans la première version client lourd Java sont à porter dans un environnement J2EE.

Ci-dessous le programme du séminaire sur les Méthodes Agiles à Toulouse. Vous pouvez télécharger la Plaquette de présentation du SigmaT1, un grand merci à Frédéric. Pour vous inscrire et obtenir un plan d’accès, envoyez-moi un message.

Je suis impliqué dans des projets étudiants depuis 8 ans. Avec en moyenne 7 projets en parallèle par an, cela fait plus de 50 projets suivis :

• En 1999, c’était un cycle en V avec plan qualité qui était appliqué.
• A partir de 2000, j’ai introduit le RUP puis des variantes allégées. Les étudiants pratiquent un développement itératif et incrémental.
• A partir de 2005, je suis progressivement passé d’une approche style RUP à une approche plus agile type Scrum.

C’est le Directeur Produit (product owner) qui définit les priorités. Quand je joue ce rôle sur des projets, j’utilise et mets à jour les priorités de la façon suivante :

Au début du projet, une fois que le backlog contient suffisamment d’exigences :

• je fais un première passe sur les priorités
• une séance d’estimation a lieu avec l’équipe. Les exigences sont estimées en suivant les priorités que j’ai définies (la durée de la séance étant limitée, il est préférable de traiter en premier les exigences les plus prioritaires).
• j’ajuste les priorités en tenant compte des estimations. Je peux, par exemple, monter dans la liste une exigence estimée peu chère.

Elle est agile, c’est sûr, cette chèvre qui n’existe pas dans les Alpes ni les Pyrénées, mais peuple uniquement les Rocheuses.

Ca doit être pour ça que Mike Cohn en a fait son emblème et a appelé sa société Mountain Goat Software. Comme si je m’appelais BouquetinLogiciel !

Un des points forts de Scrum est le backlog de produit, qui regroupe toutes les exigences, ce qui facilite leur gestion. Il est -techniquement- simple de définir les priorités entre les éléments du backlog. Mais sur quels critères se baser ?

Il faut d’abord bien comprendre que la priorité correspond à l’ordre de développement. Ce ne sont pas 2 notions différentes. La priorité est souvent comprise autrement -que pour définir le contenu des itérations-(voir ce billet précédent), tant qu’on n’a pas pratiqué Scrum.

Un principe agile est qu’une histoire d’utilisateur soit développée et finie dans une itération. Une histoire possède une carte, une conversation et une confirmation. Ce qu’on met sur la carte, c’est le titre de l’histoire et cela est fait (bien) avant que l’itération ne commence. On pourrait croire qu’au début de l’itération on n’a que ça et que la conversation et la confirmation ont lieu pendant l’itération.

Il n’en est rien.

J’ai entendu parler pour la première fois de document Vision avec les premières versions du RUP, vers 1997. Un bonne vision, c’est quand même autrement utile que les documents d’EB (expression des besoins) ou les pseudo cahiers des charges que je lis souvent dans les entreprises.

Une histoire d’utilisateur est composée d’une “carte”, d’une conversation et de sa confirmation. Sur la carte (bristol, post-it, ou carte virtuelle), on écrit le “résumé de l’histoire”.

Mike Cohn, auteur de User Stories Applied, préconise l’emploi de la formulation suivante :

As a , I want so that

En français, cela donne :

J’ai déjà parlé de la visite de Michel et d’autres français chez Google : voyant marqué Scrum sur une porte, un de ces visiteurs a pensé au rugby " tiens ils font des mêlées chez Google ?". En Angleterre, en Australie et en Nouvelle-Zélande grandes terres rugbystiques et pour des français aussi donc, c’est une réaction normale -quand on n’a pas entendu parler de la méthode Scrum- on pense à la mêlée du rugby.

C’est clair ?

Je prépare une formation sur la façon de spécifier des exigences “agiles” avec des user stories. Bien sûr je me suis posé la question de comment traduire user story en français et j’ai regardé ce qu’en disaient les autres, dans la communauté XP :