Les cartes sont réparties par code couleur. Les idées d’architecture en orange, les principes de code en bleu, les principes d’équipe en rose. Les méthodes en rouge et enfin les tests en vert.

Chaque carte nous fait prendre conscience que l’on ne devient pas magiquement un bon développeur. C’est un gros travail. J’ai interviewé Jean-Laurent de Morlhon, l’un des responsables techniques de Xebia France afin de comprendre les origines de ce projet, et son déroulement. Le constat de départ est simple : avec une dizaine d’années d’expérience nous commençons à « sentir les choses » et à devenir « instinctif ». Comment transmettre et débattre de ce que nous avons appris et nous avons lu ? Comment former et proposer aux consultants quelque chose d’original ?

Xebia est répartie en Hollande, en Inde et en France. Le projet s’est déroulé sur plusieurs mois, chaque pays a contribué. L’équipe à Paris s’est chargée de la réalisation à proprement parler des cartes. L’ensemble est livré dans un beau boitier cartonné, chaque carte est assez rigide pour être passé de main en main lors d’une réunion.

Un QRCode permet de se rendre sur le site essentials.xebia.com où chaque carte est détaillée. Motivation, contexte d’application, exemple et références. C’est aussi un gros travail de documentation et de tri. Il y a eu environ 200 idées proposées. Après partage et délibération, 80 cartes ont été retenues.

Une explication du titre de la carte est placée au dos de celle-ci. Un lien vers le site internet de Xebia permet ensuite d’avoir plus d’informations, des exemples et de quoi mieux comprendre la carte.

Comment utiliser ce boitier ?

Je pense qu’il peut servir d’outil lors des rétrospectives ou des stand-ups meeting. C’est aussi un moyen lors d’une pause café de discuter d’une idée ou d’un principe, et de le mettre en application immédiatement. Enfin il peut servir de référence lors de discussion ou de présentation.

Un principe que j’aime beaucoup « No Blame, but no Mercy » : Aucun blâme, mais aucune pitié. Sur votre projet, ne vous permettez pas de critiquer le développeur qui a écrit le code. Soyez critique et sans pitié sur le code, pas sur la personne qui l’a écrit. Elle débutait ? Elle n’avait que quelques minutes avant de partir ? Elle n’avait pas toutes les informations dont vous disposez aujourd’hui ? Soyez humble et ne blâmez jamais la personne. Soyez sans pitié pour le mauvais code. Peu importe qui l’a écrit. Nettoyez, refactorez, discutez avec d’autres développeurs. Ce que vous jugez mauvais est peut-être la solution la plus adaptée, la plus simple et la moins cher pour un problème. Bref soyez humble.

Où trouver/acheter ce boitier ?

Je crois que pour l’instant, il n’est pas possible de l’acheter. Je pense qu’il pourrait être intéressant de proposer une offre pour couvrir les frais de fabrication de chaque boitier, puis de proposer d’en faire l’acquisition aux équipes intéressées.

Je vous laisse, j’ai la carte « It ain’t over till it’s done » en main et je vais prendre un café.

Il y a 3 ans, je quittais mon poste de Chef de projet chez un éditeur pour devenir freelance et indépendant. 3 ans après, j’ai découvert qu’il existe une nouvelle façon de travailler. J’ai fait l’expérience d’être freelance en mission chez des clients, puis de travailler chez moi. Nous allons d’abord parler de l’Indépendant 1.0, du type de mission que nous pouvons effectuer. Puis ensuite du nouveau métier d’Indépendant 2.0.

Il y a tout d’abord l’indépendance au sens juridique et financier du terme. Vous claquez votre démission, vous créez votre EURL et en avant pour l’aventure. Dans l’informatique, le marché a besoin de vos compétences. Trouver une mission ne sera pas dur. Comptez 2 jours avec un CV dans l’air du temps. Vous débuterez votre nouveau boulot lundi prochain, bien plus vite qu’une embauche.

En effet.

Trouver une mission, c’est facile. Ensuite trouver un client avec lequel vous pourrez travailler en direct, s’avère plus difficile. Les grandes entreprises ne travaillent qu’avec une liste fermée de prestataires. Vous, simple petit indépendant, ne pouvez tout simplement pas travailler pour les grandes banques en direct. Il sera nécessaire de passer par de la sous-traitance, en trouvant un « porteur » référencé chez le client final. Parfois, vous trouverez vous-même la mission, vous serez ensuite obligé de demander la liste des sociétés référencées, de les contacter, et de venir les voir en disant : « Salut, je veux bosser chez Client Final. Ca vous intéresse de faire 8 à 10% de marge, de montrer au Client Final que vous bossez avec moi ? « .

Vous trouverez par contre sans problèmes des missions avec un intermédiaire comme une SSII ou un broker. Il y en a des tonnes sur Monster, sur Freelance.net et d’autres sites similaires.

Si je t’en parle, c’est pour t’expliquer l’influence de ce type de mission sur la notion d »indépendant.

Il y a donc 2 types de clients : en direct et via un intermédiaire

Sur ces 3 dernières années, j’ai travaillé avec 5 clients en direct et 2 clients via un intermédiaire. Les 2 clients pour lesquels j’ai travaillé via un intermédiaire étaient de grandes Banques, qui ne travaillent jamais avec des petites structures en direct.

Sur la durée, j’ai effectué 14 mois et 12 mois pour chacun de ces 2 clients avec intermédiaire. Sur mes 36 mois d’indépendant, j’ai donc travaillé 26 mois pour 2 clients, et le reste du temps pour ces 5 autres clients. Le plus long étant la startup en décembre 2009, avec 3 mois. Le plus court étant un audit pour un client avec 5 jours.

Donc 2 types de missions, avec une durée et un fonctionnement différent :

1. la mission en régie via un intermédiaire pour un grand compte
2. la mission en direct sans intermédiaire

La mission en régie via un intermédiaire pour un grand compte

Sur les missions à long terme, via un intermédiaire, vous vous retrouvez dans la même situation qu’un salarié, qu’un autre consultant ou qu’un interne. Chaque jour ressemble à la veille, et vous avez vite fait de prendre quelques habitudes routinières. Vous n’avez pas plus de temps que les autres pour développer votre entreprise et votre réseau. Côté veille techno, vous devez aussi travailler chaque soir pour avancer. Cependant sur mes 2 grosses missions, j’ai pu libérer du temps pour participer à des conférences comme Devoxx, Mix-IT, What’s Next, le JUG SummerCamp et les différents JUG où je suis allé. D’un point de vue légal d’ailleurs : vous faites ce que vous voulez : vous n’avez pas à demander l’autorisation de prendre des congés, vous êtes dans une relation commerciale avec le Client Final.

Tout ceci c’est ce que je vais appeler « être Indépendant 1.0 » avec les caractéristiques suivantes :

• mission en régie chez le client
• facturation à 30 jours
• relative sécurité avec des contrats de 3 à 12 mois
• parfait pour faire tourner financièrement son entreprise
• n’offre pas plus de temps pour la veille
• permet de prendre des jours pour participer aux conférences
• adapté à ceux qui veulent travailler librement
• moins de liberté dans les technologies utilisées

La mission en régie pour un client en direct

Je ne parle pas des missions au forfait, car ce sont souvent des missions compliquées, que je préfère refuser. Je travaille plutôt en mode conseil, avec un contrat type de service, des conditions générales de ventes et des conditions particulières pour travailler avec mes clients.

Ce type de mission est différent. Les caractéristiques seraient celles-ci :

• une mission avec un client en direct
• une réalisation chez le client ou chez vous (télétravail)
• l’acceptation d’une précarité avec un contrat court de 30 jours renouvelable
• un risque d’impayé plus élevé
• un vrai rôle de conseil et d’expert
• la possibilité de moduler son agenda en accord avec le client plus facilement
• plus de temps pour effectuer de la veille technologique ou lancer ses propres projets
• une liberté sur la réalisation, tant que cela marche, respecte le budget et rend le client heureux

