Rencontre avec des développeurs chez Vidal Software

J’ai rencontré une équipe de développement chez Vidal Software, grâce à l’invitation de Jean-Laurent de Morlhon. Des murs couverts de post-its, des développeurs heureux et décontractés, un espace de travail qui donne envie de rester, des discussions où l’on entend les mots « Scala », « Jersey » et « JAX-RS », ce fut un bon moment.

Une grosse expérience de Scrum
Jean-Laurent m’a présenté un bilan très instructif de la mise en place de Scrum, ainsi que des outils d’industrialisation. L’un des projets passe son 40ème sprint, sachant que chaque sprint a une durée de 2 semaines. Autant dire qu’en terme de Scrum et d’Agilité, c’est une équipe très mature et très professionnelle. Sadek Drobi de Valtech et Romain Maton de Xebia France, qui vont présenter Scala au Paris JUG le mois prochain, font aussi partie de cette équipe de développement très sympa.

Par rapport à Scrum, sa mise en place a demandé des efforts, qui permettent aujourd’hui vraiment de se rendre compte de la valeur de ce framework léger. Jean-Laurent m’a montré quelques indicateurs comme la corrélation entre le nombre de points livrés et le nombre de développeur. Premier exemple : un projet sur lequel 5 développeurs travaillent à plein temps. Résultat sur 8 sprints : un taux de livraison en augmentation, l’équipe a une vélocité de 10. Ensuite il me montre un projet avec 7 développeurs. Chacun des développeurs est affecté entre 2/10 et 8/10 sur le projet… Au final, ce projet livre moins que le premier projet. C’est connu depuis longtemps, mais l’équipe de Jean-Laurent peut en parler, preuves à l’appui. Jean-Laurent présentera au 1er anniversaire du French SUG le 30 mars prochain ces résultats.
Cela renforce clairement un des concepts de Scrum : Chaque développeur ne doit travailler que sur un seul projet par itération.

Nous avons passé pas mal de temps face aux radiateurs d’informations. Cela prend plusieurs pan de mur chez Vidal. D’ailleurs pendant nos discussions, nous avons vu passer le Product Owner 2 fois. Cellle-ci vient voir sur l’indicateur et repart, les développeurs déplacent les post-its, bref on sent qu’ici le système est bien rôdé et bien pensé.

Historique des projets
Une idée simple à appliquer : à chaque fin de Sprint, l’ensemble des Users Stories qui est écrit sur des post-its, est rangé et archivé au dessus du Kanban. L’équipe note le nombre de points de vélocité, qui a contribué au développement, bref l’histoire du Sprint. Cela permet de voir d’un seul coup d’oeil l’histoire des projets. Vous pouvez cliquer sur l’image pour l’afficher en grand :

Technique d’évaluation
Nous avons discuté sur les techniques d’estimation et sur l’unité utilisée pour estimer les stories. Une équipe utilise des jours-homme, une autre équipe utilise des points scrum. A titre personnel je préfère les points scrums, qui permettent de représenter la confiance du développeur et la part risque. Un point important : les équipes estiment les stories globalement. D’après Nicolas qui m’a donné aussi pas mal d’informations, cela permet de gagner du temps et ne trompe pas les chiffres. Ensuite lorsque le Sprint démarre, et qu’une Story est dépilée, l’équipe découpe en tâches, et donne une estimation par tâche. Cela permet d’attendre le dernier moment (principe Lean) pour affiner les estimations, au lieu de passer 4 heures de réunion à décortiquer le Product Backlog. J’avoue que ce mélange de Lean et de Scrum est très intéressant.

Itérer lors de la mise en place de Scrum
Dans les discussions, un point revient souvent : « …on faisait comme ça, puis on a changé et on fait comme ça…« . L’équipe a constamment un œil critique sur les méthodes Agiles, et n’hésite pas à adapter au plus juste les pratiques. Et je pense qu’ils sont légitimes pour le faire, étant donné l’expérience accumulée. Cela fait bientôt 3 ans… En fait, je trouve cela plus légitime que les prêcheurs de bonne parole qui n’ont pas d’expérience de Scrum sur le terrain.

