Avec 190 inscrits, encore une fois le Paris JUG a fait salle comble. Hier soir grâce à Eric « Bob » Mignot nous avons vu comment fonctionne Scrum. Je ne vais pas me lancer dans un résumé de notre présentation, car Olivier Croisier a posté un très bon résumé ce matin sur son blog, The Coder’s Breakfast.
La deuxième partie de la soirée a été animée par Guillaume Bodet, Directeur Technique de Xebia. L’objectif de la présentation est de répondre aux questions souvent posées par les clients que Guillaume rencontre, lors de la mise en place de Scrum. Le plan de la présentation :
– Trouver le product owner
– D’où vient le product backlog ?
– Et mon planning ?
– Mon projet est trop gros !
– Et l’architecture alors ?
Dans un premier temps, la difficulté est de trouver le Product Owner. Rappel de la théorie : il est le propriétaire du produit, il doit porter la vision du produit, il est en charge du ROI, du budget et du planning de livraison. Guillaume présente le meilleur Product Owner au monde : Steve Jobs !
Mais comment faire lorsqu’on a pas un Steve Jobs sous la main ? Tout d’abord il n’est pas forcément seul. Il doit par contre être responsable de tout et avoir une vision de ce que le projet ou le produit doit être.
Guillaume liste dans un slide une liste des rôles existants dans les structures qui font de bons product owner :
– Chez les Editeurs de Logiciels -> Responsable Produit
– Web -> Le Directeur Marketing
– Banque -> Chef de projet utilisateurs
– Industrie -> AMOA + users groups
Guillaume Bodet aborde ensuite le Product Backlog. D’où vient ce PB ? Selon la littérature Agile, il émerge un peu par magie, sans finalement donner des repères assez solides pour commencer. Par son expérience, il explique que le démarrage d’un projet peut se faire avec un document d’une dizaine de pages, avec des critères d’estimation de la taille du projet, une présentation du ROI, l’évaluation du risque et la définition d’une équipe. Lorsqu’il explique cela, je pense alors à un Business Plan. C’est clairement un document synthétique qui donne la vision d’un projet d’entreprise, qui présente la partie budget, les équipes, sans chercher à définir en détails le produit.
Il explique ensuite que les équipes de Xebia mettent en place des spécifications exécutables (TDD,TDR) afin d’aider le client à formaliser ses demandes. Contrairement à une idée reçue, Scrum ne supprime pas les documents de spécifications techniques ou fonctionnelles. Simplement, on cherche à être moins exhaustif sur les points qui ne seront pas développés en premier.
Le planning est important. Nous devons rendre compte de l’avancement. Il nous explique tout d’abord ce que les chefs de projets font en principe avec Microsoft Project et les diagrammes de Gantt. L’objectif d’un diagramme de Gantt est d’effectuer un ordonnancement des tâches, afin de communiquer un planning. C’est ensuite un outil qui permet d’assurer le suivi de l’avancement. Il parle d’un dérapage souvent rencontré en conduite de projet :
– vous définissez avec beaucoup d’efforts un planning type diagramme Gantt
– chaque jour vous collectez le temps passé par chacun des développeurs. Problème : que se passe-t-il lorsque le temps estimé déborde ? vous devez alors réadapter le diagramme afin de faire « rentrer » cette mise à jour
– vous perdez du temps pendant une heure à remettre à jour ce diagramme, pendant ce temps là vous ne faites rien de productif
– ensuite vous êtes débordé, donc un assistant chef de projet se charge de mettre à jour ce machin. Bravo vous faites preuve de délégation.
Bref le planning classique est parfois une souffrance, voire une grosse perte de temps. A cela, l’Agile répond : on ne fait pas de planning, ce qui n’est pas forcément mieux. Guillaume explique que scrum propose de faire des plannings de release, afin de s’assurer que le développement d’un produit ou d’un logiciel suit une roadmap, respecte la vision du product owner.
Guillaume parle aussi parfois de nous, praticiens de Scrum, qui tentont de vendre le Burndown Chart comme une prévision de l’avenir… ce qui n’est pas le cas. Il explique que c’est un outil destiné avant tout à faciliter la communication entre le Product Owner et l’équipe, ni plus ni moins. Pour terminer, j’ai apprecié sa vision de la plannification. Il y a 5 niveaux de plannification :
– au niveau quotidien, défini lors du stand-up meeting du matin
– au niveau de l’itération (sprint planning)
– au niveau de la release (release planning)
– au niveau de la vision du produit (roadmap)
– au niveau de la vision annuelle
Il rappelle qu’un plan fixe des objectifs, la planification permet ensuite d’adapter ce plan à la vraie vie. Pour preuves, il parle de la démarche d’Einsenhower, général durant la 2ème guerre mondiale et 34ème président des Etats-unis qui a juste réussi le plus gros projet de notre histoire : l’opération Overlord.
Les estimations et la plannification : c’est un sujet qui me passionne. J’ai bien aimé l’évocation de Cocomo II mais bon, il y a d’autres méthodes moins hype, je vous prépare un billet sur ce que je suis entrain de faire avec mon équipe en ce moment.
J’en profite pour vous proposer de relire un billet de décembre dernier : Devoxx les estimations de temps.
Ensuite Guillaume parle du cas des projets qui ne pourraient pas faire de Scrum car « ils sont trop gros »
Il partage tout d’abord l’expérience du Projet ProRail PUB, la refonte du SI du système des chemins de fer hollandais. Avec un budget supérieur au million, 25 personnes ont réalisé en 8 mois une première version. La v1 était opérationnelle. De nouvelles versions continues à être mise en production tous les 3 mois. Les gros projets se divisent en plusieurs équipes. La mise en place de Scrum of Scrum permet de coordonner le développement d’une plateforme. C’est donc possible, en conservant une taille respectable d’équipe (<15 personnes).
L’architecture ensuite est importante. Il casse le mythe des Agilistes qui vous disent que « l’architecture émerge » tel un iceberg… C’est faux. C’est au prix d’un travail d’analyse, de spécifications, d’études de faisabilité que les projets se construisent une architecture. Il a une pensée émue aussi pour les équipes d’Architecture transverse qui sont parfois déconnectées des équipes de terrain. Un architecte internet doit faire partie d’une équipe Scrum. L’architecture se pilote par le besoin, comme dit Scott Ambler. La modélisation doit se faire à plusieurs, il ne faut pas laisser à une seule personne le soin de décider d’une architecture : c’est bien trop dangereux. Enfin il rappelle l’importance de rester simple (et humble) et de penser qu’il est plus important de livrer un produit qui fonctionne, qu’une documentation exhaustive qui ne fait pas gagner d’argent.
En conclusion, j’ai trouvé que la présentation de Guillaume complétait bien la première partie.
Merci à l’équipe du Paris JUG de nous avoir donné l’occasion de faire 2 heures sur Scrum et les méthodes Agile !
Annonces et informations
En début de soirée, Tanguy Bayard a fait une présentation de 10 minutes vraiment sympa. Il a présenté le principe du Paris JUG à l’équipe de direction de SFEIR. Grâce à lui, SFEIR est devenu sponsor annuel du Paris JUG ! Franchement bravo et merci à SFEIR.
Oxiane est aussi un nouveau sponsor, vous pouvez lire leur blog très sympa, merci à Gabriel Kastenbaum.
Enfin Antonio a parlé du podcast « Les Cast Codeurs » dont je vous parlerai dans un autre billet.
🙂
The 3ème mi-temps
Enfin en 3ème partie de soirée, entouré de Florent Ramière, de David Gagot, de Jean-Michel Bea, de Sébastien Douche, de Cyrille Leclerc et de Thomas nous avons pas mal discuté de Google App Engine. Je pense qu’il y a beaucoup de restrictions et que de parler de Java alors qu’il y a tant de limitations, c’est un point important à ne pas négliger. David explique qu’en même temps nous parlons d’une version béta de ce support. Qu’avec le temps d’ici 6 mois nous aurons aussi apprivoisé ce nouveau système. Je demande à Florent si pour SpringFuse il serait prêt à basculer d’Amazon EC2 à Google App Engine (GAE). A vue de nez oui, maintenant en perdant une base de données ou un système de fichier, cela fonctionnera en utilisant le moteur BigTable. Il va y réfléchir, même si ce serait plus pour tester que pour vraiment s’en servir.
David et Florent parlent ensuite de Mockito versus EasyMock, après une discussion sur Citcon très intéressante. C’est sans doute la bonne bière qui m’a aussi convaincu de m’inscrire pour mi septembre ! Avec Thomas et Florent nous parlons aussi pas mal sur Google et le dernier Barcamp. Florent parle aussi des premiers retours des clients de SpringFuse, avec un démarrage très fort sur un gros projet entre autre.
Enfin voilà, fin de la 14ème soirée du Paris JUG. L’occasion encore de discuter entre geeks et passionnés, de voir que presque 200 personnes sont venues nous écouter présenter Scrum avec Eric.
Eric, merci à toi d’être venu. Départ le lendemain pour Bordeaux, tu étais la semaine dernière au Canada, je sais que tu bouges beaucoup mais merci d’être passé nous parler de Scrum.
Je vous prépare un podcast avec l’enregistrement de la soirée avec mon histoire de machine à laver 😉
0 no like
Un très grand merci pour cette très très bonne soirée au Paris JUG ! Une présentation originale, avec une bonne dose d’humour, mais pour autant avec un contenu vraiment intéressant.
Merci Nicolas et Eric
PS : Merci aussi à Guillaume pour la 2ème présentation, très réussie également et qui complétait parfaitement la première.
« A cela, l’Agile répond : on ne fait pas de planning, ce qui n’est pas forcément mieux. »
C’est une affirmation gratuite. Pourquoi ne serait-ce pas forcément mieux ?
Je suis curieux de savoir comment cet intervenant a présenté les plannings de release. Si c’est un planning qui se contente de dire « tel groupe de fonctionnalités a plus de valeur donc il est prioritaire », c’est très bien. Si on commence a mettre une roadmap avec des dates, je n’en vois pas l’intérêt si ce n’est pour passer du temps à modifier le truc au sprint suivant…
Concernant l’architecture, comment l’approche top-down peut-elle être agile ? Si on produit l’architecture à partir d’analyses, comment la remettre en cause le jour où les besoins imposent une modification de celle-ci ?
Salut,
le sujet m’a vraiment imprésionné (je l’ai beaucoup apprécier) mais je pose la question si je peux avoir les vidéos de cette soiré, je suis très intéréssé par le sujet.
Merci d’avance pour votre réponse
Les videos seront disponibles d’ici juillet sur le serveur du Paris JUG
Je posterai un message lorsque j’aurai plus de détails
Merci
Nicolas