2008, agilité mainstream ? - Scrum, Agilité & rock'n roll

Entre 40 et 50[1] personnes ont participé à ce quatrième SigmaT. A noter qu’une seule personne —à part moi— a participé à tous les SigmaT : c’est Frédéric. Pas mal de nouvelles têtes cette fois-ci. Des nouveaux très sympathiques et enthousiastes pour l’agilité et la convivialité : l’apéro a commencé à 18h45 et s’est fini à 20h15. Il ne restait plus que du jus de fruit.

C’était la semaine dernière, au cours du scrum quotidien. Le premier scrum du premier sprint. J’étais le ScrumMaster. Chacun prit la parole à tour de rôle.

Hier soir, dans l’atmosphère désormais non enfumée du Frog, avec l’aide de quelques pintes de bonne bière, s’est tenue une réunion informelle pour préparer la release de mars d’IceScrum. Il y avait Vincent le ScrumMaster et Stéphane le Product Owner.

Plus de 150 personnes présentes pour les RencontresAgiles2007 du 18 décembre pour plus de 4 heures de présentations non stop. J’ai dû partir avant la fin (je suis resté de 8h30 à midi), j’avais une réunion de planification de sprint en début d’après-midi chez un client.

J’avais été sollicité en novembre pour faire une présentation aux Rencontres Agiles. Je ne pensais pas faire le déplacement de Toulouse spécialement, et puis finalement une nouvelle mission m’a conduit à Paris à cette date-là, alors j’ai accepté avec plaisir… Je remercie chaleureusement Bernard Notarianni et Didier Girard de m’avoir fait confiance, alors qu’ils ne me connaissaient que par mon blog.

Cette année à l’IUP ISI, une Unité d’Enseignement (UE) était dédiée aux méthodes agiles. Elle était programmée au premier semestre et s’est donc terminée en décembre. Un étudiant doit être évalué pour une UE, j’ai donc proposé un examen (il y avait aussi un contrôle continu). Une des 2 questions portait sur la gestion de projet agile, que les étudiants ont vue en cours, avec des travaux pratiques, et qu’ils mettent en œuvre sur leurs projets.

Les présentations de Scrum abordent abondamment le backlog -le backlog de produit- et la façon dont il vit pendant le projet. Certaines s’aventurent jusqu’au backlog de sprint, que je préfère appeler la liste des tâches du sprint. Peu abordent la notion de problème (impediment) et surtout la façon de les gérer.

Depuis fin novembre, je passe mes semaines entre Paris et Toulouse, à faire du coaching sur des projets Scrum.

J’ai reçu ce matin le 01 Informatique[1] n° 1932 du 17 Janvier 2008. Avec un petite carte d’Armelle Siccat placée entre les pages 54 et 55. C’est la journaliste qui a écrit l’article titré “Comment… il a refondu l’application Vidal Expert en dix mois”. Elle raconte comment le projet de migration en Java a réussi, grâce à Scrum. Elle évoque quelques éléments de Scrum tirés de l’expérience Vidal : le sprint planning-un des points difficiles chez Vidal-, le backlog[2] et le la scrum meeting.

Je ne sais pas ce que je veux mais je sais comment l'obtenir

Jeff Patton raconte sa présentation Embrace Uncertainty du XPDay2007 dans un billet dont le titre “Don’t know what I want, but I know how to get it” reprend une phrase des Sex Pistols dans Anarchy in the UK.

Un backlog de produit peut se concrétiser sous différentes formes. Dans les différents projets auxquels j’ai participé, j’ai utilisé : des fiches bristol épinglées sur un tableau une feuille de calcul d’un tableur OpenOffice ou Excel une feuille de calcul partagée avec GoogleDocs, ce qui est déjà beaucoup mieux qu’un simple tableur un outil dédié, IceScrum bien sûr, ce qui est encore mieux

De nouvelles cartes pour le Planning Poker

J’avais déjà quelques jeux de cartes pour le Planning Poker. Je viens de recevoir de nouvelles cartes, fabriquées par PlanningPokerCards.com. Avec ça, je peux faire des séances d’estimation du coût de développement pour de belles équipes.

Dans le backlog de produit, on met des user stories. La technique des user stories permet d’identifier les exigences fonctionnelles. Mais il y a d’autres exigences[1], qualifiées de non fonctionnelles, parfois d’exigences techniques.