Burndown chart
Un ensemble d’indicateur est imprimé presque chaque jour, dont les fameux Burndown Chart. Les équipes ont ajouté le classique indicateur de nombres de points restant à faire. Un autre indicateur intéressant est le nombre de jours de disponibilités des équipes. Cela permet de suivre le ratio « hommes dispos/points à faire » chaque jour. Par exemple, si l’un des développeurs est appelé en urgence sur un autre projet, le nombre de jours de « hommes dispos » est modifié. Cela permet de suivre les impondérables, les impediments. Le Scrum Master fait son possible pour aider l’équipe. Mais il est parfois indispensable de faire des activités connexes comme de la production ou de la TMA.

Burndown chart

Une usine logicielle
Vidal Software est éditeur de logiciel dans le secteur médical. Jean-Laurent et ses équipes ont mis en place une usine logicielle complète. Gestionnaire de code source, intégration continue avec Hudson et TeamCity. Je me suis amusé à regarder avec le test de Joel Spolsky le niveau des équipes. Voici ce que cela donne :

     The Joel Test

 1. Do you use source control?...............................YES, svn
 2. Can you make a build in one step?........................YES
 3. Do you make daily builds?................................YES, hudson et TeamCity
 4. Do you have a bug database?..............................YES Jira
 5. Do you fix bugs before writing new code?.................Dont'know
 6. Do you have an up-to-date schedule?......................YES Scrum
 7. Do you have a spec?......................................No
 8. Do programmers have quiet working conditions?............YES
 9. Do you use the best tools money can buy?.................YES
10. Do you have testers?.....................................YES
11. Do new candidates write code during their interview?.....Don't know
12. Do you do hallway usability testing?.....................Don't know

Les méthodes de développement suivent sur 8 points au moins le test de Joel. Jean-Laurent m’explique que le prochain chantier à venir sera la migration de SVN vers Git, un DVCS très à la mode utilisé pour le développement du noyau Linux. Ce sujet sera présenté en mai au Paris JUG par David Gagot CTO d’AlgoDeal.

Des indicateurs
Jean-Laurent a mis en place le lapin Nabaztag dans son équipe. Celui-ci signale les builds qui cassent, marrant et sympa.

Une autre idée très Lean, c’est cet écran de contrôle des builds :

Cet écran affiche le nom du projet, ainsi qu’un Avatar correspondant à la dernière personne ayant commité son code sur Subversion :

Jean-Laurent a mis le code source à disposition librement : http://code.google.com/p/buildwall/

Cette idée est reprise chez plusieurs sociétés. J’ai vu chez Computer Futures un grand tableau Excel affiché avec un vidéo-projecteur dans l’open-space, j’avais vu un écran à la BNP installé par Nicolas Griso pour les builds Bamboo (spéciale dédicace aux collègues de Nicolas, passez-lui le bonjour de ma part).

Jean-Laurent a trouvé un écran de 46 pouces, l’afficheur ultime, qui existe en version tactile :

Allez voir cet article sur Panic Blog où j’ai trouvé cette photo.

Une démo de Play! Framework
Enfin nous avons terminé par une petite démonstration de Play! improvisée. J’ai montré une partie du projet eXpress Board sur lequel j’ai travaillé cette semaine. Il s’agit d’un job-board développé en 4 jours avec Play! Framework. Discussions intéressantes, Play! a fait son petit effet. Et c’est vrai que c’est vraiment un bel outil, qui permet de gagner du temps. Comparé à Grails (aaah ça y est…) et bien vous lirez cela dans un autre article !

Conclusion
Belle rencontre, une équipe de développement qui travaille avec le sourire, et une bonne ambiance. Scrum est aussi un formidable outil pour suivre et pour pouvoir restituer l’historique d’un projet, chiffres à l’appui. Grâce à ces quelques 3 années, Jean-Laurent peut reparler de chacune des étapes des projets. Et je pense que c’est un effet que l’on ne peut observer qu’à long terme.
Dans nos discussions, j’ai pensé au modèle CMMi, qui mesure la maturité de entreprises par rapport à certains critères de gestion de projet. Je pense qu’il faudrait inventer un nouvel indicateur composé des éléments suivants
– niveau d’adoption des méthodes Agile
– pratique Lean
– usines logicielles
– intégration continue
– tests unitaires, fonctionnels, intégration
– ambiance dans l’équipe
– indicateur de fun-itude
– turn-over

Pour terminer, j’ai pris une photo de l’un des derniers développeurs embauchés chez eux :

Comme quoi, il est possible d’être fun et d’être efficace.

Articles similaires:

Rencontre avec les speakers de l'USI Rencontre avec différentes sociétés Geek 2.0 : rencontre avec Didier Girard Rencontre avec Julien Dubois, responsable de SpringSource France