Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Sessions intra-entreprises sur demande : contact[at]mokatech.net.
Inscrivez-vous vite !

Paris JUG "Scrum" : compte-rendu

scrum.jpgLe 14 avril, le Paris JUG organisait une soirée complète sur le thème de Scrum, la méthode de gestion de projet agile à la mode.

La première séance, présentée par l'inimitable Eric "Appelez-moi Bob" Mignot (Pyxis) et Nicolas Martignole (le Touilleur-Express), se voulait une introduction à Scrum pour les néophytes, et les concepts fondamentaux furent expliqués.
La seconde séance, animée par Guillaume Bodet (Xebia), était présentée comme une série de questions (faussement) naïves, reflétant les inquiétudes des utilisateurs potentiels de Scrum : comment établir un planning, mon projet est-il adaptable à Scrum, etc.

Dans l'ensemble, une excellente soirée informative et argumentée, loin des poncifs et des guerres de clochers habituels.


img_3705.jpg

Oyez, oyez !

En introduction, l'équipe du JUG a fait quelques annonces :

Pour rappel, le Paris JUG, c'est :

  • Plus d'un an d'existence
  • 11 réunions
  • Plus de 200 personnes dans la salle à chaque fois
  • Une demi-douzaine de blogs qui en effectuent des compte-rendus (à votre service !)
  • L'inspirateur de 14 JUGs régionnaux créés en 2008
  • Une mailing-list de plus de 1100 personnes

C'est donc une excellente plate-forme médiatique pour les sponsors (présentoirs, T-shirts, mailing list, affichage des logos, etc.) qui touche de nombreux développeurs Java actifs et passionnés. Pour information, il existe plusieurs niveaux de sponsoring, de bronze à platinum (en fonction de la durée de l'engagement et des ressources mises à disposition), et le Paris JUG peut encore accueillir deux sponsors.

Séance I : Présentation de Scrum

Après une rapide introduction humoristique de Nicolas, comparant Scrum à la gestion des tâches ménagères quotidiennes, Eric est entré dans le vif du sujet.

Qu'est-ce que Scrum ?
C'est certes un ensemble de règles pour gérer les projets, mais c'est plus globalement une nouvelle façon d'appréhender l'organisation des projets en entreprise. Pour percevoir ce nouveau point de vue, il est bien souvent nécessaire de "désapprendre" certaines méthodes et pratiques historiques ; en particulier, il est indispensable d'analyser sans complaisance les problèmes techniques et organisationnels rencontrés lors des développements de projets.

Beaucoup d'informaticiens pourtant passionnés s'ennuient dans les projets actuels. Trop de contraintes juridiques, trop d'incertitude sur le besoin client, trop de pression et trop peu de temps et/ou de moyens pour réaliser le produit dans les règles de l'art : développer n'est plus fun. Le règne des techniciens a cédé la place à celui des avocats et des commerciaux.
De nos jours, les projets sont souvent bradés afin d'être accéptés par des clients toujours plus réticents à investir dans leur informatique (considérée comme un poste de dépense et non un centre de profits), et en cas de problème, chacun rejette la faute sur l'autre : incompétence technique ou spécification insuffisante des besoins ? Aucun secours n'est à attendre non plus de la part des chefs de projets, qui ne jurent plus que par Project et ses plannings millimétrés totalement irréalistes qui doivent malgré tout être respectés à la lettre...
Résultat, environ 63% des projets informatiques seraient jetés ou annulés[1]...

