2007, l'essor de Scrum

J’utilise DotClear pour mon blog et je n’avais pas beaucoup changé la présentation depuis son lancement

J’ai profité de la trêve pour améliorer ça. J’ai changé la présentation des billets.

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

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

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.