2008, l'envol de l'agilité

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.

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.

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

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.