2007, l'essor de Scrum

Scrum prend son envol.

Correction des copies

J'ai posé quelques questions pour les partiels de décembre des étudiants et maintenant me voilà avec une pile de copies à corriger…

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.

Pratiquer Scrum à 33

Pratiquer Scrum à 33

Dites 33

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.

Le backlog de sprint

Alias le plan d'itération

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é.

Communiquer les tests d'acceptation aux développeurs

Quand et sous quelle forme le directeur de produit fournit les critères de tests d'une histoire d'utilisateur ?

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 :

Le cycle de vie en V n'existe pas

Le cycle de vie en V n'existe pas

J'entends parfois : les méthodes agiles c'est bien mais chez nous on utilise encore le cycle de vie en V alors…

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.

Un deuxième SIGMAT

Et son backlog

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.

Session d'estimation en groupe avec des cartes

Planning poker, c'est plus fun ?

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).

La démonstration lors de la revue de sprint

La revue de sprint commence par une démonstration du produit partiel réalisé lors du sprint.

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é d'un sprint

La vélocité est la mesure de la capacité de l'équipe pendant un sprint

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.

Modélisation agile du domaine

Scrum ne traite pas l'aspect modélisation. Ce n'est pas une raison pour ne pas en faire.

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…

Littérature en français sur Scrum

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).
Aide visuelle pour les mêlées

Aide visuelle pour les mêlées

La réunion qui a donné son nom à Scrum est plus efficace si l'équipe dispose d'une aide visuelle comme le tableau des tâches

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?

Pas de relevé des heures avec Scrum

L'estimation du temps qu'il reste à passer sur une tâche est plus importante que la mesure du temps qu'on y a passé

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é.

Les backlogs de Scrum

Le backlog est un élément clé dans le processus Scrum. Mais il y a plusieurs backlogs…

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.

Rétrospective du sprint 5 d'IceScrum2

Rétrospective du sprint 5 d'IceScrum2

En étoile de mer

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 ?

Correction d'article

Reformulation de ce qu'est la méthode agile Scrum dans un article du Journal du Net

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.

Une estimation n'est pas un engagement

Cette semaine, au cours de réunions avec des équipes différentes, j'ai eu l'occasion de constater que la croyance qui consiste à considérer une estimation comme un engagement est tenace

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.