2008, l'envol de l'agilité

L’agilité devient mainstream ? Non, pas encore.

Un petit retour sur le SigmaT4

Un petit retour sur le SigmaT4

C'était le 14 décembre…

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. Après avoir rappelé l’esprit des SigmaT, j’ai fait une courte présentation de Scrum pour introduire la démonstration d’IceScrum.

Le reste à faire sur une tâche

RAF !

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.

Préparation du backlog pour la release de mars d'IceScrum

Frog and backlog

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. Après les retours encourageants suite à la démo au SigmaT4, nous avons fait un tour d’horizon de tout ce qu’il y avait à améliorer dans l’IHM de la version actuelle et de toutes les idées émises pour enrichir le produit.

Bonnes rencontres

Le succès des RencontresAgiles2007 a confirmé l'engouement autour du mouvement agile perceptible depuis mi 2007

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. L’idée de ces rencontres était de présenter des retours d’expérience (le slogan était no bluff just stuff). Dans le même esprit que les SigmaT que j’organise à Toulouse, mais avec un format plus court pour les présentations (20 minutes).

Ma présentation aux Rencontres Agiles 2007

Retours d'expérience sur l'introduction de Scrum

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. Pour rester dans l’esprit du no bluff just stuff -ça me plaît ce slogan- et des retours d’expérience, j’ai proposé de présenter mon retour d’expérience à moi, sur les projets que j’ai aidés à utiliser Scrum[1] au cours de ces 2 dernières années.

Contrôle des connaissances

Savoir analyser un burndown chart de sprint

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 oeuvre sur leurs projets.

La liste des problèmes

Impediment backlog en anglais

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. A ma connaissance, seul Jeff Sutherland l’a évoquée brièvement dans un billet sur les 3 questions du scrum meeting.

Mes semaines avec Scrum

Passent les jours et les semaines, les réunions sont les mêmes

Depuis fin novembre, je passe mes semaines entre Paris et Toulouse, à faire du coaching sur des projets Scrum. Pour mon client à Paris, je passe l’essentiel de mon temps avec une équipe qui débute avec Scrum. J’assiste le ScrumMaster et le Product Owner, en montrant l’exemple. Je mets en place les outils pour gérer les backlogs dans le site d’équipe, qui est fait avec SharePoint. J’ai également mis en place un projet de transition, qui a pour objectif de capitaliser l’expérience de mise en place de l’agilité pour la diffuser dans l’entreprise.

Success Story Scrum dans 01 Informatique

Avec l'avis du consultant

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

Sex Pistols Driven Agile Development ?

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. J’apprécie énormément ce qu’écrit Jeff Patton et en plus il a de la culture musicale : à côté des Sex Pistols, il utilise (et fournit le mp3) des paroles de chansons des Beatles, Paul Simon, The Who et Pink Floyd.

Sharepoint pour le backlog

Avec l'utilisation des listes

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 Mon client actuel utilise SharePoint pour les sites d’équipe, c’est à dire que SharePoint sert de référentiel pour tous les documents produits pendant le développement.
De nouvelles cartes pour le Planning Poker

De nouvelles cartes pour le Planning Poker

Estimer devient un jeu…

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. Le Planning Poker commence à avoir du succès comme technique d’estimation. On trouve des cartes sur Internet, on en parle dans des blogs et on l’applique sur le terrain. Parfois on en fait sans le nommer comme ça, en disant simplement réunion d’estimation ou réunion de planification en commun parce que jouer aux cartes dans une entreprise c’est pas dans les moeurs.

Que faire avec les exigences non fonctionnelles ?

Les mettre dans le backlog, comme tout le monde !

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. Dans OpenUp c’est le terme Supporting Requirements qui est utilisé et c’est mieux que le Supplementary Requirements du RUP. Cela concerne : les qualités d’exécution comme l’usabilité, la fiabilité, la performance. les qualités de développement comme la maintenabilité, la portabilité… les contraintes de conception, de déploiement, de conformité à des standards… Le backlog de produit a vocation à contenir tout ce qui apporte de la valeur, le fonctionnel, comme ce qui est non fonctionnel.

Scrumeries et agilitudes

Ce serait le nom de mon blog si j'en commençais un maintenant

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 :

Le backlog de produit n'est pas une todo liste

Un élément du backlog doit amener de la valeur, en principe

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. Par ailleurs, je découvre aujourd’hui, dans le backlog d’un des projets que je suis à distance sur GoogleDocs, un nouvel élément qui est intitulé : préparation de la revue.

Le backlog de produit est un outil de communication

On peut essayer la télépathie pour le communiquer efficacement…

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 On peut produire, à partir du backlog, des informations pour le suivi (burndown chart ou courbes diverses).

La release à points

Gestion de projet agile

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 ? Il y a la façon adaptative : la fin de la release n’est pas fixée, elle est envisagée à la fin de chaque sprint. On parle de release ajustable. Il y a la façon prédictive : la date de fin de la release est décidée, c’est ce qu’on appelle une release à date fixée.

Pas de points pour les bugs ?

Que faire des bugs relatifs à une user story et découverts dans un sprint postérieur à la réalisation de cette story ?

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 ?

Sprints à vélocité réduite

Cette semaine, j'avais 2 revues de sprint

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. Des revues de sprint basées sur des démonstrations, effectuées les 2 fois en présence de personnes extérieures à l’équipe très intéressées par le produit. Parmi ces personnes, des utilisateurs ou futurs utilisateurs, ce qui a permis d’avoir de nombreuses questions sur les fonctionnalités montrées.

Mesures agiles

Il n'y a pas que la vélocité

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 :

Bientôt le SigmaT5

Bientôt le SigmaT5

Le rendez-vous trimestriel de la communauté agile toulousaine

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). Les SigmaT se proposent de réunir régulièrement les praticiens des méthodes de développement Agiles et tous les professionnels et décideurs qui souhaitent s’informer sur ce mouvement novateur en plein essor.

Des initiatives pour une certification plus appropriée

Vers un réseau social ?

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. A la lecture du blog de Kane Mar, je vois que la certification de coach Scrum va bientôt être publiée. C’est déjà plus sérieux mais j’ai l’impression que ça reste très centralisé et verrouillé par la Scrum Alliance.

Implication du Product Owner

Le Product Owner n'est pas simplement le représentant des clients et utilisateurs. Il fait partie de l'équipe et participe activement aux travaux pendant un sprint

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.

Scrum de printemps

Scrum de printemps

C'est cool de scrummer dans les pâquerettes

Aujourd’hui, il faisait très beau à Toulouse. Soleil et plus de 20°. Nous avons fait le scrum de scrums de Wilos dehors, assis en rond dans l’herbe.