Le type de mission d’un indépendant influence son emploi

Or avec un peu de recul, je me rends compte que le type de mission va avoir une influence directe sur le type d’emploi. Si demain j’étais salarié, en télétravail ou chez un client, quelles seraient finalement les différences avec mon statut d’indépendant ?

Ces points vont me permettre de montrer aussi la différence entre un emploi salarié classique et ce type de nouveau profil. Et vous verrez qu’il doit être possible de proposer cet approche à vos salariés.

Lorsque j’étais salarié ou consultant chez un client, il est vrai que l’obligation de suivre un cadre d’organisation limite la productivité. Parfois, en imaginant ne pas avoir à assister à certaines réunions, en évitant de recevoir 150 emails par jour, je me dis : je travaille vraiment. D’ailleurs, combien d’heures avez-vous vraiment travaillé aujourd’hui ? Combien de fois avez-vous été interrompu ? Pourquoi les Français restent-ils jusqu’à 19h ou 20h au boulot, en tirent une certaine fierté, alors que nos voisins verraient plutôt là le symptôme d’un gros souci ? Qui a dit que rester jusqu’à 22h permettait d’être « meilleur » ?

La motivation est vraiment différente. Lorsque vous arrivez à travailler par plaisir, ce que je souhaite à tout le monde, vous explosez les compteurs de la productivité.

Saint-Exupery disait

Quand tu veux construire un bateau, ne commence pas par rassembler du bois, couper des planches et distribuer du travail, mais réveille au sein des hommes le désir de la mer grande et belle

Elle vient avec un cadre de travail et des outils adaptés. La question de prendre une bonne machine ou une belle chaise ne se pose pas. Prenez eXo Platform, dont plusieurs salariés travaillent à distance. L’entreprise aide les personnes à acheter un bureau, un bon fauteuil et surtout un bon Mac. Je râlais il y a quelques mois sur les DSI du XXieme siècle qui dépensent de l’argent pour mettre des filtres « top-sécurisés » ou des anti-virus. Lorsque vous êtes chez vous avec votre équipement, croyez-moi que vous êtes bien plus efficace. Un peu de discipline pour ne pas laisser Twitter et GMail ouverts en permanence, mais finalement les mêmes habitudes « qu’au bureau ».

La relation à la hiérarchie est bien entendue complètement différente. Je ne vais pas le dire trop fort… mais est-ce que vous ne pensez pas que certains de vos managers sont inutiles ? Honnêtement ? Patrick le Group Manager, c’est pas un gros boulet ? Et Vanessa, la DirCom, elle en tient pas une bonne couche ?

Si vous êtes indépendant chez un client classique, et que vous y passez plusieurs mois, vous serez sans doute un jour confronté à la hiérarchie interne de l’entreprise. Normal, toute structure a besoin d’os pour se soutenir. Cependant on tend à promouvoir les gens qui sont compétents à leur poste actuel, en les transformant en « Chef de… ». Or vous le savez comme moi : un bon développeur n’est pas forcément un bon manager. Si bien qu’au bout de quelques années, il n’y a que des mauvais managers. Un bon manager deviendra Directeur ou sera chassé par la concurrence. Par contre personne ne voudra d’un mauvais directeur. On retrouve cela surtout dans les grandes sociétés, dans les organisations pyramidales obèses et fatiguées.

Je reconnais aussi qu’en devenant indépendant, après avoir été moi-même « chef de projet » pendant 3 ans, on perd le sentiment de peur ou de soumission du salarié vis-à-vis de sa hiérarchie. Rebelzzzzz !!! Disons plutôt : adulte. Fin de la récréation où ton manager écrasé par sa hiérarchie négocie tout avec toi : tu bosses pour toi.

Lorsque tu travailles pour un client en direct, la hiérarchie est inutile. Tu peux être confronté à une organisation pyramidale, mais tu n’en fais pas partie. Tu passes du mode « développeur ouvrier » au mode « développeur artisan » qui réalise son travail chez lui, pour le compte d’un client, qui souhaite de la qualité.

L’innovation est un avantage compétitif lorsque l’on est Indépendant 2.0. Si je mange littéralement du Scala en ce moment, c’est pour 2 raisons. Tout d’abord je continue à suivre l’aventure de Play! Framework, et la partie Scala est intéressante. Ensuite, c’est dans l’idée de se former et de se positionner aujourd’hui sur des technologies pointues, qui seront utilisées demain. Je n’ai pas pris un langage complètement exotique. J’ai fait le choix de prendre un outil proche de Java, mais qui me permettra surtout d’être sollicité dans quelques mois, pour réaliser des missions encore plus intéressantes. J’aurais pu rester sur la stack technique que j’utilise, ou j’aurais pu aussi faire le choix de monter en compétences dans la Finance. J’ai fait le choix d’apprendre un nouveau langage. J’ai cependant aussi mon « Options, futures et autres actifs » de John Hull sur la table de nuit.

Lorsque j’étais Independant 1.0, il était difficile d’avoir du temps pour apprendre de nouveaux langages ou de nouveaux outils. Vous êtes dans la même situation qu’un salarié ou qu’un autre consultant : votre boulot est de réaliser avec le socle technique de l’entreprise, pas de venir tout casser. J’en ai fait l’expérience il y a quelques temps : il n’est pas possible d’amener sa technologie « kikoulol » chez un client. Vous devez respecter et comprendre les synergies et les choix du client. Vous devez respecter son choix de telle ou telle technologie. Comprenez-bien : en tant qu’indépendant 1.0 vous apportez votre expertise dans la réalisation. Pas dans le choix de telle ou telle framework web. Si par contre vous pouvez avoir un rôle de conseil, allez-y car c’est intéressant.

L’Agilité est un truc d’entreprise. J’en fais l’expérience tout seul : je ne fais pas de pratiques Agiles lorsque je suis tout seul. Non. Je ne vais pas mentir et faire style « ouais je teste tout, je fais de l’intégration continue, je me fais des stand-up meeting tout seul, je mets des post-its dans le salon« .

Non je ne fais rien de tout cela, et merci, je vais bien. Je travaille différemment. J’appelle cela de la « Pragmatilité« . C’est comme de l’Agilité, mais en plus pragmatique. Si je dois tenir une liste des choses à faire, je le marque sur une feuille de papier, je rature lorsque j’ai codé quelque chose, et c’est tout. Si je dois donner une estimation du reste à faire, je fais le point avec mon client et je réajuste le cadre de ce qu’il faut réaliser. Voilà.

Dernier mot enfin sur les heures de travail. Dans le cadre de l’entreprise, il est obligatoire d’avoir un créneau où l’ensemble des collaborateurs est là. De 10h à 17h par exemple. Ensuite, et je pense que vous le vivez, il y a ceux qui arrivent tôt et partent à 17h30, et ceux qui arrivent à 10h mais restent jusqu’à 20h. Etonnant non ? Lorsque je racontais à mes parents il y a 13 ou 14 ans que j’avais commencé à 11h et terminé à 21h avec 2h de Quake en réseau entre les deux… ils avaient un peu de mal à comprendre.

L’entreprise et la vie personnelle se mélange, ce qui n’est pas bon. Je ne trouve pas normal que Pierre réserve ses billets de train avec sa copine au téléphone à 15h00 de l’après-midi dans l’open-space, puis qu’il reste jusqu’à 19h pour travailler. Si vous êtes en entreprise ou chez un client, à vous de fermer votre espace de vie privée. Après tout, il y a quelques années, l’organisation des vacances pouvait attendre 19h non ?