J’avais prévu un article sur la certification (il y a des nouveautés) mais comme je fatigue un peu après une journée de travail (et un train de nuit) -c’est pas si facile que ça la vie de consultant Scrum- et que le sujet est polémique, je ne me sens pas de le faire ce soir. Ce sera pour une prochaine fois et aujourd’hui je vais me contenter de mentionner 2 billets trouvés chez Brian Marick dont la lecture m’a détendu :

Dans un commentaire de mon dernier billet sur les exigences non fonctionnelles, JML suggère de mettre également dans le backlog de produit les actions décidées lors de la rétrospective. Il donne l’exemple de l’automatisation des tests d’intégration pour les lancer lors du build.

Le backlog de produit recueille pas mal de choses éparpillées d’habitude dans plein de documents différents. On y trouve : une liste des User Stories, ce qui correspond -au moins en partie- à ce qu’on trouve dans un document de spécifications fonctionnelles un rangement par priorité, ce qui, couplé à des estimations en points, permet d’obtenir un planning de la release éventuellement, les tests associés aux stories

Une release est une série de sprints successifs. C’est une période de temps. Comment et quand déterminer la fin de la série et donc la fin de la release ?

Ah, un post très intéressant et très concret d’Eric Lefèvre. Eric parle d’un problème qui se pose couramment, qu’est ce qu’on fait des bugs relatifs à une story et découverts après que cette story ait été considérée comme finie ?

Cette semaine, j’avais 2 revues de sprint, mardi pour la fin du sprint 3 chez mon client à Paris et hier pour le sprint 2 de la release de mars sur le projet IceScrum.

La mesure la plus connue dans les méthodes agiles est probablement la vélocité. Mais il y a d’autres mesures simples à faire lors d’un développement agile permettant d’obtenir des indicateurs et des courbes (burndown charts, courbes diverses). Au cours de chaque sprint, on peut mesurer :

Après le succès des 4 SigmaT précédents, voici que se profile le cinquième du nom. Ce séminaire d’information gratuit sur les méthodes agiles aura lieu le 28 mars. Ça se passe toujours à Toulouse (le T, et le rouge et noir).

J’ai déjà dit ce que je pensais de la pseudo-certification connue sous le nom de certification ScrumMaster : c’est du pipeau. Devant les nombreuses critiques, la Scrum Alliance avait lancé une initiative en juin 2007. J’en avais parlé dans ce billet.

Le rôle de Product Owner(PO) ou Directeur produit est important dans Scrum. Il faut un PO et il faut qu’il s’implique dans le projet. Par qui ce rôle est tenu est une question à laquelle il y a plusieurs réponses possibles selon l’organisation en place et les compétences des candidats potentiels.

Ce rite quotidien constitue un point de rencontre entre tous les membres de l’équipe pour garder la focalisation sur l’objectif du sprint en cours.

Evaluation de la collaboration dans une équipe

Cette importance de l’humain est bien connue mais pas toujours appliquée dans nos organisations hiérarchiques. Les méthodes agiles cherchent à favoriser absolument cette idée de collectif, à travers, notamment, les réunions et les travaux en groupe. Comment savoir si ça fonctionne ? Évaluez votre niveau…

Dans les applications Web, il existe souvent un rôle secondaire qui a accès à des informations seulement en lecture et qui a besoin d’une ergonomie particulière, soit parce que les personnes qui jouent le rôle ne sont pas expertes dans l’utilisation de l’outil informatique, soit parce que les informations doivent constituer un tableau de bord facilement lisible et permettre d’avoir une vue synthétique. L’ergonomie est essentielle et fait que ces exigences ne sont pas des histoires comme les autres.

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système. Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs. Pour décrire les tests d’acceptation, ma préférence va à une technique orientée comportement, le BDD.

Mercredi, lors de la réunion de planification du sprint que j’animais, nous avons inclus dans le sprint plusieurs spikes. On utilise un spike pour mener des travaux d’étude, d’exploration technique d’un élément (user story) du backlog.

C’était hier une journée Mai 68 sur France Inter, qui a pris de l’avance en célébrant le Mouvement du 22 mars. L’évocation des événements m’incline à estimer qu’une des raisons qui me font adhérer avec enthousiasme aux idées du mouvement agile, c’est qu’elles me rappellent l’esprit de Mai 68, qui a irrigué mon adolescence. On retrouve dans le mouvement agile cette remise en question de l’ordre établi et quelques idées en commun. En particulier un principe essentiel des méthodes agiles est celle de l’équipe qui se gère toute seule (empowered team).