Le Manifeste Agile a été publié (en 2001, ce n'est donc pas nouveau) en réponse à ce constat déplorable, Il préconise de voir au-delà des processus et des outils, et de s'intéresser davantage aux individus et à la façon dont ils collaborent. Par exemple, au lieu de renégocier sans cesse un contrat et d'imposer des avenants, il est plus intéressant de collaborer directement avec le client pour remettre un projet en difficulté sur les rails, quitte à laisser de côté certaines fonctionnalités accessoires. De même, la documentation ne doit pas être une priorité, car seul le code peut être déployé en production et donc générer de la valeur métier[2].

Scrum instaure une collaboration directe et continue entre le client (appelé Product Owner - PO) et l'équipe de développement (la Team).
Go.jpgLe premier définit les fonctionnalités du produit et en détermine la priorité relative ; la seconde est responsable de leur estimation[3] et de leur réalisation, en toute indépendance. C'est ici qu'on mesure la difficulté du rôle du Scrum Master, qui assure la liaison entre ces deux entités : il doit savoir protéger l'équipe des intrusions du client, tout en veillant à ce les besoins de ce dernier soient pris en compte au final.
Cela implique que le PO accepte de changer son mode de pensée, et se concentre sur l'amélioration continue du produit (et de sa valeur métier) plutôt que des jalons lointains (dans quel état sera mon produit dans 6 mois ?). C'est là la pierre d'achoppement de l'adoption de Scrum.
Au final, comme le jeu de Go, les principes de Scrum sont simples à apprendre et à comprendre, mais difficiles à cerner et à appliquer correctement...

En pratique, comment cela se passe-t-il ?
Tout d'abord, le processus de développement est nécessairement itératif et incrémental, pour rester flexible face à l'évolution constante des besoins du client. Un cycle, ou "Sprint", dure généralement entre deux semaines et un mois.

  • Au début de chaque Sprint, le Product Owner définit les éléments du "Product Backlog" (liste priorisée des fonctionnalités attendues - c'est un peu la lettre au Père Noël). Pendant la phase de développement, le PO continue évidemment à travailler sur sa liste, qui sera rééxaminée au Sprint suivant.
  • A partir de cette liste, la Team s'engage sur la réalisation d'un certain nombre d'items parmi les plus prioritaires. Attention, c'est à la Team de sélectionner ces items et d'estimer la charge associée, et surtout pas à un quelconque "Chef de projet", poste qui n'existe pas en Scrum !
  • Pour éviter que l'équipe ne travaille en sous-marin pendant le Sprint (surtout s'il est long), on peut mettre en place des "Daily Scrums" (mini-réunions matinales) de 15 minutes maximum, qui permettent de s'informer de l'avancement du projet et de vérifier que l'équipe est toujours alignée sur les objectifs du Sprint.
  • A la fin du Sprint, on livre un produit terminé, qui contient des améliorations par rapport aux Sprints précédents (ajout de valeur métier), et qui pourrait théoriquement être mis en production immédiatement. Le Product Owner peut valider ou refuser l'incrément.
  • Enfin, l'équipe effectue une rétrospective du Sprint pour améliorer ses pratiques en vue du suivant.

Enfin, un petit schéma vaut mieux qu'un long compte-rendu à 2h du matin. Vous voyez, Scrum, c'est pas dur (quoique...)
img_3706.jpg

L'adoption de Scrum n'est jamais immédiate ni facile. La meilleure méthode consiste à en adopter progressivement les concepts et pratiques, en les adaptant au contexte particulier du projet. Cela peut passer par l'établissement d'un planning d'adotion : par exemple, se donner 6 mois pour mettre en place le développement en Sprints courts. La progression peut être lente, mais les résultats se font généralement ressentir assez rapidement.

Séance II : Scrum, pas pour moi ?

Trouver le Product owner

Idéalement, le Product Owner est le propriétaire du produit, il est censé en porter la vision. Il est responsable du ROI, du budget et du planning du projet. Il en définit les fonctionnalités et les priorités.
Dans la réalité, il n'est pas forcément seul ni responsable de tout. Et il est rarement visionnaire... Il est souvent possible de trouver un poste approchant chez le client, qu'on peut transformer en PO : le responsable produit chez un éditeur, le directeur marketing dans une web-agency, une MOA principale dans une banque...

D'où vient le product backlog ?

Dans un projet classique mené selon le cycle en V, on part de spécifications plus ou moins bien écrites, mais existantes et structurées. Les budgets sont estimés et validés sur la base de ces spécifications, avant même que l'équipe soit constituée. Tout ceci pose des problèmes pour passer à Scrum, où le périmètre, le budget et le planning sont potentiellement variables.

Premier problème : comment démarrer le projet ? Quels sont les renseignements minimums nécessaire pour estimer sa taille, identifier les risques et déterminer la composition de l'équipe ? Un document de moins de 10 pages est généralement suffisant pour tracer les grandes lignes du projet. On peut alors lancer le projet en mode Scrum.
Le tout premier Sprint, appelé "Sprint 0", peut être lancé à partir d'un noyau d'équipe réduit (Scrum Master, architecte, PO, éventuellement un analyste métier...) qui va construire le premier backlog et réfléchir à l'architecture générale du projet. Il faut également spécifier les livrables attendus à l'issue des itérations. L'approche TDD permet d'avoir des "spécifications" exécutables et rejouables automatiquement, garantissant la non-régression.

Quel planning pour Scrum ?

Chacun a connu les affres de l'effet papillon sur MS Project : décaler un jalon d'une journée peut avoir des conséquences imprévues, comme décaler subitement la date de mise en production de 3 mois. Il faut alors passer des jours entiers à se battre contre l'outil pour tout recaler correctement... En pure perte, car il est de toute façon totalement irréaliste de régler un planning à la journée près sur des projets autres que triviaux.

La preuve :
img_3707.jpg
Guillaume dans sa fameuse prise du "Project Grip of Death" : "si je décale le planning de ça, ton projet est fichu !"

Une approche plus réaliste est d'utiliser le Burndown Chart pour estimer la date de fin de projet en fonction de la vélocité moyenne de l'équipe (sa vitesse de réalisation) et de la tendance du Product Owner à ajouter ou modifier des items. Si tout va bien, les courbes convergent et délimitent une plage de dates de fin réalistes et réadaptées en continu (et non une date empirique). Là encore, cette imprécision relative est généralement souvent mal perçue par le client, qui doit être sans cesse rassuré. Comme disait Dwight Eisenhower : "plans are nothing, planning is everything" : on a beau avoir le meilleur plan initial du monde, il est nécessaire de le réadapter en permanence pour tenir compte des faits concrets et des événements imprévus.

Mon projet est trop gros !

Ici, l'équation est facile :

  • Gros projet + peu de monde = délai de 200 ans
  • Gros projet + bcp de monde = usine à gaz

Comme l'équipe idéale, composée uniquement de consultants expérimentés et sur-productifs n'existe ps (du moins, pas chez le client...), la meilleur solution est de mettre en place plusieurs équipes de taille petite ou moyenne, et de les faire travailler ensemble.

Cette technique a remporté un franc succès auprès des Chemins de Fer Hollandais. Grâce à 25 personnes réparties en 4 équipes et un budget de plusieurs millions d'euros, il ont réussi à livrer une première version de leur produit en 8 mois, puis une nouvelle version tous les 3 mois.
On peut également citer les exemples de Google, Oracle, IBM, Motorola, etc. (surtout des entreprises américaines ou des pays nordiques, où les mentalités sont plus souples)

Et l'architecture dans tout ça ?

Il est très coûteux de se tromper d'architecture, c'est une des premières causes d'abandon des projets informatiques.

Aux architectes dogmatiques, isolés dans leurs cellules d'expertise, il vaut mieux préférer les architectes agiles, intégrés à l'équipe et donc plus pragmatiques. La modélisation et la spécification du socle doivent être réalisées en groupe, et le développement de petits prototypes est recommandé pour évaluer des solutions techniques incertaines. Mais il ne sert à rien de spécifier l'intégralité de l'architecture du projet en amont ; celle-ci doit être exclusivement pilotée par les besoins spécifiques du projet, et rester souple pour s'accomoder des évolutions des besoins. En revanche, il est très utile de spécifier comment le projet s'intègrera au reste du système d'information.

Pour finir, il peut s'avérer intéressant de ne pas structurer son projet en fonction des couches techniques, mais plutôt selon les fonctionnalités du produit. Ainsi, on pourra livrer des incréments auto-contenus, composés des portions des couches de persistance, de service et de présentation qui leurs sont propres.

Conclusion

Cette soirée était fort bien animée et les deux heures sont passées très rapidement. J'ai apprécié le ton informel et calme des intervenants, qui n'ont jamais cherché à imposer leurs points de vue et ont esquivé l'écueil du dogmatisme.

img_3708.jpg
img_3709.jpg
img_3710.jpg

Notes

[1] Mais par ailleurs, on sait que 83% des statistiques sont forgées de toutes pièces ;)

[2] Cette affirmation doit être considérée avec circonspection : le logiciel produit de la valeur métier immédiate ; la documentation qui permet de le maintenir en génère davantage encore sur le long terme

[3] On peut ici appliquer le principe de l'estimation relative : on compare les estimations des différentes sous-parties du produit entre elles, selon une unité abstraite décorrélée des notions de temps ou de budget. Par exemple, si la mise en place d'Hibernate vaut 2 unités, la réalisation de l'interface graphique vaudra peut-être 3. La somme des points d'action fournira le reste à faire.


Commentaires

1. Le mercredi 15 avril 2009, 06:52 par Nicolas

Excellent résume. Merci olivier.
Je posterai le podcast de la 1 ère partie bientôt.

2. Le jeudi 16 avril 2009, 10:50 par Guillaume Bodet

Merci pour cet excellent résumé!
Juste une petite correction : on doit la célèbre citation "Plans are nothing, planning is everything" à Dwight Eisenhower, dit "Ike", commandant en chef des forces alliées en Europe durant la seconde guerre mondiale puis Président des Etats-Unis...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.