Cela provient aussi du fait que l’entreprise et la vie privée sont mélangées. Quid alors de la situation d’une personne qui travaille chez elle ? Et bien croyez moi si vous le voulez : j’ai un emploi du temps bien organisé. J’accompagne les enfants à l’école, un peu de sport, lecture des blogs, rédaction d’un billet ou test, puis début de la journée. Pause café via Skype avec quelques potes indépendants, puis boulot jusqu’à midi. Je sors chaque jour, histoire de prendre l’air. Boulot ensuite toute l’après-midi, peu de pause. Hop je vais chercher les 2 petits, gouter, jeux, bains, diner : une vraie vie de famille pendant 2 à 3h. Ensuite si mon épouse bosse aussi, je bosse un peu encore 2 heures, et c’est tout. Finalement, c’est mieux qu’avant.

Indépendant 2.0 en quelques mots

Je suis passé d’un mode salarié à un mode indépendant 1.0 pendant quelques temps. Puis en travaillant à mon compte pour l’eXpress-Board et en travaillant pour des clients en direct, j’ai découvert un autre métier. Disons plutôt une autre façon de travailler. Emploi du temps plus souple, motivation sur la réalisation, flexibilité des heures de travail, possibilité de se former et d’apprendre de nouvelles technologies.

Avec le Cloud Computing et les technologies du Web, je ne serai pas étonné de voir de plus en plus de personnes comme moi : vous travaillerez de chez vous ou dans des petits bureaux. Vos valeurs seront le travail, la qualité, la possibilité de travailler à distance et la bonne humeur. Vous n’aurez pas ou peu besoin de « manager » car le fruit de votre travail sera visible et tangible.

Je sais pas pour vous, mais si un jour je créé une société avec des geeks, et bien je garderai ce modèle. Je pense qu’il s’adapte aussi aux salariés en télé-travail.

A voir :

- New Workstyle : Un graph sympa qui montre le changement dans les habitudes de travail

Chaque équipe de développeur est composée de différents profils. Vous voyez une équipe de foot ? Et bien une équipe de développement c’est pareil. Il y a celui qui abat le travail comme un bucheron, celui qui a des idées ou celui qui est fort en Web. Or il nous arrive encore de rencontrer des responsables de projets informatiques, qui ne perçoivent pas cet écart de performance et de capacité entre développeurs.

Il y a quelques années, je me souviens avoir discuté avec un chef de projet qui pensait que les développeurs étaient tous identiques, avec une capacité à produire du code facilement calculable dans Excel. La discussion était partie d’un tableau Excel justement. Il essayait de prédire, je dis bien prédire, la répartition de charge et de déterminer la date de fin de projet. Alors qu’il remplissait son tableau, je le voyais diviser des tâches entre développeur. Une tâche estimée à 8 jours passait ainsi à 4 jours s’il mettait 2 développeurs…
Grave erreur. S’il faut 9 mois à une femme pour faire un bébé, 9 femmes ne font pas un bébé en 1 mois (la phrase est de 1975, de Frederick Brooks, tirée du livre The mythical Man-Month).
Après discussion il a admit qu’il était très difficile de prédire quoique ce soit. Et nous avons travaillé à plusieurs pour réussir à faire un planning prévisionnel.

Prévoir et prédire

En fait si vous acceptez qu’il est impossible de prédire, vous avancerez et vous serez en mesure de chercher un autre moyen. Prévoir et prédire sont deux verbes différents. Il est possible de prévoir un budget, il est possible de prévoir le départ ou l’arrivée d’un développeur. Il est certainement important de prévoir la date de sortie de votre logiciel. Mais ensuite, la réalisation reste pour moi de la prédiction. Un planning détaillé de développement, que vous avez précieusement et difficilement mis à jour, n’est pas suffisant pour prédire correctement la fin d’un projet, dans le temps imparti, avec les fonctions demandées et en respectant un budget.

Il est évident qu’il est impossible de prédire le futur, et le problème se pose lorsque le responsable d’un projet confond prédiction et prévision.

Je vous prédis un bel avenir, je prévois que vous allez bien galérer avant d’y arriver.

(ce billet date en fait de septembre 2010)

Neal Ford, Crédit photo : USI 2010 album sur Flickr.com

De l’importance de la communication
Après cette première partie, Neal Ford nous parle maintenant de la communication. Plus importante que la technologie, nous allons voir que la communication est l’un des points clés pour réussir des projets.

Neal demande à la salle si nous avons déjà fait partie de projets qui se sont plantés. Rires, quelques mains se lèvent. Il demande ensuite si la raison de l’échec était le mauvais choix d’une technologie, ou une mauvaise communication ? L’ensemble répond : la communication.

Il est donc plus facile de planter un projet car vous communiquez mal, que parce que vous avez pris un framework exotique au lieu de prendre un framework standard.

Les projets se plantent souvent à cause des gens. La communication entre les gens devient très importante. Nous sommes des créatures massivement communicantes. Notez qu’en prison, la plus grosse punition est d’aller au mitard. De ne plus pouvoir communiquer avec d’autres humains… Dingue non ? Pensez aussi aux gens que l’on met « au placard »… Nous avons besoin de communiquer. C’est vital.

Alistair Cockburn explique dans un graphe que la qualité de la communication avec les outils modernes est très inégale.

Pour travailler, nous sommes bien plus efficace devant un tableau blanc qu’au téléphone, ou même pire, via un document Word. Le pire des processus de communication est le papier écrit. Et le drame, c’est que c’est l’un des plus utilisés dans les Entreprises. C’est marrant, mais la semaine dernière je suis allé chercher un grand tableau blanc pour notre équipe, et je l’ai installé dans notre bureau… Croyez-moi cela marche.

Neal Ford explique que c’est pour cette raison, qu’il est illusoire de croire qu’une spécification technique envoyé à des développeurs en Inde donnera le logiciel escompté. C’est une perte de temps et d’argent. Cela ne fonctionne pas.

Cela va plus loin. Nous avons même une capacité limitée à communiquer et faire autre chose en même temps. Vous ne vous êtes pas demandé pourquoi il est dangereux de téléphoner et conduire en même temps ? Pourtant vous avez le droit de parler avec votre voisin, vous pouvez écouter la radio, mais on vous interdit de téléphoner en même temps. Or pour ceux qui ont essayé (moi le premier) vous vous rendrez compte que la communication au téléphone est moins bonne que lorsque vous avez la personne à côté de vous. Cela vous demande même un effort plus important pour comprendre. Et cet effort vous déconcentre de la route. C’est bien là la preuve que les canaux de communications demandent plus ou moins d’efforts.

Un document écrit est aussi très destructif, car la possibilité de donner son retour n’existe pas ou peu, par rapport à une communication face à face. Bien entendu, ces documents sont souvent écrits à la suite de réunions, où nous nous sommes vus… Mais souvent le développeur n’aura pas eu l’opportunité de discuter avec le client, et de poser quelques questions simples. Il est donc primordial pour réussir un projet de prendre en compte ce facteur de communication.

Le manifeste Agile propose 4 valeurs clés, dont l’une est exactement ce que Neal Ford vient d’expliquer.
Les quatre valeurs fondamentales Agiles sont :
– Davantage l’interaction avec les personnes que les processus et les outils.
– Davantage un produit opérationnel qu’une documentation pléthorique.
– Davantage la collaboration avec le client que la négociation de contrat.
– Davantage la réactivité face au changement que le suivi d’un plan.

Voir l’article original en Anglais : http://agilemanifesto.org/

Neal Ford présente ensuite un projet supporté par ThoughWorks au Malawi. Ce projet permet à des infirmières de transmettre via SMS des bilans de santé, alors que les moyens de communications sont très mauvais, et que la vie est très dure. Ce projet RapidSMS, est un projet open-source réalisé pour l’UNICEF en Python.

La communication dans ce projet est vitale, et elle permet de sauver des vies.

Le Feedback
Martin Fowler attaque maintenant la deuxième partie de sa présentation. Pourquoi certains projets réussissent bien ? Il souhaite nous parler de l’importance du retour d’information, le feedback en Anglais.

