2008, l'envol de l'agilité

Un burndown chart de sprint montre au jour le jour le reste à faire sur les tâches du sprint. Une de mes équipes a produit lors de son dernier sprint une variante de burndown qui montre en plus le reste à faire sur chaque story réalisée pendant le sprint.

Je corrige les copies. Une question de mon sujet d’examen portait sur les pratiques agiles. J’ai donné aux étudiants une liste d’une trentaine de pratiques, en leur demandant d’en choisir 6 pour les présenter et les expliquer. Je leur laissais le choix, donc je suppose qu’ils ont choisi celles qu’ils ont le mieux comprises.

La nouvelle version d’IceScrum, la R2#9, est enfin disponible dans les bacs.

Tous les ans, c’est pareil, il faut que je trouve un sujet pour l’examen du module Ingénierie du Logiciel Agile. Même 2 fois par an avec la repêche de septembre.

J’ai été invité à participer à la réunion mensuelle d’un groupe de praticiens parisiens. Comme j’étais justement à Paris ce soir, entre une formation Scrum pour un client et une rétrospective de sprint 2 pour un autre, j’y ai assisté.

Ceux qui ne connaissent pas trop l’agilité pensent parfois, à tort, qu’on ne peut pas planifier sur les projets agiles, parce que ça change tout le temps. Ils ont bien compris que le client pouvait faire des changements. Ils doivent en déduire :

À quoi ça sert de faire des plans s’ils sont remis en question ?

L’an dernier, j’avais fait un billet sur les features, stories, epics.

Aujourd’hui je revisite ces notions à l’occasion d’évolutions dans IceScrum, qui les embarque actuellement de façon pas très limpide. Pour simplifier l’usage, nous allons fusionner les notions de thèmes et de features, et nous appuyer sur des idées de Dean Leffingwell et Philippe Kruchten.

Une des réalisations dont je me souviens de ma vie de développeur, c’est l’écriture d’un générateur de code à partir de tables décrivant un automate. Plutôt un moteur d’automate, capable de lancer les actions élémentaires d’une transition suite à la réception d’un événement dans un état. A l’époque je travaillais à Telic-Alcatel dans le monde des autocommutateurs (PABX). Le comportement du poste téléphonique était décrit avec des automates à états finis. On disait simplement automate.

Attention, c’était de gros automates.

Même si on a fait une analyse des risques et mis en place une stratégie de réduction, des impondérables surviennent toujours sur un projet. Un impondérable (impediment) a pour effet de bloquer ou ralentir une ou plusieurs tâches en cours.

Pour empêcher ces impondérables de remettre en cause les engagements, il faut se garder du mou lorsqu’on planifie (c’est d’ailleurs aussi une stratégie de réduction des risques).

À la fin d’un sprint, il y a la revue et la rétrospective. Les plans sont actualisés et les rapports sont mis à jour. Mais toutes les partie-prenantes ne participent pas aux réunions et n’ont pas toujours un accès facile à ces rapports. Il peut être utile de diffuser un petit compte-rendu, sous forme de présentation, qui les contient.

Pour cela, j’ai un plan-type de présentation OpenOffice qui permet de produire un compte-rendu en quelques minutes, en y faisant figurer les informations importantes :

J’ai assisté ce matin à une présentation des projets des étudiants du Master1 de l’IUP ISI. Il s’agit des étudiants que je forme, avec d’autres, aux méthodes agiles (50 heures de cours et TD). Ils ont également des projets qui commencent en octobre et durent jusqu’en mars. Une équipe (motivée) qui travaille sur un projet peut y passer jusqu’à 2000 heures, ce qui permet de belles réalisations.

Dans son célèbre article Who needs an architect?, Martin Fowler distingue l’architectus reloadus et l’architectus oryzus :

James Shore qui l’a déclenchée avec son billet The Decline and Fall of Agile.

L’article est intéressant, les commentaires aussi. En (très court) résumé : il y a des risques de se planter avec Scrum si on est mal formé et il faut des pratiques d’ingénierie pour éviter la dette technique.

Dans son deuxième commentaire de mon billet sur la variation de périmètre, Zorro revient sur les courbes et s’y perd entre les notions de valeur, d’effort et de coût.

J’essaie d’éclaircir.

Le burndown chart montre l’effort qui reste à faire. Il est obtenu en collectant le nombre de points des éléments qui restent à faire dans le backlog de produit.

Ceci est une annonce commerciale ostensible : je vais animer une formation publique “Les Ateliers de l’Agilité” les 2 et 3 décembre 12 et 13 mars 2009 à Toulouse.

Entrer dans le domaine de l’Agilité implique d’acquérir un nouveau vocabulaire. C’est vrai en particulier avec Scrum et ses métaphores sportives (sprint, mêlée). Comme la plupart des termes viennent de l’anglais, le vocabulaire subit les aléas liés à la traduction. Ou à la non traduction si on garde le mot anglais.

Pour ne pas ajouter à ces difficultés de communication, il convient d’utiliser le bon vocabulaire. Lors de présentations ou de discussions, j’ai relevé des mots ou des expressions, qu’à mon avis, il vaudrait mieux éviter.

La première est le sprint0 (ou itération zéro).

J’ai donné il y a quelques jours une formation pour une grosse SSII. Il s’agissait de la formation d’une journée qui présente l’Essentiel de Scrum et des Méthodes Agiles. Le contenu est dense et la formation occupe bien la journée. J’ai donné cette formation 5 fois en un mois et, à chaque fois, quand je terminais le cours, les participants étaient pressés de rentrer chez eux ou d’aller voir leurs messages.

Mon interview dans 01, sur le modèle historique du contrat au forfait face à l’essor des méthodes agiles.

Cela faisait longtemps que je n’avais pas parlé d’OpenUp et du projet Eclipse Process Framework. Ce projet communautaire continue à vivre et à évoluer. Je viens de me mettre à jour, à l’occasion d’une présentation d’OpenUp à mes étudiants.

Les 100 premiers inscrits à la conférence Agile Tour de Toulouse ont reçu des goodies. Dans le sac estampillé Agile Tour, il y avait un jeu de cartes pour le planning poker, grâce à notre sponsor Agile Hardware.

Depuis mon dernier billet sur le sujet, pas mal de petits nouveaux.

J’ai lu le dossier sur les méthodes agiles dans 01 Informatique.

Un article du dossier revient sur la genèse des méthodes agiles, en remontant loin (1957 !). Dans la litanie des citations, on trouve RAD, pourquoi pas. Mais quand Scrum est abordé, je lis : …

Je fais de nombreuses présentations de Scrum. Rien que pour les séminaires SigmaT organisés à Toulouse (et à Montpellier), j’ai fait une introduction à Scrum presque à chaque fois. Cette fois pour l’Agile Tour, j’ai fait une nouvelle présentation, intitulée Scrum : des racines à la ScrumMania. Comme Scrum est maintenant beaucoup plus connu, j’ai préféré revenir sur les racines et montrer l’évolution plutôt que d’expliquer la mécanique, comme je le fais d’habitude[1].

Jeudi dernier lors de la conférence Agile Tour de Toulouse, Philippe Kruchten et moi avons fait un exposé intitulé L’Agilité en situation.

Comme Philippe vit à Vancouver, nous l’avions préparé en communiquant par Skype toutes les semaines. Cela a été très enrichissant de partager nos expériences de mises en application des pratiques agiles sur différents projets et dans différents contextes.