2007, l'essor de Scrum

Cette année, mes questions étaient ouvertes et la correction n’est pas facile. Il me faut lire entre 5 et 8 pages bien remplies par étudiant. Avec une trentaine d’étudiants, ça doit faire dans les 200 pages.

Le plus souvent c’est plein de fautes d’orthographe. Dans la seule copie où je croyais ne pas en trouver, il est écrit à 2 lignes de la fin : “il … est choisit…”. Dommage, mais cela ne me gêne pas. Plus embêtant pour ma lecture, c’est que ce n’est pas toujours bien présenté ni bien écrit.

Mais j’y trouve quand même du plaisir à voir que ce que j’ai présenté a été bien compris. Et puis je découvre toujours quelques perles amusantes.

On trouve ScrumMaster en un mot et Scrum Master (en 2 mots).

Un article d'InfoQ: Debating the Merits of Pair Programming rappelle que la programmation en binôme est un sujet des plus discutés parmi les pratiques que propose Extreme Programming.

Je viens de lire les prévisions de Fred Cavazza sur le Web2.0 et les anticipations de Louis Naugès sur la bureautique2.0. Et si on faisait l’exercice pour le domaine des méthodes Agiles ?

Nous sommes 33 sur le projet Wilos, c’est bien plus que la taille normale d’une équipe Scrum.

Wilos est un environnement d’exécution de processus. Il y a 32 personnes qui travaillent sur le projet, plus moi qui suis le directeur de produit. La première version de Wilos sortira fin mars. Scrum est appliqué, avec des sprints de 3 semaines. Sur le schéma, l’organisation que nous mettons en place, en adaptant Scrum à la taille de l’équipe.

L’équipe est formée de 3 groupes avec chacun 10 ou 11 personnes. Chaque groupe s’occupe d’un domaine fonctionnel identifié. En plus, un des groupes est plus particulièrement chargé de l’infrastructure.

Il y a un backlog de produit unique.

On commence à trouver des formations en France sur Scrum et les méthodes Agiles. Par exemple, Valtech propose un cours de 5 jours “gérer les projets Agiles”.

Quelques commentaires sur le contenu du backlog de sprint :

• les tâches, estimées en heures, ne devraient pas dépasser une vingtaine d’heures, soit environ 2 jours de travail pour une personne. Par exemple, une tâche qui s’appelle “Page JSP (interface)” et qui fait 40 heures est probablement le signe d’un travail à faire qui est mal identifié ou mal maîtrisé.

Eclipse Process Framework publie un plugin Extreme Programming.

Aujourd’hui j’ai défini des tests d’acceptation [1] pour des histoires d’utilisateur[2]. C’est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s’assurer qu’une histoire est complète. C’est un exercice indispensable si on veut automatiser les tests d’acceptation. Si on n’automatise pas cela reste tout de même très important.

Par exemple pour l’histoire “En tant que participant à un projet, je démarre une tâche du plan”, des critères de test que j’ai identifiés sont :

Je viens de lire Project Management and Scrum – A Side by Side Comparison(pdf), une comparaison entre le rôle traditionnel de chef de projet (selon le PMBOK) et le rôle de ScrumMaster.

Un cycle de vie est un ensemble ordonné de phases décrivant la vie d’un projet, la phase n ne pouvant commencer que si la phase n-1 est terminée. Dans la représentation graphique du V, les boites s’appellent Spécification, Conception, Codage, Test et Validation pour prendre la variante la plus simple[1]. La signification du nom de ces différentes boites est à peu prés claire : Spécification on décrit le quoi, Conception le comment etc. Il s’agit des disciplines classiques du développement de logiciel.

Le prochain Séminaire d’Information Gratuit sur les Méthodes Agiles de Toulouse aura lieu le vendredi 16 mars à 16 heures. Le premier SIGMAT du 8 décembre, organisé avec la collaboration de l’IUP ISI, a reçu un accueil favorable. Nous avons décidé de renouveler l’expérience et nous prévoyons d’en proposer régulièrement, 3 ou 4 par an.

Hier j’ai animé 2 sessions de planning poker. Contrairement à ce que cela laisse entendre, il ne s’agit pas de planifier mais d’estimer. Il ne s’agit pas non plus de poker d’ailleurs[1].

Comme le dit très bien Mike Cohn, le planning poker permet d’obtenir une estimation des histoires d’utilisateur(user stories) en points(les story points).