Martin nous montre une photo d’un gâteau. Réalisé avec une approche prédictive, tout le monde sait qu’il faut respecter la recette en cuisine pour réussir. Ma grand-mère me disait de mettre 75g de farine, et de ne pas poser de questions. La cuisine est une alchimie intéressante. Si vous avez une recette pour 4 et que vous voulez faire un gâteau pour 8, il ne faut pas doubler les quantités. En effet, lorsque vous doublez les quantités, vous avez toutes les chances de planter votre gâteau. Curieusement, la cuisine est bien plus compliquée que ce que nous pensons. Et bien le développement logiciel, c’est pareil. Il ne sert à rien d’ajouter 2 développeurs en pensant que vous irez 2 fois plus vite. Parfois même, vous irez 2 fois moins vite, car il faudra former ces nouveaux arrivants…

Martin nous montre une photo de gâteau donc, et une photo de pomme de douche. Quelles différences y-a-t-il entre une pomme de douche « chaud-froid » et un gâteau ? Et bien une histoire de retour, de feedback.

La cuisine est un processus défini alors que régler une douche est un processus adaptatif/empirique.

La cuisine suit un plan précis, une recette. Et le feedback ne sera fait qu’à la fin. Peut-être que votre gâteau sera raté, peut-être qu’il sera excellent, vous ne le saurez qu’à la fin. Au contraire, si vous prenez une douche dans un Hôtel, et que vous devez régler la température, vous allez utiliser un feedback permanent pour adapter la température. C’est l’approche Agile.

Cette illustration nous permet de comprendre qu’il existe 2 types de processus, et que cela fait partie de notre vie quotidienne. Dans le cas d’un processus empirique (la douche) nous examinons le résultat final pour adapter le signal d’entrée. Dans le cas d’un processus défini, si je suis la recette à la lettre j’aurai toujours le même gâteau, je serai capable de reproduire à l’identique la même chose.

Or chaque développement de chaque projet est différent et donc l’approche prédictive ne semble pas une bonne chose. Par contre pour mélanger des ingrédients chimiques dans une usine, vous serez d’accord qu’un processus défini est primordial, pour des raisons de sécurité. Pour le développement d’un logiciel, Martin Fowler nous demande de bien réfléchir avant de choisir une méthode de développement.

Si vous prenez l’approche empirique (la douche) pour construire votre logiciel, il est donc très important de mettre en place un système de feedback. C’est pour cette raison que les équipes Agiles s’installent des murs de post-it, des Kanban, des indicateurs visuels et toutes sortes de trucs sympas : pour avoir du feedback disponible à tout moment.

Martin Fowler montre la photo d’un immeuble de 20 étages en Chine. On voit qu’au 15ème, les fenêtres sont couvertes de post-it. C’est l’étage de ThoughWorks, facilement identifiable de la rue… Rires dans la salle.

L’intérêt d’un Kanban est que ce tableau est lisible par tout le monde. Ecrit clairement, il donne une vision de l’avancement du projet. Tout le monde peut y participer, et donc doit pouvoir y accéder facilement.

Feedback sur la construction du logiciel
Martin Fowler insiste ensuite sur l’importance de donner un indicateur sur l’avancement de la construction du logiciel. Nous devons savoir où nous en sommes en terme de développement du logiciel.

L’intérêt d’afficher sur le mur le planning de son projet est primordial. Martin Fowler explique qu’il lui arrivait auparavant d’aller dans des équipes de développement, et de constater que les développeurs n’avaient pas accès au planning global du projet. Mettez en place un tableau avec les prochaines semaines de développement, cela permettra de donner plus de visibilité et donc de sens, au travail de chacun.

A propos des outils électroniques, les équipes de développement préfèrent utiliser un vrai tableau plutôt qu’un logiciel. Je confirme : ne vous jetez pas sur un outil, privilégiez une solution simple à base de post-it et de fiches bristols. Cela fonctionne très bien.

Dans ce qui est de donner du feedback, Martin rappelle que le seul moyen de voir un progrès dans le développement d’un logiciel, c’est d’avoir un logiciel qui marche. Cela veut aussi dire, un logiciel déployé et testé.

Le processus de construction de votre logiciel est très important. Certains projets aiment bien utiliser des Lava Lampes rouges ou vertes pour signaler que la construction du logiciel fonctionne, ou non. A titre personnel, j’ai mis en place cette pratique à la BNP il y a un an et nous avions une Lava Lampe rouge que nous allumions pour signaler un « Build failed ». C’était sympa.

Neal Ford parle ensuite de CCBoard, un tableau de bord de construction de projets. Ce logiciel open-source permet d’afficher le status de toutes vos builds.

Faire de l’intégration continue c’est compiler, tester, packager, déployer, retester et valider un logiciel. Cela demande un effort, qui permet cependant de réduire à zéro l’effort de « release » d’un logiciel. Si vous êtes capable de construire à tout moment votre logiciel, et de le packager, vous comprendrez que faire « une release » devient facile.

A propos des pratiques de développement logiciel, Martin Fowler parle du Pair Programming. Il a été observé que lorsque 2 développeurs travaillent en même sur un écran, les deux n’utilisent pas la même partie de leur cerveau. Celui qui tape le code sur le clavier est dans la réalisation, alors que celui qui est assis à côté est dans la réflexion, la beauté du code et la vision globale. Celui qui code est le pilote, et celui qui est à côté est le navigateur. Cela permet de réaliser du code de meilleur qualité.

Martin utilise l’image d’un jardin de la Renaissance, tiré d’un château de la Loire. Puis ensuite l’image d’un jardin tropical, tiré d’un parc en Angleterre. D’un côté l’ordre, la clarté. De l’autre le chaos, le foutoir apparent. Et pourtant ces 2 jardins sont beaux. Ils correspondent à deux approches : l’une procédurale, l’autre artistique. Tout ceci pour illustrer qu’il faut des deux pour faire un monde. Et il nous encourage à mélanger ces 2 approches lorsque nous codons, en faisant du Pair Programming par exemple.

Dernière partie
« La perfection n’est pas ce que nous visons, mais ce que nous faisons à tout moment ». Cette phrase de Kent Beck résume l’approche eXtrem-Programming, où l’on fait de tout, mais très bien et en permanence.

L’introspection est alors important. Chaque semaine, l’équipe doit réfléchir et s’assurer de s’améliorer en permanence. Si une équipe ne change pas ses pratiques régulièrement, et qu’au bout de 12 mois vous la retrouvez dans le même état, c’est qu’elle a cessé de progresser. Et c’est un indicateur qu’il manque peut-être des pratiques de rétrospectives.

Neal Ford ensuite à propos de la communication et du retour, nous raconte un peu ses expériences passées. Dans les équipes de développement qu’il a croisé, il a remarqué que les équipes aiment bien laisser trainer des petits jeux, des casse-têtes ou des Rubbik’s Cub. Cela permet en fait de décompresser et de mobiliser d’autres parties du cerveau. Il y a 5 ans, je me souviens que nous avions un petit panier de basket, et que nous faisions des tournois, histoire de lever le nez du code de temps en temps…

Neal Ford dit clairement que mettre des développeurs face à un mur pour coder, n’est pas une bonne idée. Il faut stimuler leur créativité. Il y a des entreprises qui mettent en place des règles et qui vous interdisent d’afficher des photos personnelles, des posters de cinéma, ou de vous balader en tee-shirt « My bozz rebooted » dans les couloirs… Pensez à ces photos des locaux de Google, où à l’excès inverse, les gens peuvent avoir un peu tout et n’importe quoi dans leur espace de travail… La notion de « Cubicle » est cependant très américaine, et c’est un aménagement de bureaux peu utilisé en France.

