On reproche parfois à #hypertextual d’être un blog un peu stratosphérique, parlant de livres et de théories Californiennes et se confrontant assez peu finalement au terrain et au ici et maintenant. Admettons que ce soit recevable.
Je vais donc m’attacher à concentrer quelques billets sur l’hyper-local et cela tombe bien : la caravane de l’Agile Tour s’est arrêtée dans notre splendide ville de Bordeaux la semaine dernière. Une bonne occasion pour aller à la rencontre de la communauté Agile locale, celle qui, au quotidien, s’attache à redonner du sens et de la noblesse aux métiers des systèmes d’information et, ce faisant, contribue à transformer nos organisations vers des entités plus solubles dans l’économie du 21ème siècle.
Félicitations aux organisateurs pour une conférence sold-out passionnée et passionnante … (Attention long billet : +1500 mots)
Ce que les développeurs et les testeurs devraient apprendre les uns des autres
Après l’introduction de Samir Hanna (de l’équipe d’organisation), la première keynote de la journée a été prestigieuse et internationale avec l’intervention de David Evans pour discuter des tests dans les processus Agiles dans une perspective d’apprentissage. Evans rappelle que nous apprenons à travers 3 choses : en voyant les choses de puis une perspective différente, en essayant de nouvelles choses et, enfin, en apprenant de nos erreurs.
Un grand nombre des problèmes rencontrés par les organisations mettant en oeuvre l’Agile sont liés à cette relation développeurs / testeurs : l’objectif de la session d’Evans était donc de traiter ces points en proposant un échange de perspectives entre les deux métiers. L’occasion de rappeler quelques vérités bien senties : “Code that is not tested does not work. This seems to be the safe assumption” – “Kent Beck, “Every bug is evidence of a missing test” ou encore “Thinking you improve quality by making more testing is like thinking you can lose weight by weighting more often”.
Souvent le développement voit les tests comme quelque chose qui ralentit le développement : “Speed of development alone is not point. Speed of delivering quality software is” ou, au sujet de l’Acceptance Test Driven Development : ATDD slows down development, just like passengers slow down the bus.
Evans a aussi discuté de la couverture des tests. L’objectif de l’intégralité du code couvert est un peu similaire à celui des systèmes à disponibilité 100% : très coûteux. Le rôle des tests est donc d’offrir le meilleur compromis quantité de tests Vs coûts, en utilisant pour cela la boîte à outils que propose le quadrant des tests bien connu.
Le seul point de la certification ISTQB qu’Evans juge utile dans le contexte de l’agilité est celui de la chaîne de causalité. Au départ il y a une erreur humaine, ce qui introduit une erreur dans le système, la survenue du cas d’erreur et enfin l’erreur elle même en tant que divergence par rapport à la marge de fonctionnement. Cette chaîne doit être prise en compte lors de l’étude de la cause racine.
Enfin Evans invite les développeurs et testeurs à se considérer comme des amis car ils sont complémentaires et ont des choses à apprendre les uns des autres. Leurs perspectives différentes sur le produit leur permettent d’élaborer ensemble des produit nouveaux et d’apprendre les uns des autres : les 3 conditions de l’apprentissage sont réunies.
Guilty code until proven innocent
Indépendamment de celle de David Evans, de nombreuses sessions ont été dédiées aux tests logiciels automatisés (i.e exécutés automatiquement). A ce sujet il y a plusieurs écoles. Les excellents développeurs auto-proclamés prétendent que ce n’est pas nécessaire. Lorsque c’est David Heinemeier Hansson, qui se moque des développeurs se vantant d’écrire 3 fois plus de tests que de code de production, cela peut-être recevable. Lorsque c’est un développeur local, peu curieux, qui ne s’interesse pas aux bonnes pratiques, qui ne contribue pas à des logiciels open source etc … c’est beaucoup plus discutable.
L’objectif des tests automatisés est simple : identifier les problèmes au plus tôt pour en réduire le coût et faciliter la résolution. Une approche très Lean au final. Gilles Mantel a été très convaincant dans sa présentation sur le ROI des tests automatisés. Son analogie avec les Options financières pour illustrer ce ROI est éloquent et très actionnable. Basé sur une expérience solide, un retour très instructif.
La partie sur le Behavior Driven Development par Guillaume Saint-Etienne (qui a remplacé au pied levé une session annulée au dernier moment) a été un peu moins convaincante. Guillaume a expliqué en toute transparence (ah, la culture Agile …) que le BDD n’apportait pas toutes les vertus qu’on lui prêtait. Une présentation peut-être un peu trop technique où Guillaume s’est attaché à décrire les problèmes que le BDD traitaient dans son contexte de développement. On regrettera l’utilisation de media audio (qui n’apporte que du spectaculaire en brisant le flux de la présentation) ainsi que des détails très techniques qui nous ont peut-être un peu fait perdre de vue l’avantage global de cette approche. Convaincu cependant qu’il s’agit là c’est de quelque chose à tester.
Démo et des maux
Une présentation très rafraîchissante a été celle de Caroline Damour Nobi et Emilie Franchomme sur la Sprint Demo. Passons rapidement sur l’effet désengageant de la lecture de feuille lors de la présentation pour nous consacrer à l’essentiel : le contenu. Caroline a fait remarquer qu’il existe de la littérature abondante pour environ tous les aspects du scrums (les différents rôles, les principes, les différentes cérémonies) sauf sur la Démo.
Caroline a donc organisé un questionnaire auprès d’une cinquantaine de personnalité de l’Agile en France (un questionnaire en ligne est accessible) autour de cette réunion de fin de sprint durant laquelle l’équipe montre ce qu’elle a réalisé au cours de l’itération. L’objectif de cette réunion : finir les choses. Les développeurs sont perfectionnistes et ils ont toujours fini à 90%. La démo permet de finaliser complètement, de tirer un trait et passer à l’itération suivante. Le second objectif est d’obtenir du feedback et là c’est un authentique test pour la culture collaborative de l’organisation : “La qualité du feedback est un des indicateurs de la maturité de l’équipe Agile.”
Enfin la démo permet d’obtenir des petites victoires régulières lorsque le Product Owner peut voir que ce qui a été développé (ou modifié suite aux derniers feedbacks) est en adéquation avec sa vision du produit. On rejoint ici cette planification des petites victoires rapides selon John Kotter, action essentielle dans la conduite du changement.
Lean et Kanban
On observe sur ces 10 dernières années un rapprochement très intéressant entre les approches Lean et l’Agile. Ce processus a été démarré dès la publication en 2003 de Lean Software Development par Tom & Mary Poppendieck puis avec les travaux de David Anderson en particulier sur l’utilisation du Kanban dans un contexte Agile. Je crois profondément en la théorie de Roland Burt (exprimée dans The Social Origin of Good Ideas) selon laquelle l’innovation survient grâce aux personnes qui relient différentes communautés d’expertise.
Le Lean apporte une réponse à deux questions auxquelles, à mon sens, les méthodes Agiles seules n’ont pas su répondre : 1/ Comment inscrire les Managers dans une transformation Agile et 2/ Comment passer à l’échelle ?
L’excellent Antoine Contal (consultant chez Operae Partners, les organisateurs du Lean IT Summit) a montré comment les Managers Lean pouvaient complètement s’inscrire dans l’approche Agile et retrouvaient ainsi un rôle très important : celui de coach et d’enseignant. Qui enseigne la résolution de problèmes aux équipes pour garantir l’amélioration continue et qui s’assure qu’il assigne les bons problèmes aux bonnes personnes au bon moment pour garantir le bon développement de chacun. Le consultant a rappelé sa définition du Lean : du management visuel et des équipes qui ont les moyens de résoudre leurs problèmes pour s’améliorer.
De son côté, Laurent Morisseau (auteur du livre Kanban pour l’IT), acteur infatigable du sujet nous a rappelé les vertus du Kanban. Une approche très prudente de sa part car le Kanban n’est pas forcement très apprécié par les supporters radicaux du Scrum. Une présentation très convaincante cependant, parfaite suite à celle d’Antoine. Sa définition du Kanban est très séduisante : une méthode incrémentale de gestion du changement par l’amélioration continue des processus.
Selon Morisseau le Kanban regroupe 5 pratiques, de la plus superficielle à la plus profonde : 1/ Visualiser le flux 2/ Limiter le travail en cours 3/ mesurer et gérer le flux 4/ Rendre les règles explicites et 5/ s’améliorer de manière collaborative. La dimension incrémentale passe par ces différentes étapes de cette approche simple, vertueuse, et terriblement efficace. Qui s’avère aussi être terriblement difficile à mettre en oeuvre en ce qu’elle nécessite une bonne dose de courage et de l’abnégation.
Le point intéressant, peut-être essentiel, non remonté par Morisseau : le Kanban est l’outil qui permet de passer Scrum à l’échelle depuis l’équipe jusqu’à la gestion de portefeuille de projets. C’est ainsi que Kniberg le présente [EN], c’est aussi ainsi que les processus Agiles à large échelle sont implémentés au niveau des outils d’Application Lifecycle Management[EN] tels Rally ou VersionOne par exemple. Voir à ce sujet les nombreux slidedecks mis en ligne par l’impeccable Mike Cottmeyer de chez ces derniers.
Noblesse du programmeur
Malheureusement, je n’ai pas pu assister à des sessions pourtant très alléchantes. La première de Jean-Baptiste Dusseaut du crew Arpinum : la voie du programmeur. La seconde est celle de Thierry Cros sur la Sociocratie. Enfin la dernière est celle sur la chasse aux faux semblants et ce retour d’expérience alléchant sur certains échecs rencontrés alors que l’on fait de l’Agile by the book.
Deux autres sessions étaient elles sur le pur métier de programmeur : celle sur les principes SOLID de développement et celle sur la mouvance du Clean Code faisant la promotion de l’artisanat du développement (un peu dans le sens Compagnon Du Devoir, hein). Des professionnels qui défendent la noblesse du métier tout en offrant une grande agilité organisationnelle … l’exemplarité et la passion au service de l’économie de la connaissance.
#hypertextual 
Bonjour Cecil,
Merci pour ce retour !
Une petite précision : Emilie et moi avons pairé tout du long de cette aventure de la démo, du choix du sujet à l’enquête, de l’analyse des résultats au choix du titre, de la synthèse de nos expériences aux slides etc… etc…
Et c’était / c’est absolument génial (si le pair programming est comme cela, les développeurs doivent s’éclater)
Une autre précision : la feuille à la main, c’était pour respecter les citations qui nous ont été faites. Mais feedback bien reçu, perspective d’amélioration pour la prochaine fois !
A bientôt
Caroline
Bonjour Cecil,
encore un excellent billet ! Je m’en suis inspiré pour faire ma propre analyse de lean vs. agile : http://informationsystemsbiology.blogspot.fr/2012/12/lean-scrum-agile-and-extreme-programming.html
Merci Yves ! Je viens de lire ton article qui est très éclairant. Il s’agit souvent d’un point de confusion pour les équipes. Je leur ai donc recommandé la lecture de ton billet.