BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Comment Diffuser Des Pratiques Techniques Comme Le TDD Dans Une Organisation

Comment Diffuser Des Pratiques Techniques Comme Le TDD Dans Une Organisation

Favoris

Points Clés

  • Le coaching technique consiste à aider les développeurs à changer leurs habitudes quotidiennes et leurs méthodes de travail pour prendre en charge Agile et DevOps.
  • Peu d'organisations réussissent à adopter le TDD. Les développeurs ont généralement besoin d'aide pour passer des exercices pratiques TDD à une base de code de production à grande échelle.
  • Ensemble travailler avec un praticien expérimenté est efficace pour apprendre le TDD, en particulier en combinaison avec des sessions de formation pratiques régulières.
  • « Samman » est une approche du coaching technique. Il comporte deux parties principales  : les heures de travail et d'apprentissage de l'ensemble.
  • Il y a trop peu de coachs techniques ; une méthode concrète comme Samman peut aider les développeurs à commencer à coacher.

L'un des facteurs de succès pour Agile et DevOps est que les développeurs changent leur façon de travailler et adoptent des pratiques telles que le développement piloté par les tests (TDD). Ce n'est pas quelque chose qui se produit tout seul, et bon nombre des manières « habituelles » d'introduire le changement échouent pour TDD. Dans cet article, je décrirai certaines des choses que j'ai essayées qui fonctionnent réellement. Je vais vous expliquer « Samman », qui est la méthode de coaching que j'utilise avec les développeurs.

Pourquoi le TDD est important

Si une organisation construit un produit logiciel, la façon dont les gens écrivent le code est importante. De bonnes pratiques techniques signifient que l'organisation peut créer de nouvelles fonctionnalités dans un délai plus court et de meilleure qualité. Cela devrait signifier respecter les délais et fournir des logiciels fiables. Les développeurs qualifiés voudront travailler pour une organisation avec un code de haute qualité, des pratiques de développement efficaces et une culture saine. D'un autre côté, les organisations qui luttent avec une mauvaise qualité de code et ne parviennent pas à y remédier deviendront finalement incapables de fournir de nouvelles fonctionnalités en temps opportun ou de manière rentable. C'est un mauvais résultat pour n'importe quelle organisation.

Il existe des recherches bien respectées qui montrent exactement ces effets. Le livre Accelerate de Forsgren et al. explique les résultats remarquables d'une étude pluriannuelle des organisations de développement de logiciels. Ils ont étudié de nombreux facteurs et identifié ceux qui contribuent le plus au succès de l'entreprise. En particulier, ils mettent en avant la pratique du Continuous Delivery. Ce terme générique comprend plusieurs pratiques techniques et organisationnelles, notamment le développement piloté par les tests, TDD.

C'est exagéré de dire que faire du TDD conduira à une entreprise de logiciels prospère, mais c'est sans aucun doute une partie importante de l'image. Les équipes qui produisent du code de haute qualité y parviennent généralement en écrivant des tests automatisés de haute qualité, en les intégrant fréquemment et en apportant constamment de petites améliorations de conception. Toutes les équipes ou tous les développeurs de logiciels n'ont pas les compétences pour bien le faire.

Dans mon travail de coach technique, je rencontre beaucoup de développeurs de logiciels habitués à des cycles de livraison longs, intégrant leurs changements peut-être hebdomadairement. Ils améliorent rarement une conception au-delà des changements immédiats nécessaires pour la fonctionnalité particulière sur laquelle ils travaillent. Ces équipes travaillent à une fraction de l'efficacité que je vois dans d'autres équipes où les compétences sur le TDD sont répandues. Le TDD et la base de code de haute qualité qu'il permet ont un effet important sur le travail d'équipe, la capacité à collaborer et le bien-être général des développeurs.

Ce que les organisations font déjà

La recherche Accelerate nous dit qu'il existe un fossé énorme entre les meilleures organisations et les moins performantes. Dans le nouveau monde de la numérisation, du DevOps et de l'agilité métier, de nombreuses organisations doivent améliorer les compétences de leurs organisations de développement de logiciels. J'ai certainement rencontré de nombreux managers, architectes et responsables techniques qui souhaiteraient que leurs équipes de développement utilisent des pratiques plus efficaces.