Ce qu’il faut retenir, c’est qu’il important de traiter les développeurs comme des créatifs. Ils doivent pouvoir aménager leur espace de travail librement. Mettez des tableaux blancs, laissez-les s’installer et s’approprier leur bureau. Si vous n’avez que des prestataires qui viennent de SSII, croyez-moi c’est possible. Nous avions une lava-lampe, j’avais acheté une petite plante verte, nous avions nos posters Scrum, le tout en évidence à côté de la cafétéria, et personne ne nous a jamais dit d’arrêter.

A propos de la construction des logiciels, Neal Ford raconte une histoire sympa. Dans une des équipes où il a travaillé, le logiciel d’intégration continue joue une petite musique de 3 secondes lorsque la compilation fonctionne. C’est très pratique, car cela permet de vous signaler que vos derniers commits fonctionnent, sans vous déranger. Vous entendez vos 3 secondes de musique, et vous pouvez continuer. Chaque développeur avait sélectionné une chanson ou un bruit, et donc pouvait savoir que son commit était passé. Sympa non ?

Ensuite, lorsque le build cassait, une autre chanson se mettait en marche. Dans son équipe c’était « Oups I did it again ! » de Brittney Spears. Et d’entendre cette chanson mettait une bonne ambiance. Toute l’équipe se mobilisait pour aller réparer le logiciel immédiatement.

Neal Ford montre ensuite une photo d’une équipe de développement. On voit une énorme peluche de Kangourou assise sur le fauteuil à côté du développeur. Celui qui a le « Stuff Kangoroo » est responsable du build pour la journée. Lorsque la chanson de Brittney se met en marche, son travail est alors de chercher le développeur et de s’assurer que le logiciel est réparé rapidement. C’est un peu un rôle barbant, donc ce rôle tourne. Et celui qui a cassé le build récupère alors le « Stuff Kangoroo ». Et ainsi de suite…

Notre travail peut être amusant, et sérieux. Derrière cette peluche « pas sérieuse » il y a une pratique très précise de génie logicielle, celle de fixer tout de suite la construction du logiciel. Et ça marche ! Alors n’hésitez pas à aller chez Toyr’us et d’acheter un énorme Ours en peluche, et de le donner à l’équipe de développement. J’ai repéré une peluche de « Sully » du dessin animé « Monstres et compagnie » et je compte bien l’embarquer pour notre projet actuel.

Neal Ford montre enfin une page de Wiki généré automatiquement par l’outil de construction, sur laquelle les développeurs peuvent aussi écrire. Ce carnet de bord quotidien raconte la journée passée. A quelle heure Nicolas a commité son code… a quelle heure la compilation s’est terminée, puis les tests. Ensuite on voit que Pierre a annoté la page et qu’il a marqué un détail sur l’installation… Bref un carnet de bord, comme en marine, mais généré en partie automatiquement.

Conclusion
En conclusion, Neal Ford reprend la question du départ : « Pourquoi le développement Agile fonctionne-t-il si bien ?« . Et bien grâce au Feedback, grâce à la communication, et aussi parce que nous percevons le métier de développeur différemment. Nous pensons que la réflexion est aussi importante que la réalisation. Et nous pensons aussi que le développement est fun !

Avant tout, je présente rapidement les deux speakers. Martin Fowler est d’origine anglaise, c’est un geek de 47 ans qui a participé au Manifeste Agile, a co-écrit des livres d’excellentes qualités sur le refactoring avec Kent Beck, et c’est surtout un conférencier de renom. Neal Ford est américain, Geek de 48 ans, passionné par la technologie, auteur de plusieurs livres comme l’excellent « The Productive Programmer« , il travaille aussi chez ThoughtWorks avec Martin Fowler.

Neal Ford débute la présentation en nous apostrophant, afin de nous demander si nous savons pourquoi certains logiciels marchent, pas comment ils marchent. Martin Fowler explique qu’une phrase anglaise célèbre dit : « Plan your work, work your plan« . Cette approche prédictive est intéressante. Un plan est une prédiction de ce que l’on souhaite, plutôt une prévision. Et pour aller plus loin, le succès d’un projet dans ce cas, serait de dire que vous avez respecté votre plan à la lettre. Le succès des projets est défini sur la base d’une prévision. Cette approche prédictive est intéressante dans certains domaines, mais elle doit être discutée lorsque l’on parle de développement logiciel. Elle ne fonctionne que si vous êtes en mesure de préparer un ensemble clair et indiscutable de demandes, et que cet ensemble n’évolue pas dans le temps.
Reconnaissez tout d’abord que c’est difficile. Il est assez difficile de tout prévoir, et de tout planifier. Et ce, d’autant plus que le projet est long.

Martin demande aux chefs de projets qu’il rencontre, si les exigences sont stables. Et c’est plutôt rare. Un sondage dans la salle remplie de près de 500 personnes montre aussi qu’en général, les demandes évoluent ou sont précisées alors que le développement a débuté. Presque personne n’a de demande stables. La communauté de l’approche traditionnelle le sait très bien. Alors ils cherchent à stabiliser et à figer les requierements. Ils mettent un point d’honneur à vous rendre la vie difficile si vous souhaitez changer quelque chose.

Dans le monde Agile, nous savons que le changement est une composante du développement logiciel. Cela nous permet de nous en servir comme d’un avantage, plutôt que de le subir. Nous avons développé des techniques pour absorber le changement, tout en délivrant le logiciel. La première de ces techniques, est de séparer la phase de recueil des exigences, de la phase d’implémentation. Pour parler de Scrum, nous avons une étape de capture des requierements, c’est l’alimentation du Product Backlog. Et nous avons par ailleurs un cycle de développement, qui travaille sur un périmètre stable. Vous voyez que nous avons bien besoin de figer à un moment donné les demandes, mais nous le faisons sur une petite période de 2 à 3 semaines.

How do we do this ?
Nous passons d’une approche prédictive à une approche adaptative. Le secret de l’Agilité c’est que l’on ne peut prévoir tout, mais que par contre on sait s’adapter. D’où ce mot « Agile » finalement. Faire de l’Agile ce n’est pas jeter des plannings. Au contraire, nous serons en mesure de donner un planning chaque semaine. Nous serons en mesure de prédire avec précision les 2 semaines qui arrivent.

Ensuite, pour réussir il ne faut pas uniquement appliquer des méthodes Agiles et penser que cela va réussir. Il faut absolument prendre de bonnes pratiques de programmation. Tests unitaires, intégration continue, refactoring, vous les connaissez tous je pense. Martin propose de relire un papier publié il y a 10 ans, remis au goût du jour en 2004, que chaque Architecte Agile devrait connaître : « Is Design Dead ?« . Faire de l’Agilité ce n’est pas jeter le Design à la poubelle. Au contraire.

Martin Fowler raconte qu’il va parfois dans certaines entreprises qui sont passées d’une approche classique à une approche Agile. Et les projets ne réussissent pas mieux. L’Agilité permet même de se planter plus vite en fait. Il rappelle l’importance des techniques de programmation et de développement telles que celles de l’eXtreme Programming. Faire de l’Agile sans changer sa méthode de travail ne permet pas de réussir mieux. A méditer lorsqu’un consultant de 19 ans de McKissé vous vend de l’Agilité… alors qu’il n’a jamais programmé.

Donc pour résumer cette première partie : passez de l’approche prédictive à l’approche adaptative.

La seconde distinction
Une photo de Taylor nous rappelle qu’au XXe siècle la vision du Taylorisme visait à séparer l’exécution d’une tâche de sa définition. Ecoutez bien ce qui va suivre, moi j’ai adoré. Il y a 100 ans, nous pensions que pour être plus effectif, il fallait que des gens pensent à ce qu’il faut faire, et que d’autres réalisent cette tâche. C’est le métier d’Ingénieur ou d’Architecte, ce métier où tu penses à ce qu’il faut faire. Mais dans le développement informatique, nous avons juste oublié la partie « réalisation », la partie « artisanale ». Et c’est pour cette raison que de très bons scientifiques, en mesure de penser, sont de très mauvais exécutants. Personne ne leur a appris à programmer.

Vous savez pourquoi il faut le faire, mais vous ne savez pas comment faire…
N.Martignole

L’approche traditionnelle du développement logicielle essaye de séparer ceux qui conçoivent de ceux qui réalisent. Cette vision fonctionne si les gens qui réalisent sont prévisibles. S’ils suivent à la lettre le processus standardisé, comme un ouvrier finalement, oui cette approche devrait marcher. Alistair Cockburne explique que les gens ne sont pas prédictibles :

In the title, [of his article] I refer to people as « components ». That is how people are treated in the process / methodology design literature. The mistake in this approach is that « people » are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.
[Alistair Cockburn non-linear]

Dans l’approche traditionnelle, nous pensons que les processus vont nous aider. Cela va plus loin, car certaines approches (Model Driven Architecture) proposent de retirer la possibilité de développer, pour plutôt générer du code. La génération automatique de code permettrait d’économiser du temps. Cette approche essaye de combattre le caractère imprévisible de l’être humain. Générer un logiciel par modélisation c’est mettre un terme au chaos de la programmation classique.

Je pense à titre personnel que l’approche MDA permet de déplacer la complexité, mais qu’elle ne peut pas être une solution pérenne pour développer des projets de bout en bout. Lorsque nous aurons compris que la programmation d’un logiciel complet ne peut pas être automatique, nous aurons fait un grand pas.

Les développeurs sont donc les personnages les plus importants dans le développement logiciel. Or ils ne sont pas prévisibles, il est donc stupide de voir les gens comme des ressources. L’utilisation du jour/homme fait beaucoup de tord à notre industrie. Je connais personnellement des personnes qui font en 1 journée ce que d’autres font en 20 jours. Et je me mets dans les 20 jours. Et inversement, je peux faire des choses en 1 journée qui demanderaient 20 jours à un autre développeur. Nous ne sommes pas égaux devant les problèmes de programmation. Nous ne pouvons donc pas prévoir la fin d’un projet en divisant le nombre de jours par la « quantité de ressources disponibles« . Mettez-vous cela dans le crâne une fois pour toute.

Alors comment cela fonctionne-t-il ? Martin Fowler explique que nous devons prendre un groupe de développeurs, mettre en place quelques règles, puis ensuite s’adapter et faire des rétrospectives afin de progresser. Il est contre-productif d’utiliser des processus et de la standardisation, cela tend à niveler par le bas les niveaux des équipes.

People comes first, and they chosse their own process they follow, not the opposite.

En résumé, Martin Fowler a parlé de l’attitude par rapport au planning, et de l’attitude par rapport aux gens.

Fin de la première partie
Retrouvez la suite de cette KeyNote dans un deuxième article demain

L’ouvrage commence par un questionnaire qui permet d’identifier sa connaissance de la gestion de projet. Le choix entre méthode de gestion de projets traditionnelles et méthode Agile est proposé au lecteur un peu plus loin. Ce que vous apprécierez, c’est la vraie démarche d’accompagnement pour passer des méthodes traditionnelles aux méthodes Agiles. L’expérience de l’auteur permet de trouver les mots justes.

Le recueil des exigences est couvert en proposant plusieurs techniques pour hiérarchiser les besoins correctement. La gestion du temps, la planification des ressources, avec une démarche itérative, on parle même de la technique du Pomodoro dont j’avais entendu parler par Eric Lefevre.

A propos d’expert, un nombre important de personnes connues de la communauté francophone a participé au livre. Des témoignages appuient la présentation de Véronique. 16 experts en tout, dont Christophe Addinquy, Régis Médina, Laurent Bossavit, David Gageot, Claude Aubry, Freddy Mallet pour ceux que je connais par exemple.

Les derniers chapitres sont consacrées au pilotage du projet avec des indicateurs de qualité, de risque et de performance. Un chapitre est consacré à la gestion de l’équipe, à la gestion des sous-traitants et à l’animation des équipes. Très justement placé dans le cadre de la gestion de projet Agile.
Enfin le livre se termine par un accompagnement du changement. Si vous souhaitez passer à l’Agile, la conduite du changement est bien expliqué.

En conclusion je pense que ce livre est un pont entre la gestion classique et la gestion de projet Agile. Il sera lu facilement par un chef de projet à la recherche d’un guide de démarrage complet. Je le conseille aussi aux Scrum Master, qui souhaitent élargir le spectre de leurs connaissances. Le recueil de besoin comme la gestion des hommes sont bien expliqués.

Quelques mots sur le speaker. Régis Medina est bien connu dans la communauté Agile Française. Coach Lean spécialisé dans l’accompagnement des équipes techniques, il découvre XP en 98, il a co-écrit avec d’autres auteurs le livre « Gestion de projet : eXtreme-Programming » paru chez Eyrolles. C’est un orateur passionnant, qui propose une vision où le Lean et l’Agile sont mis en parallèles. Et accessoirement c’est un utilisateur d’IDEA IntelliJ, donc je +1 avec plaisir.

Arrêtons-nous un instant sur ce que nous produisons. Parfois, nous suivons à la lettre ce que demande le client. Peu importe la méthode de développement, ou de gestion de projet. Lorsque l’on regarde quelques temps plus tard certains projets, certains apparaissent comme dangereux. Regardez cette théière utilisé par Régis pour illustrer son idée, fruit du travail de Donald A.Norman. Sur le plan du cahier des charges, l’ensemble des besoins sont développés. Simplement, cet objet est inutile. Et combien de projets ou d’outils inutiles avons-nous croisé dans notre carrière ?

Régis Medina pose la question suivante : « Comment faire des logiciels en mesure de satisfaire pleinement les clients ?« .

A priori, la réponse serait de prendre une bonne méthode de développement, et une bonne méthode de gestion de projet. Prenons le cycle en V, qui anime les soirées d’hiver et qui permet de se chauffer grâce aux tonnes de documentations produites…
Faire une spécification pour certains utilisateurs, c’est un peu découper le catalogue de la Redoute dans les pages Jouets. Certains utilisateurs, de peur de manquer, chargent à mort les spécifications fonctionnelles. Le fait de demander en amont aux clients, puis de spécifier de manière exhaustive leurs besoins, peut conduire parfois à une perte de temps, à un certain gâchis.

Les spécifications c’est fait. La conception ressemble ensuite à une équipe dans un sous-marin nucléaire. Impossible d’accéder à l’équipe de développement, c’est du cycle en V. Si tu veux leur parler, on te demandera d »écrire une spécification. Et de la donner aux développeurs avec une fourche.

Une fois le développement terminé tant bien que mal, souvent à l’arrache, vient le temps de la validation. Autant éteindre un feu avec un verre d’eau. Si la Validation se passe bien (ahahah) vous irez en production. Ne donnez pas votre vrai nom au gars qui fait la mise en prod. Il serait capable de venir vous casser la figure. Le déploiement… Régis utilise l’image d’une personne qui a peur.

Alors arrive l’Agile
Après avoir dépeint un tableau noir de la situation, Régis passe à la page « Agile ». Premier principe : nous allons écouter le client et délivrer des incréments de logiciels qui fonctionne, petit à petit. Cela permet de lisser l’inconnu et de s’assurer que le logiciel fonctionne.

Régis explique cependant, qu’en appliquant trop à la lettre les demandes des clients, vous risqueriez de développer une théière avec un manche mal placé. Le client ne sait pas toujours exprimer correctement ses besoins. Et faire de l’Agile, faire du Scrum, ne veut pas dire « ne pas prévoir à 2 ou 3 mois » ou « ne pas faire de l’Architecture ». C’est un anti-pattern de Scrum, que de croire que l’Architecture émerge magiquement du développement (ça c’est de moi).

Le Client n’est pas concepteur de logiciel. Pourquoi lui demander d’apprendre l’UML pour exprimer son besoin ? Si vous commenciez par écouter, et par apprendre le domaine du client… Je sens que Régis est aussi un fan de DDD comme moi.

Alors vient souvent la phrase « oui mais il faut un BON Product Owner« . Cette phrase est à mon avis un moyen élégant de dire « le client est un abruti, il en faut un plus intelligent« .
Je retourne la question : « Oui mais il faut une BONNE équipe capable d’écouter le client« .
Cela va mieux dans ce sens là non ?

Régis explique l’importance de définir le domaine du client, de cadrer les frontières de son problème. Il recommande de travailler par exploration, de découvrir le domaine, les mots du clients, à s’approprier le vocabulaire et la connaissance de celui-ci. C’est du DDD non monsieur Medina ?

Et bien il poste un nouvel acronyme : PDL pour Problem Driven Development.

Notre mission sera désormais de résoudre les problèmes des clients. Et de les résoudre complètement. Les tests vont piloter le développement. Nous, développeurs, sommes là pour comprendre, analyser et résoudre les problèmes du client.
Pour cela, Régis propose d’appliquer deux des principes du Lean :
– Plan Do Check Adjust
– Aller sur le terrain (Gemba)

Demandez à aller voir le client, l’utilisateur qui sera 8h par jour avec votre logiciel. Regardez comment le client utilise votre logiciel, ou comment il utilise un logiciel similaire. Listez les problèmes qu’il rencontre, et tirez-en des leçons pour vraiment écouter le client.

La voix du client
Prenons les 5 points suivants :
1. Donne moi exactement ce que je veux
2. Quand je le veux
3. Où je le veux
4. Soyez fiables
5. Ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre

Le point 1 apporte la valeur. Les points 2 à 5 seront du gachis pour le client s’ils ne sont pas respectés. Les 2 points les plus importants : le 1 et le 5 : donnez moi exactement ce que je veux et ne me faîtes pas perdre mon temps, je n’ai pas envie d’apprendre à utiliser votre logiciel. Le meilleur exemple ? Pensez à l’iphone. Avec une ergonomie et une puissance importante, vous allez à l’essentiel. Si seulement nos bonnes vieilles applications de gestion pouvaient s’en inspirer…

Le meilleur service finalement, c’est celui que l’on ne voit plus. Régis nous demande de réflechir à tout ce qui est mis en oeuvre entre toi, lecteur qui lit cet article, et les byes stockés dans une base MySQL sur un serveur quelque part… sans parler d’électronique. Vous vous rendez compte du parcours de l’information ?

La démarche d’être très simple, très rapide et très efficace est aussi illustrée par Google. Lorsque vous arrivez, que vous tapez un mot, puis que vous partez sur une page de résultat, il s’écoule moins de 5 secondes… Quand on pense à tout ce qui se passe derrière, en amont, c’est assez impressionnant.

Régis propose donc de nous faire réfléchir aux meilleurs choix pour résoudre le plus efficacement possible le problème du client.

Regarder la performance
On ne peut améliorer que ce que l’on mesure. Il faut des indicateurs, afin de se rendre compte de ses progrès ou non. Que ce soit le nombre d’utilisateurs, le nombre d’appel sur la hotline, ou le taux de pertes de paquets réseaux, il faut des indicateurs.

Voir les problèmes
Un problème est l’écart entre l’indicateur et sa valeur actuelle. Gemba dans la démarche Lean, nous pousse à aller sur le terrain, pour comprendre ce qui cloche. Regardez l’utilisateur, la séquence d’utilisation, les stratégies d’évitement qu’il met en oeuvre pour résoudre un problème… c’est très intéressant. Comme dit Régis : « tant que l’on ne l’a pas vu… on ne l’a pas vu… c’est le problème ».

La courbe de connaissance entre vous, développeurs, et eux, les utilisateurs, est aussi très importante. Un développeur « sait » comment marche son logiciel, puisqu’il l’a codé. Quel est l’écart entre ce que sait le client et ce que vous savez ? Quel est la taille du problème (cf plus haut) ?

Inversement, les développeurs parfois ne connaissent pas le métier fonctionnel. Cela donne des perles, comme des objets financiers implémentés avec des getter/setter, alors que l’objet lui-même, dans la vraie vie, EST IMMUABLE ! Je m’égare…

Résoudre le problème
Résoudre c’est bien, mais il faut être proactif, et il faut penser en permanence à l’amélioraton du système. Pour cela, la technique du PDCA : Plan Do Check Adjust. Il faut voir les causes d’un problème, anticiper le résultat lorsque le souci sera corrigé, élaborer une contre-mesure en cas d’erreurs.

En tirer de bonnes leçons
Ecoutez les clients, et mettez en place des ateliers d’apprentissage afin que les développeurs s’approprient le domaine du client. Pour travailler, faites des ateliers de prototype, des interviews, des sessions de brainstorming avec le client. Lorsque vous développerez votre prochain site Web avec Play! Framework, ou votre application de gestion sérieuse avec Play! Framework, pensez aux écrans, à l’idée que pour résoudre un problème, il faut aller vite.
Imaginez Google ou l’interface de l’iphone développé par un gars qui n’aurait aucunes idées de votre besoin… ou qui ne chercherait pas à résoudre efficacement et rapidement vos problèmes…

Conclusion
En conclusion, Régis nous rappelle les principes de la démarche Lean, et de sa possible mise en place dans les équipes de développement logiciel. Avec de grands principes, qui placent le client au centre des préoccupations, j’ai bien accroché. J’aime aussi cette vision où le développeur et ses frameworks n’est plus le plus important. C’est vrai que parfois, nous donnons l’image de gosses qui bidouillent avec une boîte de « Petit chimiste », alors que l’on nous demande juste de faire une chose : résoudre les problèmes des clients simplement, le plus efficacement possible, et sans lui faire perdre son temps.

A méditer.

Merci à Régis, en espérant avoir retranscris l’esprit.

J’attaque la journée par une présentation sur la PNL. Ensuite nous avons présenté Domain Driven Design avec François Wauquier. J’ai passé un bon moment et je n’ai pas vu l’heure passer. Juste le temps de remballer le Mac, et nous passons dans la salle d’à côté.

Jean-Laurent de Morlhon et Eric Mignot présentent un sujet sur Scrum intéressant : « Comment j’ai remplacé 30% de mes développeurs en adoptant l’Agilité« . Jean-Laurent présente son retour sur la mise en place de Scrum chez Vidal Software. Avec une expérience de presque 4 ans sur le sujet, ce fut très intéressant. Eric Mignot de Pyxis était là pour jouer le rôle du Coach et pour nous aider à trouver le sens et à nous faire réfléchir sur le témoignage.

J’ai beaucoup aimé cette présentation. C’est un témoignage vivant de la mise en place de l’Agilité dans une organisation, chez un éditeur. Une équipe de 10 développeurs, plusieurs produits, la place des Product Owners, la relation avec la hiérarchie, tous les sujets ont été abordés.

Jean-Laurent présente les différentes versions de leur « Scrum Board ». La version v1 classique avec « To Do/Checkout/Done ». Puis l’ajout d’une colonne « Good » pour que le Product Owner puisse donner son retour. Les Stories restent sur une ligne, et ce sont les Tasks de la Story qui naviguent de colonne en colonne. En 4 ans, le tableau s’est plus enrichi que simplifié. Mais il a répondu aux besoins de l’équipe.

La validation au fil de l’eau par le P.O est une démarche intéressante. Elle consiste lorsque le P.O est disponible, à faire une validation dès lors qu’une Story est terminée.

Eric insiste aussi sur l’importance du mot « démo ». Lorsqu’il arrive dans des équipes et que celles-ci disent « on fait la démo au PO ? « , c’est très intéressant. Le mot démo véhicule une intention différente du mot « rétrospective ». Ce mot tend aussi à influencer la personne qui vient assister à la rétrospective. Ce n’est pas un mauvais mot, c’est un mot qui donne de l’information sur la manière dont l’équipe perçoit son travail.

La rétrospective justement, est le point qui pendant les 6 premiers mois, n’a pas du tout été fait par l’équipe. Avec le recul, Jean-Laurent explique que l’équipe étant jeune avec l’Agilité, ils ne percevaient pas l’intérêt immédiat de la rétrospective. Puis ensuite, petit à petit, le besoin a émergé. Après le Design émergeant, on a la « Rétro-émergence »…
Pour donner son retour, Jean-Laurent détaille les techniques simples utilisées lors des rétrospectives. Elles permettent en fait de se congratuler entre membre de l’équipe, sans rendre cela « artificiel » ou génant, mais en permettant naturellement de reconnaître les efforts de chacun. Intéressant, surtout dans la culture Française assez peu friande des congratulations.

Faire de l’Agilité, cela entrainera aussi des frictions. Il y eu quelques échanges mémorables. Le premier P.O est parti, remplacé par une personne qui prendra ses fonctions un peu plus tard. En attendant, l’équipe a pris le rôle de P.O, mais ce ne fut pas l’idéal.

La « Sprint review » (plutôt que le terme « Demo ») permet de se resynchroniser entre membres de l’équipe, et avec le Product Owner. Il est primordial d’avoir un logiciel qui tourne. C’est le bon moment aussi pour s’assurer que le Product Backlog est à jour.

Eric demande si certains font faire la « Demo » par le Product Owner ? Après tout il faut qu’il tire le meilleur parti de cet événement. A peu de moment, le mot Scrum est cité. Eric emploie souvent le mot « Processus Itératif Incrémental« .

Jean-Laurent montre aussi des graphiques en forme de radar, qui montre Spring après Sprint l’évolution des critères de qualité de l’équipe. Sans le savoir, je faisais la même chose il y a 2 ans chez Reuters ! Great minds gets together !

Le sujet des Estimations est intéressant. Jean-Laurent n’essaye pas d’expliquer ce qu’est une estimation, ou ce qu’il faut faire. Il raconte ce qu’ils ont fait, à l’époque.
Au début, l’équipe utilise l’échelle « jour/homme ». Calculé en amont des Sprints, c’est finalement assez mal vécu et utilisé par l’équipe. Cela permet par contre de travailler « à l’ancienne » avec les équipes externes de management, en demande de chiffres.

Ils essayent ensuite une autre approche : une Story est côté en terme de « points de complexité », puis les Tâches de cette Story sont estimées en jour/homme au moment où la Story est dépilée. C’est assez pratique car on attend le dernier moment pour donner un engagement.

Personnellement, j’essaye de rester sur les points de stories. J’ai appelé cela « un nombre de patates » pour vraiment montrer aux développeurs que ce chiffre regroupe une estimation de temps, de risque et de confiance. J’aime bien avoir une unité virtuelle, afin de ne pas tordre ensuite l’agenda avec une notion de jour/homme.

Jean-Laurent raconte l’histoire d’un développeur qui avait pour habitude de suivre à la lettre les estimations en jour. Une tâche est estimée à 2 jours ? Il prend 2 jours. Une autre tâche est estimée à 5 jours ? Il prend 5 jours. Un jour, il voit le développeur entrain de faire autre chose sur son PC. Il lui demande ce qu’il fait. Comme celui-ci a terminé, il attendait en fait d’avoir écoulé les jours pour prendre une tâche suivante sur le tableau…

Nous parlons ensuite du Daily Stand-up Meeting. Dans certaines organisations, cette cérémonie est vécue comme du Reporting. Chaque développeur donne son point d’avancement et le Scrum Master (qui soit-dit en passant n’a rien à faire à cette réunion) met à jour les « reste à faire ».

Eric ré-explique l’utilité et l’organisation du Daily Stand-up meeting. C’est une cérémonie où tous les sens sont en action. La vue, l’ouïe, le toucher pour bouger les post-its. Bien mieux qu’un compte-rendu de réunion sur papier ou une téléconférence par exemple. Son utilité est de synchroniser les activités de chacun au sein de l’équipe. Le Scrum Master doit s’effacer. ll peut noter quelques points à vérifier, mais son rôle est simplement de s’assurer que la réunion a lieu chaque jour. Ensuite, il peut aller prendre un café.

Eric propose de faire le test suivant si vous êtes Scrum Master. Ne venez pas un matin à la réunion. Que se passe-t-il alors ? Est-ce que l’équipe se regroupe ou non ?

Pour terminer, Jean-Laurent balaie quelques points sur la mise en place de méthodes Agiles et certains mots comme « Stress » par exemple. Il reconnaît que depuis l’adoption de Scrum, 3 développeurs sur 10 en 3 ans sont partis. Pour certains, c’est trop violent. Devoir se réunir chaque matin et dire à haute voix : « hier j’ai bien galéré et je n’ai pas codé une ligne » est parfois un exercice insurmontable.

Le Scrum Master a un devoir de communication. Eric enfin termine en nous donnant l’une des utilités de passer en mode « Processus Itératif Incrémental » : ces approches font ressortir les dysfonctionnements dans l’entreprise et dans les équipes. J’évoquais il y a un an et demie l’effet « pétard » de Scrum : il tend à faire exploser les tensions et les points de dysfonctionnement d’une organisation. Et puis il a un effet euphorisant lorsqu’il fonctionne, car avoir une équipe qui délivre un logiciel, sans souffrances, et avec plaisir, c’est un peu le sens de notre métier non ?

Fin du premier billet

J’ai ensuite assisté à deux présentations que je couvrirai demain dans d’autres articles :
- Pierrre Piezzardi d’OCTO Technology sur la question suivante : « Le Lean management peut-il transformer l’entreprise ? »
- DRH, Agile, WTF avec Iva Konstantinovic et Gabriel de Pyxis. Débat très intéressant sur la mise en place de Scrum chez un éditeur dans la finance.

La soirée s’est terminée comme l’an dernier par un repas assis, sur des grandes tables rondes de 8-10 convives. L’occasion de parler recrutement, recherche d’emploi, Git, Spring WebFlow, les vieux développeurs, DVCS et Agilité…

Le cadre est tout d’abord original : dans le bois de Vincennes, au Chalet de la porte jaune. Les conférences se déroulent dans des petites salles de 50 à 80 places. C’est l’occasion de prendre connaissance des dernières avancées dans le monde Agile, dans la gestion de projet et dans le pilotage des équipes.

Je co-présente avec François Wauquier de SFEIR un sujet sur DDD (Domain Driven Design). Ce sera l’occasion de vous donner un retour pratique et théorique, et de vous faire comprendre ce que cela a changé pour moi, lorsque je développe. J’avais eu l’occasion de suivre la formation Domain Driven Design avec Eric Evans chez Zenika en février dernier, et c’est un très bon souvenir.

La semaine prochaine il y aura aussi un show sur scène avec les meilleurs programmeurs du monde Java, en tournée mondiale et qui seront spécialement sur scène pour vous. J’ai entendu une rumeur qu’un célèbre Juggeur sera sur scène pour animer le show. L’objectif est de faire du « live-programming » en mettant sur scène des binômes : un expert et un débutant. Chaque binôme aura 10 minutes pour résoudre un problème devant l’assemblée. Les juges évalueront la performance technique, mais aussi la performance artistique. Il n’est pas interdit de faire du bruit, de chahuter et de crier pendant les sessions de live-coding. Pour terminer, tout ceci se déroule pendant l’heure du déjeuner. Donc n’hésitez pas à venir voir le show… surprise !

Rendez-vous lundi matin pour suivre l’événement sur le Touilleur Express.

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.