Hier soir le ParisJug proposait un thème un peu différent en abordant Scrum : la star montante des méthodes agiles.
J’hésitais un peu à y aller, craignant que les présentations soient plus de l’introduction à Scrum. Puis je me suis décidé pour voir Eric Mignot de chez Pyxis, voir le Touilleur (aka Nicolas Martignole) faire sa première et pour revoir Guilaume Bodet qui avait fait une très bonne présentation au Scrum User Group en mars. Bien m’en a pris, car la soirée était très instructive !
Première présentation
La première présentation, sous la forme d’un dialogue, a été une introduction à Scrum. Le Touilleur en a profité pour ressortir sa métaphore de la machine à laver.
Je ne ferais pas un topo complet de cette présentation qui a principalement reposé les bases de Scrum et du manifeste agile, mais j’ai cependant bien aimé certaines idées avancées par Eric Mignot.
Notamment : apprendre Scrum c’est désapprendre autres choses (avec en cible de mire les processus lourds et parfois incohérents imposés par certaines méthodes).
L’idée véhiculée tout au long de cette présentation est que les méthodes agiles ne doivent pas être vues comme une méthodes à appliquer aveuglement « out of the box ». Les méthodes agiles sont là pour nous faire réfléchir sur ce que l’on fait, et pour nous redonner le goût de faire du dev. Pour cela, elles proposent un ensemble d’outils, mais elles ne doivent pas être vues comme une méthode à part entière.
Le but ce n’est pas de faire du scrum, mais de s’améliorer. Ainsi, pourquoi pas introduire petit à petit le daily Scrum ou bien la démonstration post itération tous les mois ?
Je vous ai refait au propre le schéma d’Eric qui synthétise assez bien Scrum ci-dessous :
Info intéressante, Eric estime que la vélocité sur un projet se stabilise au alentour du 5ème ou 6ème sprint.
Deuxième présentation
La deuxième présentation, proposée par Guillaume Bodet a été encore une fois extrêmement enrichissante. Guillaume nous proposait de confronter la réalité de l’introduction de Scrum sur les équipes en place.
Premier problème, comment trouver un Product Owner ? Pour cela, et contrairement à ce que la littérature propose on se rend compte fréquemment :
- que le product owner n’est pas forcément seul
- qu’il n’est pas forcément responsable de tout
- qu’il n’est pas forcément un visionnaire
On n’a pas tous un Steve Jobs dans nos entreprises. Le rôle de du product owner est avant tout un rôle logique.
Deuxième problème comment on démarre un projet agile et comment on constitue un Backlog de produit.
Pour démarrer un projet il faut au mininum :
- la taille estimée du projet
- le ROI
- la liste des principaux risques
- la composition de l’équipe
Le tout pouvant tenir dans un document d’une dizaine de pages max.
A partir de ceci on obtient le go du projet et on peut partir sur un Sprint 0 avec une équipe réduite. A l’issu de ce Sprint le Product Owner, aidé par l’équipe, aura créé un premier backlog de produit.
Le burdown chart a ensuite été évoqué. La notion intéressante est de mettre en avant deux courbes, une qui montre les stories implémentées à partir de l’estimation initiale, l’autre pour montrer l’ajout de story (ou le retrait) ou la réévaluation des tâches. C’est plus motivant et vendeur de voir un burdown qui globalement est en baisse.
Guillaume nous livre la difficulté rencontrée de vendre le burdown aux comités de direction, habitués au diagramme de Gantt et aux jalons clairs. Il convient selon lui de maintenir à jour 5 niveau de planification :
- daily (quotidienne en heures)
- itération (toutes les 2 semaines)
- releases (trimestriel)
- product roadmap (semestriel)
- product vision (annuel)
La scalabilité de Scrum a ensuite été mise en avant au travers de plusieurs retours d’expérience. Le but est d’avoir ses équipes de Scrum avec chacun un ScrumMaster. Puis les ScrumMaster se retrouvent tous les 2/3 jours avec un « Meta ScrumMaster » qui est le ScrumMaster des ScrumMasters. Le principe s’applique en théorie sur n’importe qu’elle profondeur (j’ai déjà vu ça dans des présentation de Yahoo).
Sur le projet ProRail au Pays-bas, 25 personnes étaient réparties en 4 équipes. La V1 a été livré au bout de 8 mois puis les releases s’en sont suivis tous les 3 mois.
Enfin, Guillaume a fini la présentation en parlant d’architecture.
Il met un léger bémol au principe d’architecture émergente. Selon lui, l’architecture doit quand même être réfléchi au début du projet, on sait globalement qu’elles vont être les besoins et on doit prévoir ce dont on aura besoin au minimum. Selon lui, les erreurs d’architecture peuvent être très lourdes à corriger (si c’est possible) si l’architecture est fondamentalement fausse.
Il a fini par présenter la notion d’architecte agile (que l’on trouve présenté sur le blog de Xebia)
L’architecte agile est cet architecte qui propose des règles flexibles plutôt que dogmatique.
D’après Scott Ambler (IBM) :
- piloter l’architecture par les besoins
- essayer de modéliser à plusieurs
- préférer la collaboration plutôt que la documentation (à quoi servent des best practices de centaines de pages si personnes ne les lit ni ne les comprend).
- faire simple (KISS)
- s’attaquer aux grandes problématiques tôt, régler les détails au moment voulu
- rester flexible
- publier les modèles d’architecture/métaphores.
Pour conclure, la soirée a été encore très intéressante. Merci aux présentateurs et au ParisJug pour ces présentations de qualité.
Un résumé très complet et avec photos est disponible également ici.