Quelques commentaires suite aux démos de Wilos et Icescrum auxquelles j’ai participé hier en tant que directeur de produit : le public n’apprécie pas d’attendre plusieurs minutes avant le début réel de la démo. L’installation et le raccordement au vidéo-projecteur doivent être rapides ou préparés avant il convient de préciser le contexte de l’installation (serveur, en local ?) et décrire les données de test éventuellement utilisées pour la démo il n’est pas utile de faire de présentation sous forme de diaporama avant la démo la démonstration ne s’adresse pas uniquement au directeur de produit.

La vélocité est une mesure associée à une équipe pour un sprint. Elle se calcule juste après la démonstration lors de la revue de sprint.

Dans la famille Agile, il y a Scrum, il y a XP et on trouve aussi la modélisation Agile.

Scrum donne un cadre dans lequel on peut appliquer des pratiques de modélisation Agile, de la même façon qu’on peut y inclure des pratiques XP, comme les user stories, la vélocité, le TDD…

Je viens de lire un article du Journal Du Net sur la méthode Agile Scrum. Je trouve l’explication très approximative, avec des choses bizarres comme les “4 activités qui s’enchaînent dans un sprint” et l’utilisation de “processus non linéaire” pour qualifier Scrum, ce qui me laisse perplexe. On pourrait aussi discuter de l’insistance à limiter l’utilisation de Scrum à de petites équipes. Modification du 16 février : l’article du JDNet a été revu suite à mes propositions (voir le billet Correction d’article).

L’objectif de la mêlée quotidienne[1] ou scrum est de : Evaluer l’avancement du travail Identifier les obstacles nuisant à la progression Garder l’équipe concentrée sur l’objectif du sprint Améliorer l’esprit d’équipe Permettre une communication objective sur l’avancement D’un autre côté Scrum donne un cadre pour l’organisation de ces réunions : durée limitée à 15 minutes tout le monde debout 3 questions posées à chaque membre de l’équipe : Qu’as-tu fait depuis la dernière fois?

La pratique habituelle de gestion de projet consiste à estimer la durée de la tâche avant de la commencer, de relever les heures passées effectivement et d’analyser les écarts constatés. Avec Scrum, on estime aussi la tâche, et on la ré-estime régulièrement (tous les jours !) pendant son déroulement. Cette ré-estimation s’appelle le reste à faire (RAF). On se préoccupe pas des heures consommées. Une erreur serait de croire que le RAF est l’estimé au départ moins le consommé.

La notion de backlog n’est pas très difficile à comprendre : c’est une liste dont les éléments sont rangés par priorité. Mais le fait qu’il y ait plusieurs backlogs peut induire une confusion dans la compréhension de Scrum. L’article du JDNet dont je parle dans un billet récent parle de 3 backlogs : un backlog de produit, un backlog de release et un backlog de sprint. C’est une mauvaise interprétation, il n’y a en réalité que 2 backlogs[1] dans Scrum.

La rétrospective, qui fait partie intégrante de Scrum, est probablement la réunion qui est la plus négligée dans la pratique et c’est dommage parce que c’est un bon moyen d’améliorer le processus, moins lourd que le CMM-I…

La rétrospective est une réunion qui vient après la revue du sprint[1].

Scrum recommande que les membres de l’équipe soient invités à répondre à 2 questions :

• qu’est-ce qui s’est bien passé pendant ce sprint ?
• qu’est-ce qui pourrait être amélioré pour le prochain sprint ?

Dans un billet précédent, je commentais un article du JDNet sur Scrum. Voici la version améliorée… L’auteur de l’article m’avait suggéré dans un commentaire sur ce billet de proposer des améliorations. C’est ce que j’ai fait. Mais comme il ne se manifeste pas et que l’article n’a pas été modifié sur le site du JDNet, je vous livre ma version améliorée, paragraphe par paragraphe. Xavier Borderie vient de me signaler (16 février) qu’il a repris la quasi-totalité de ma réécriture et que la nouvelle version est en ligne.

En français !

Mardi j’animais une rétrospective. On m’a remonté des difficultés à estimer des histoires d’utilisateur en points. Puis une fois l’estimation faite, les doutes qui persistent sur la qualité de ces estimations :

Et si une pour une histoire que nous avons estimée à 3 points, on s’aperçoit que finalement elle vaut 5 points ?

Vendredi lors d’une revue de sprint, j’ai assisté à la présentation d’un tableau montrant la liste des tâches du sprint qui se finissait. Pour chaque tâche, l’orateur (le ScrumMaster) a présenté l’estimation en heures faite au début du sprint et le nombre d’heures effectivement passées sur la tâche, en essayant de justifier les écarts.