J'ai récemment effectué un sondage auprès d'environ 300 participants à la conférence ACCU 2021 sur les activités d'apprentissage qu'ils font déjà. (Il s'agit évidemment de participants à la conférence, c'est donc une activité que je n'ai pas répertoriée !) Les choix les plus populaires par ordre décroissant étaient :

  • Revues de code
  • Vidéos de formation en ligne à la demande
  • Cours de formation dirigés par un instructeur pendant 2 à 5 jours consécutifs
  • Pair programmation fréquent
  • Hackathons
  • Communauté de pratique

J'ai ensuite suivi cette question en leur demandant lesquelles de ces activités ils avaient utilisé avec succès pour apprendre le TDD, avec une option supplémentaire de "Je n'ai pas appris le TDD". C'était malheureusement l'option la plus populaire, suivie de la programmation fréquente en binôme et des vidéos de formation en ligne à la demande.

Cela a confirmé mes propres observations selon lesquelles le TDD n'est pas une compétence facile à apprendre ; la meilleure façon de l'apprendre est de quelqu'un qui le connaît, et il faut des efforts et de la répétition avant de devenir à l'aise avec. Les activités comme les hackathons et les revues de code ne fonctionnent pas ; apprendre une compétence comme TDD ne fait tout simplement pas partie de ce qui se passe ici. Même les cours de formation dirigés par un instructeur ont peu de chance de réussir - c'est trop court et trop peu de répétitions pour que les nouvelles méthodes de travail tiennent vraiment.

La programmation en binôme avec quelqu'un qui connaît TDD est l'une des rares choses que j'ai vues qui fonctionne vraiment. Cependant, peu d'équipes ont quelqu'un comme ça avec qui s'associer. Une formation en ligne à votre rythme associée à de nombreux exercices pratiques fonctionne également si les gens sont motivés et s'y tiennent. Cependant, cela pourrait ne pas aider votre équipe dans son ensemble si seules quelques personnes parviennent jusque-là.

Ma propre expérience

En 2005, j'ai découvert le Coding Dojo en tant que forum d'enseignement et d'apprentissage du TDD, et j'ai commencé à constater des progrès en aidant mes collègues à s'y habituer. J'ai écrit mon premier livre "The Coding Dojo Handbook" en 2011. Les Coding Dojos sont un excellent moyen d'amener les gens à apprendre les bases du TDD et à commencer à changer la culture du développement. Cependant, il est devenu clair pour moi après quelques années que ce n'est pas tout à fait réussi à apporter un changement durable, en particulier dans les organisations où la qualité du code est mauvaise et le TDD est difficile. Il y a un trop grand écart entre le type d'exercices de kata que les gens font avec succès dans le Coding Dojo et la réalité qui les concerne lorsqu'ils retournent à leur bureau.

Ce que j'ai essayé ensuite - la méthode Samman

En 2018, j'ai reçu une invitation fantastique de Llewellyn Falco à travailler en binôme avec lui. J'ai passé deux semaines aux États-Unis en tant que client et j'ai vu que ce qu'il faisait semblait fonctionner. Il utilisait le même type de sessions de code de groupe Kata que je connaissais dans les dojos de codage, ainsi que des sessions pratiques avec toute l'équipe dans le code de production. La combinaison semblait être la clé pour le faire tenir.

Je suis rentré de ce voyage inspiré pour changer de direction dans mon conseil. Au cours des trois années suivantes, j'ai trouvé quatre ou cinq organisations prêtes à me laisser essayer ce nouveau style de coaching technique. J'ai également recruté quelques personnes supplémentaires pour travailler avec moi de la même manière, et nous avons développé l'approche. Bientôt j'ai eu envie de partager ces techniques efficaces.

J'ai décidé que ce style de coaching avait besoin d'un nom pour le distinguer des autres approches et pour aider les gens à le découvrir. « Samman » est un mot suédois qui signifie « ensemble ». Cela semblait approprié pour une méthode qui implique beaucoup de travail « ensemble ». Mon nouveau livre "Technical Agile Coaching with the Samman method" a été publié en janvier 2021.

Qu'est-ce que la méthode Samman ?

Samman est une méthode pour les personnes qui veulent faire la différence et améliorer la façon dont les logiciels sont construits. L'accent est mis spécifiquement sur les pratiques techniques et la façon dont les gens écrivent du code. Un coach Samman partage son temps entre plusieurs équipes de développement logiciel, et la méthode comporte deux parties principales :

  • Heure d'apprentissage
  • Travail ensemble

Pendant l'heure d'apprentissage, le coatch utilise des exercices et des techniques d'apprentissage actif pour enseigner la théorie et la pratique de compétences comme le TDD. Dans les sessions Ensemble, toute l'équipe collabore avec le coach pour appliquer les techniques de développement agiles dans leur base de code de production habituelle. (Certaines personnes peuvent connaître Ensemble Working sous un autre nom : Mob Programming.)

Heure d'apprentissage - comme un Coding Dojo court et fréquent

Je suis sûr que vous avez eu l'expérience d'apprendre une nouvelle compétence. Peut-être avez-vous appris un instrument de musique, une langue étrangère, un nouveau style de danse, de cuisine ou un nouveau sport. Si vous avez réussi, je suppose que vous avez eu une forme d'enseignement ou de coaching ainsi que quelques heures de pratique dédiée. Les meilleures expériences d'apprentissage impliquent généralement d'être dans un groupe amical avec un enseignant inspirant et des exercices pratiques amusants présentés au bon niveau. C'est l'essence d'une heure d'apprentissage.

Je suis très inspirée par les méthodes d'enseignement utilisées par Sharon Bowman. Son livre à succès « Training from the Back of the Room » décrit le modèle d'enseignement « 4C ». Chaque heure d'apprentissage est structurée avec ces quatre parties :

  • Connection
  • Concept
  • Pratique concrète
  • Conclusion

Il y a environ un paragraphe, je vous ai demandé de vous rappeler avoir appris une nouvelle compétence. C'est une sorte d'activité de « connexion ». Pour apprendre quelque chose de nouveau, vous devez l'intégrer à ce que vous savez déjà. Cela aide à donner aux apprenants l'occasion de rappeler leurs connaissances antérieures et de les mettre en tête avant de passer à la partie suivante, le « concept ».

Se tenir devant un jeu de slides et parler est une façon de faire comprendre un nouveau concept aux gens. Cependant, ce n'est peut-être pas toujours le moyen le plus efficace. Vous voulez alimenter leur curiosité, les amener à participer activement à leur propre apprentissage. Le cerveau se nourrit de la variété, du mouvement, des interactions sociales et de la découverte par vous-même. J'essaie généralement de minimiser le nombre de slides.

Si le concept que je veux faire passer est un aspect du TDD, je ferai le plus souvent une courte démo de la technique. S'il s'agit d'un modèle de conception ou d'un problème de testabilité, je pourrais donner aux participants du code à réviser. Pour une nouvelle technique de codage comme les tests paramétrés, je pourrais leur demander de rechercher sur le Web des extraits de code ou des conseils de conception.

La « pratique concrète » signifie généralement écrire du code et faire un kata de code pratique. C'est souvent la partie la plus longue de l'heure d'apprentissage - environ 30 à 45 minutes de travail soit tous ensemble dans un ensemble, soit en petits groupes de deux ou trois. Vous ne pouvez pas écrire beaucoup de code pendant cette période, vous devez donc préparer un point de départ et des instructions claires pour que les gens puissent commencer à appliquer immédiatement ce qu'ils ont appris sur le « concept ».

J'utilise des katas de code depuis des années dans les coding dojos, et j'en réutilise maintenant beaucoup pendant les heures d'apprentissage avec peu de modifications. Les nouveaux exercices que je propose maintenant ont tendance à être plus petits et plus axés sur une technique particulière. J'utilise aussi souvent le même kata pour enseigner plusieurs choses, et j'ai plusieurs branches dans le référentiel configurées avec des points de départ différents. Le Supermarket Receipt en est un bon exemple. Je l'utilise pour enseigner la refactorisation ainsi que divers aspects des tests d'approbation.

Avant la fin d'une heure d'apprentissage, nous prenons toujours quelques minutes pour élaborer nos " conclusions " de la session. Cela aide les gens à se souvenir de quelque chose s'ils l'écrivent avec leurs propres mots, ou s'ils expliquent à une autre personne ce qu'ils ont appris. Enfin, j'encourage les participants à refaire l'exercice plus tard, par eux-mêmes. La fluidité vient de la pratique, et à un certain niveau, il faut juste y mettre le temps.

Travail ensemble sur une tâche typique

Tous les brillants esprits travaillant ensemble sur la même chose, au même moment, dans le même espace et sur le même ordinateur - Nous appelons cela la "Mob Programming"

– Woody Zuill

Cette citation est tirée de "Mob Programming - a Whole Team Approach" de Woody Zuill et Kevin Meadows. À l'origine, j'ai appris cette technique auprès de Zuill et d'autres personnes de son entourage. Depuis, au fil des années, j'en suis venu à préférer d'autres mots pour la décrire. Je dis généralement "ensemble". J'aime la façon dont ce terme implique des personnes amicales qui collaborent, comme un groupe de musiciens. L'essence de la technique est cependant la même. 

De même que les musiciens doivent s'exercer ensemble avant de créer un très bon son, les programmeurs doivent apprendre à collaborer en douceur au sein d'un ensemble. Il y a différents rôles que vous pouvez jouer dans le groupe, qui nécessitent des compétences différentes. L'un des premiers défis à relever en prenant le rôle de "navigateur" est de s'exprimer verbalement sur le code et la conception. Vous devez dire "déclarer une nouvelle variable" ou "mettre en ligne cette instruction de retour" alors qu'auparavant vous n'avez jamais fait que taper cela sans penser à son nom. Une fois que vous avez acquis un nouveau vocabulaire, cela vous permet de penser à un niveau d'abstraction plus élevé et de vous ouvrir à des discussions sur la conception. En fin de compte, toute l'équipe peut s'impliquer dans la réalisation du travail de développement, en mettant en commun leurs connaissances et en produisant un code dont tout le monde est fier.

J'ai observé à de nombreuses reprises ce qui suit dans un contexte d'ensemble : une personne de l'équipe sait comment faire quelque chose. L'ensemble doit faire cette chose. Très vite, tout le monde dans l'ensemble sait comment faire cette chose. Cela se produit tout le temps - les gens apprennent les uns des autres, les connaissances et les compétences se répandent rapidement. C'est ce que j'ai compris en tant que coatch technique. Faire partie d'un ensemble me donne des superpouvoirs ! Si je fais partie d'un ensemble, je peux diffuser ce que je sais de manière très naturelle au fur et à mesure que le besoin s'en fait sentir, avec toute l'équipe en même temps.

Lorsque je coache un ensemble, je les incite souvent à utiliser le développement piloté par les tests (Test-Driven Development). Lorsque nous discutons de ce qu'il faut faire, je leur demanderai d'esquisser une liste de tests. Lorsque quelqu'un commence à implémenter du code, je lui demande d'écrire d'abord un test. Si nous devons procéder à une refonte, je leur demanderai de le faire par petites étapes sûres. Si, à un moment donné, il ne sait pas comment faire, je peux jouer le rôle de navigateur et lui montrer. J'essaie de rester dans ce rôle le moins longtemps possible, juste le temps de changer de direction. Quand quelqu'un d'autre commence à se sentir en confiance pour prendre le relais. Je me retire à nouveau.

Une conséquence brillante pour le travail dans un ensemble est que vous apprenez aussi constamment de nouvelles choses des équipes avec lesquelles vous travaillez. Rien qu'en travaillant avec autant de personnes différentes, vous collectez de nouveaux outils, frameworks et idées de conception, en plus d'être personnellement gratifiant ; cela profitera aussi en fin de compte à l'ensemble de l'organisation, car vous passez du coaching de différentes équipes à la diffusion de ce que vous avez appris.

Dans les sessions ensemble, l'équipe choisit une tâche typique de ce sur quoi elle travaille habituellement. Avec l'aide du coach, l'équipe apprend à appliquer les techniques de développement agile pertinentes. C'est la partie cruciale qui manque si vous ne faites que des exercices pratiques et des coding dojos. C'est là que nous commençons à voir à quoi ressemblent les techniques agiles dans ce code de production sur lequel mon équipe travaille.

Lorsque les gens apprennent à travailler ensemble, deux heures par jour sont suffisantes. C'est pourquoi la méthode Samman permet au coach de travailler avec plus d'une équipe à la fois, s'il le souhaite. Vous pouvez coacher une équipe le matin (deux heures de travail d'ensemble, une heure d'apprentissage) et une autre l'après-midi. Si vous êtes ambitieux, vous pouvez coacher les sessions ensemble de trois équipes et organiser une heure d'apprentissage commune chaque jour. Je dois dire que c'est un peu stressant cependant.

J'ai fait ce coaching à la fois sur place et à distance. Je pense que les deux façons fonctionnent bien, avec des avantages et des inconvénients différents. Lorsque vous êtes sur place, vous avez l'avantage de pouvoir lire le langage corporel, et d'avoir des conversations tranquilles sur le côté pendant que le reste du groupe continue à travailler sans être interrompu. Lorsque vous êtes à distance, vous avez l'avantage que tout le monde peut clairement voir le code sur l'écran partagé, et que chacun dispose d'une chaise, d'un clavier, d'un écran, etc. confortables. Il est également facile pour les gens de consulter la documentation ou d'autres parties du code, puisque chacun a sa propre machine ainsi que l'accès à l'écran partagé. 

.

Je trouve qu'après dix demi-journées de coaching, l'équipe et le coach bénéficient d'une pause ; quelques jours ou semaines avant un autre bloc de coaching similaire de 10 jours. L'équipe obtient un peu de temps pour poursuivre les nouvelles méthodes de travail sans le coach, et est obligée de découvrir ce qu'elle sait vraiment et ce pour quoi elle a besoin de plus d'aide lorsque le coach revient. Le coach a l'occasion de planifier de nouvelles heures d'apprentissage et peut-être de faire du coaching en binôme avec d'autres personnes. Il peut intégrer de nouvelles équipes pour de futurs blocs de coaching. 

.

Les résultats observés

Après un bloc de coaching de 10 demi-journées, j'ai observé que la plupart des équipes obtiennent la prise en main du travail d'ensemble au point qu'elles pourraient le faire sans la présence du coach. C'est en soi une excellente compétence à acquérir pour une équipe - en allant de l'avant, ils peuvent décider quand il est utile d'utiliser cette technique de collaboration. J'ai entendu parler d'équipes qui choisissaient par la suite de travailler ensemble lors de changements importants dans la conception et lors de l'intégration de nouveaux membres de l'équipe. Certaines l'adoptent même comme une partie régulière de leur travail quotidien.

L'autre résultat principal que j'ai observé après seulement un ou deux blocs de coaching était un changement d'attitude. Dans un sondage post-coaching, la majorité d'entre eux ont convenu qu'ils étaient :

  • Plus enclin à écrire des tests unitaires
  • Plus susceptible d'améliorer la conception et de refactoriser en toute sécurité
  • Plus susceptibles de concevoir des cas de test lisibles et maintenables
  • Plus susceptibles de travailler par petits incréments, en committant le code plus souvent
  • Amélioration du travail d'équipe, meilleure collaboration

Jusqu'à présent, je n'ai pas travaillé avec de grandes organisations qui ont réussi à adopter le TDD à grande échelle. J'ai vu plusieurs équipes adopter le travail ensemble assez régulièrement, et commencer à écrire beaucoup plus de tests unitaires. Les changements les plus notables que j'ai observés ont eu lieu dans quelques cas où un membre de l'équipe était déjà assez expérimenté et avait des compétences en TDD. L'accompagnement leur a permis d'amener le reste de leur équipe à commencer réellement à adopter cette pratique, alors qu'auparavant, ils n'en avaient fait qu'évoquer la question. 

Est-ce que le coaching Samman est fait pour vous ?

Je suis convaincu que le monde a besoin de plus de coachs techniques. Il y a tellement d'équipes qui se battent avec du code difficile et qui n'ont pas les compétences techniques agiles nécessaires pour bien progresser. Il y a beaucoup de développeurs et de responsables techniques qui ont peut-être ces compétences mais qui peinent à les diffuser largement et rapidement dans leur organisation. Samman est une méthode concrète pour apporter des pratiques de développement efficaces dans les équipes et les organisations qui en ont besoin.

A propos de l'auteur

Emily Bache a plus de 20 ans d'expérience en tant que développeuse de logiciels et coach technique, ayant travaillé dans une variété d'organisations, des petites startups aux grandes entreprises. Elle est une auteure et une conférencière réputée sur des sujets liés aux tests automatisés et au coaching technique. Elle maintient un site web avec du matériel pour les coachs techniques.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT