2ème partie consacrée à la Keynote de Martin Fowler et de Neal Ford après l’introduction consacrée à la plannification.
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 !
Merci Nicolas pour ce retour.
Tiens en parlant de pair-programming, j’ai fait un petit retour dessus avant-hier sur mon blog, pour ceux que ça en intéresse :
http://dutheil.brice.online.fr/blog/index.php/2010/07/11/petit-retour-sur-le-pair-programming/
Par contre je n’ai effectivement pas parlé des activations de certaines zone du cerveau. Et pourtant je suis complètement d’accord, Andy Hunt en parle dans son livre Pragmatic Learning and Thinking, il explique la différence entre le « cerveau gauche » et le « cerveau droit », et pourquoi c’est important de faire appel à ces deux types de fonctionnement du cerveau.
J’ai vu également ces choses vis-à-vis de la méthode pomodoro, qui permet de faire des micro itérations dans la journée de ~25min puis de ~5min de pause ou il faut dessiner, aller marcher, etc. Mais surtout ne pas rester coincer devant son écran.
Ça vient d’aujourd’hui sur Yahoo : Les effets pervers du mail au bureau.
http://fr.news.yahoo.com/80/20100716/tbs-lutter-contre-les-effets-pervers-des-3213331.html
Effectivement ça rappelle la courbe de l’efficacité de la communication dans l’article.