La revue de projet IceScrum2, dans le cadre de l’année scolaire 2007-2008 pour les étudiants de l’IUP ISI, a eu lieu vendredi dernier. 6 mois de travail qui ont abouti à un résultat tout à fait intéressant qui sera présenté lors du SigmaT5 de vendredi. Pour qu’un outil comme IceScrum soit utilisé, il faut qu’il facilite la vie dans l’utilisation de Scrum. La qualité de l’ergonomie et l’utilisabilité du produit seront déterminantes. Les leçons tirées des premières versions d’IceScrum et l’utilisation d’Ajax ont permis d’apporter des avancées significatives dans ce sens.

Par Infoq, je viens de lire un article Well Formed Teams and Agile: An Opportunity to Thrive qui définit 3+2 attracteurs pour penser efficacement et constituer des équipes hyper-productives, comme dit Jeff Sutherland.

Les SigmaT sont destinés aux personnes qui pratiquent les méthodes agiles mais aussi à celles qui ne le font pas encore et souhaitent s’y mettre. Cela se passe à Toulouse, mais au delà des Toulousains, les SigmaT accueillent des participants du grand Sud-Ouest : le 28 mars, nous aurons des visiteurs de Montpellier et Bordeaux ainsi que de Montauban. Les SigmaT abordent l’agilité sous toutes ses facettes et s’adressent à toutes les personnes impliquées dans le développement ou le management des projets. Ils incluent également l’aspect enseignement avec la participation d’étudiants qui apprennent les Méthodes Agiles et les appliquent sur leurs projets.

Il y a presque 2 ans, j’avais développé un plugin Scrum avec le Composer d’Eclipse Process Framework. J’avais l’objectif d’ajouter des tool mentors pour IceScrum (j’ai commencé avec la version 1 de IceScrum, maintenant abandonnée). La communauté EPF s’était montrée intéressée par mes travaux et je leur ai fait une donation en décembre 2006, qui avait été publiée sur le site EPF. Depuis mon plugin en français a été traduit en anglais. En lisant le dernier compte-rendu de la communauté EPF, j’apprends d’ailleurs que Mike Cohn liked the published web site.

Un tableau de tâches sert à montrer l’avancement des travaux pendant le sprint, c’est une représentation physique du backlog de sprint. Il est élaboré lors de la réunion de planification du sprint. Pour chaque story sélectionnée, l’équipe identifie les tâches correspondantes. Sur le tableau, les stories et les tâches sont placées avec des notes collantes. L’état des tâches est reconnu selon la place de la tâche dans des zones représentant chaque état : à faire, en cours et finie.

J’ai commencé ce blog il y a tout juste 2 ans. C’était l’époque du CPE, il y avait encore Chirac, nous devions être une centaine seulement à connaître Scrum en France. Une autre époque quoi ! J’ai réussi à écrire près de 400 billets, ce qui fait en moyenne un peu plus d’un tous les 2 jours. Ce n’est pas facile de maintenir le rythme surtout ces 4 derniers mois où je suis en déplacement à Paris presque toutes les semaines.

Au cours du sprint, bien avant la fin, l’équipe a produit un build, permettant de passer des tests d’acceptation. Le product owner (ou un testeur) a du temps pour tester ce build. Le problème, c’est qu’il n’est pas physiquement proche des développeurs quand il utilise le build et passe ces tests. C’est dommage mais that’s life.

Je fais partie d’un club de tarot et j’y joue les vendredis soirs. Nous avons eu une partie qui a engendré de nombreuses discussions enflammées. André prend une garde, il récupère 2 atouts au chien. C’est lui qui entre. Atout, du 13. Juste après lui, Bernard met le 20. Derrière Pierre met un petit atout et moi aussi. Bernard fait donc le pli et rejoue dame de coeur. Pierre a en main 6 coeurs dont le roi. A votre avis, que doit-il jouer ? Il se trouve que Pierre n’a pas mis son roi et qu’André a fourni. Bernard a fait le pli avec la dame et été obligé de faire une nouvelle entrée. André a fait le pli et a rejoué atout, prenant le petit de Bernard.

Une discussion récente avec un acheteur d’une grande administration m’a conforté dans l’idée que le contrat au forfait n’est pas un obstacle à l’introduction de l’agilité. Au contraire, l’agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels. Voici un petit résumé des quelques idées que je lui ai présentées, reprises de ma contribution au livre de Véronique Rota :

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences.

Je termine demain ma mission à Paris. Presque 5 mois à mi-temps, à faire du coaching pour un Scrum Master et un Product Owner et les aider à mettre en œuvre Scrum sur un projet. J’avais commencé par former l’équipe à Scrum et, à côté de ma participation au projet, ma mission consistait aussi à capitaliser les pratiques agiles pour les insérer dans le cadre méthodologique de l’entreprise. Intéressant mais pas facile tous les jours, en particulier avec le rôle de Product Owner, dans un milieu pas vraiment favorable à l’agilité au départ : structure basée sur une séparation MOA MOE qui, en général, ne facilite pas la transition à l’agilité

La connaissance attendue de Scrum n’est pas la même pour des personnes qui participent à un projet que pour celles qui le suivent et, dans une équipe qui applique Scrum, pour un ScrumMaster que pour un simple membre de l’équipe. La stratégie de formation doit tenir compte des rôles et des projets.

Courant mai, je visite des étudiants de l’IUP ISI en stage dans les entreprises toulousaines. Pour l’instant, j’ai vu 3 étudiants. Tous travaillent sur des projets innovants et utilisent des technologies de pointe. Côté méthode, 100% des projets utilisent Scrum. Les étudiants sont parfois amenés à expliquer Scrum à des collègues. Dans une entreprise, j’ai vu un beau tableau des tâches (horizontal) avec des notes collantes au mur de la salle de réunion. Dans l’autre, c’est IceScrum qui est utilisé intensivement. Des initiatives venant des étudiants en stage et acceptées et même encouragées par les entreprises.

Emmanuel Chenu a publié des illustrations sur les principales pratiques de Scrum et de l’Agilité. Les dessins sont en anglais et les commentaires qui les accompagnent sont en français. C’est sympa, mais pourquoi sont-ils tous chauves ? Dans un genre différent, j’utilise maintenant les icônes de IceScrum pour illustrer les rôles Scrum dans mes formations et mes présentations Vous avez reconnu les différents rôles ?

La mécanique de Scrum repose sur la réalisation d’un élément du backlog en un sprint. A la fin du sprint, l’élément du backlog sélectionné pour ce sprint est normalement fini. Fini ? Fini fini, c’est le credo de Scrum ! Et quand c’est fini, ça ne recommence pas ! Fini ne signifie pas la même chose pour tout le monde. Lors de mes formations ou de mon coaching, je pousse les équipes à définir leur notion de fini et à l’afficher.

Mi avril, je m’étais mis d’accord avec un charpentier pour la construction d’un appentis. Il s’était engagé à faire les travaux en mai. Je l’appelle hier, il me dit : vous comprenez, avec tous ces ponts, on a pris du retard, je ne pourrai venir chez vous qu’en juin. Ce que je comprends surtout c’est que le 17 avril, il n’avait pas pensé qu’il y aurait des ponts en mai pour ses prévisions de travaux. Après tout, les artisans ne sont pas formés à la gestion de projet.

Il y a une dizaine d’années, disons entre 1996 et 2000, le langage de modélisation UML était considéré comme l’espéranto du développement de logiciel. Le U de unifié pouvait même servir pour universel. Tous les développeurs étaient encouragés à utiliser UML[1]. Quel que soit le jugement qu’on peut porter sur les qualités et les défauts d’UML, force est de constater qu’aujourd’hui sur le terrain, UML n’est pas très utilisé par les équipes de développement. Pourquoi ? Un billet donne 13 raisons pour la descente d’UML dans les ténèbres. L’article est polémique, en tout cas il attire beaucoup de commentaires de développeurs qui s’y reconnaissent.

Je faisais en début de semaine une formation de sensibilisation aux méthodes agiles. Quand j’ai parlé de l’autonomie de l’équipe et que j’ai expliqué que c’est l’équipe qui identifie les tâches et chacun qui les prend, j’ai eu une question : et si des tâches pénibles ne sont prises par personne ?

Plutôt que ruminer sur la défaite cruelle du Stade Toulousain, j’ai fait un petit tutorial qui vous aidera à expérimenter IceScrum. Je vais décrire comment constituer un backlog de produit initial, créer une release et ses sprints, faire une planification de release et aller jusqu’au démarrage du premier sprint. Cette phase de préparation est aussi appelée sprint 0.

L’année dernière et encore en début de cette année, je suis intervenu, pour des formations et du coaching, majoritairement dans des grandes entreprises ou des administrations : Total, Areva, Sagem, Siemens/Continental, Banque de France… La tendance s’inverse. En quelques semaines, je viens de donner chacune de mes 3 formations Agile/Scrum dans des plus petites entreprises oeuvrant dans des technologies de pointe :

En complément au billet du JC, mon camarade blogueur de Quality Street, sur l’intérêt d’avoir une bonne vision, je joins un plan type avec guide de rédaction, au format OpenOffice.