Quel est le point commun entre le Clean Code, les Tests unitaires, les TDD (pour Test Driven Development), BDD (pour Behavior-Driven Development) et DDD (pour Domain-Driven Design) ? Le Software Craftsmanship, la méthode qui met l’accent sur les compétences des développeurs en matière de codage ! Attention, l’approche craftsmanship ne s’arrête pas simplement à délivrer les bonnes pratiques pour coder, elle pousse la démarche jusqu’à l’amélioration continue. Elle permet ainsi de remettre en question la façon de travailler des développeurs au quotidien, de les faire grandir. Elle amène les équipes à se poser les bonnes questions et évoluer de façon autonome, leur permettant de mieux maîtriser les contraintes techniques et de qualité du développement de logiciels. C’est une démarche qui requiert un savoir-être, et une certaine façon de travailler pour que la méthode fonctionne. Julien Vitte, coach Software Craftsmanship, nous dévoile les secrets et méthodes de coaching pour aider la diffusion des pratiques Crafstmanship dans les organisations.
Pourquoi le coaching est incontournable dans le domaine du développement informatique ?
Dans la plupart des métiers où il faut acquérir des compétences pratiques, l’apprentissage est incontournable. Ce qui implique un « apprenti » et un « maître de stage ». C’est vrai dans le domaine de l’artisanat, également dans celui du développement informatique. A une différence près : dans le monde de développement, nombreux sont ceux qui pensent que 2 jours de stage suffisent pour acquérir une nouvelle compétence. Pour autant la maîtrise d’un langage comme Java, par exemple, ne prends pas 2 ou 3 jours. Il faut du temps et de la pratique car c’est un domaine qui évolue vite et des nouveautés émergent sans cesse. Si les formations couvrent la base, elles ne peuvent pas aborder tous les cas possibles et imaginables : il faut donc un accompagnement pour compléter. Il ne faut garder à l’esprit qu’il y a une grande différence entre des cas pratiques appliqués dans des contextes réduits, comme en formation, et une pratique au quotidien sur du code de production.
Peux-tu nous donner ta vision du parcours de formation pour le Software Craftsmanship ?
Les pratiques du software craftsmanship reposent sur des outils. Il faut donc être en capacité d’utiliser les bons outils au bon moment, bien les connaître et savoir exactement à quoi ils correspondent, sans pour autant être dogmatique. Prenons l’exemple du TDD : c’est en fait un prétexte pour bien travailler en agilité. Dans cet atelier, il ne s’agit pas de développer l’aspect technique, qui consiste à faire du code en écrivant les tests en premier et en faisant des boucles de feedbacks rapides. Il s’agit de s’attacher à obtenir des critères d’acceptation correctes en challengeant le besoin. Ce qui va embarquer toute l’équipe autour d’une démarche de qualité, y compris le PO (Product Owner) car il est sollicité pour mieux formaliser le besoin initial, et les QA (Quality Assurance) car ils s’occupent le plus souvent des critères d’acceptation.
L’idée est donc de proposer des formations (avec 30% de théorie et 70% de pratique) qui permettent de montrer les outils et comment les utiliser, ce que les équipes vont gagner et les difficultés auxquelles elles seront confrontées. Dans ces formations nous essayons de poser un socle de compétences pour que les développeurs sachent à la fois pratiquer et se projeter dans leur contexte, avec des éléments qu’ils pourront appliquer directement en production et la possibilité de s’améliorer au quotidien.
Il faut noter qu’il n’existe pas une méthode qui fonctionne parfaitement avec tout le monde. Le contexte humain doit être pris en compte, certains intervenants se sentent plus à l’aise en commençant par se confronter directement à des cas réels. L’aspect mentoring ne doit donc pas être négligé.
Pour en savoir plus sur notre parcours de formation dédié au Software Craftsmanship !
Peux-tu nous parler justement du mentoring et du Craftsmanship ?
L’aspect mentoring a pour but de pousser les équipes à sortir de leur zone de confort, et à développer une démarche d’autonomie pour trouver par soi-même des solutions. L’aspect « communautaire » -avec notamment les communautés de pratique- est un volet incontournable de l’approche Crafts. Ces communautés permettent de « dé-siloter » le travail des équipes, de créer de la communication qui va amener les différents intervenants à s’enrichir les uns les autres. C’est un moyen, indirect, de mettre en œuvre une démarche d’amélioration des compétences des équipes de développeurs. Il prône l’échange et une certaine curiosité qui font partie des savoir-être « des crafts-Dev ». Cette démarche va faire émerger des solutions à partir des compétences transmises aux membres des équipes lors des phases de coaching. Il faut enfin noter que pour certains profils de développeurs, cette méthode fonctionne mieux que celle qui utilise des ateliers. Tout dépend des caractères.
Peux-tu nous parler de la méthode de formation TFBR ?
Elle est tirée du livre Training From the Back of the Room, et se déroule en quatre phases : Connections, Concepts, Concrete practice et Conclusions. Soit la méthode des « quatre C ». La première amène les participants à faire connaissance entre eux -car ils peuvent parfois venir d’équipes différentes- et du sujet qui sera abordé. Ils peuvent ainsi rapidement se projeter sur un cas réel. Les 2 phases suivantes alternes entre des présentations de concepts et le passage à des cas pratiques. Les alternances entre théorie et pratique n’excèdent pas 15 minutes. Cet ensemble d’exercices pratiques se clôture par la dernière phase de conclusion en récupérant du feedback sur ce que les participants ont retenu. De plus, nous favorisons la prise de notes collective dans ce type de formation (grâce à des boards en ligne), ce qui amène un bon niveau d’interaction. Je précise que j’ai découvert cette formation TBFR en m’intéressant à la méthode d’Emilie Bach nommée Samman Coaching.
J’ai cru comprendre que tu étais le premier Français à contribuer à la méthode de coaching Samman. En quoi consiste-t-elle ?
On trouve principalement 2 volets. Le premier est le learning hour qui consiste à faire de courtes sessions de formation au cours desquelles les participants mettent en pratique leurs compétences de programmation et apprennent de nouvelles techniques. Concrètement, nous essayons d’avoir une demi-journée complète avec les équipes, avec une heure d’apport de concepts et de pratique via des ateliers basés sur la structure « quatre C ». Le reste du temps disponible est réservé au second volet, c’est-à-dire l’Ensemble Working. Il consiste pour nous à travailler avec l’équipe sur son propre code en essayant d’incorporer ce qui vient d’être vu en atelier. Cela amène à se confronter directement aux difficultés réelles rencontrées par les équipes, et à glaner du feedback sur les prochains apports de connaissance qui seront nécessaires. Enfin, ce deuxième volet permet une montée en compétence du travail en équipe.
Côté formateur, il faut réussir à scinder des concepts qui prennent du temps à transmettre en formats de seulement une heure (qui s’enchaînent). Si nous reprenons l’exemple du TDD, le but n’est pas d’apprendre aux équipes à être autonome au bout d’une heure. Le but est d’acquérir des éléments pratiques à chaque session. Comme la façon d’envisager les tests qui devront être mis en place, et la complexité qui sera amenée dans le code.
Pour aider à la tenue ce type d’atelier, nous allons être les premiers Français avec mes collègues Yohann et Nicolas à mettre en ligne notre méthode de coaching sur le site sammancoaching.org
Vous souhaitez échanger avec nos experts autour de vos enjeux et de la diffusion des pratiques du Software Craftsmanship dans votre organisation, c’est par ici !
Dans ces formations nous essayons de poser un socle de compétences pour que les développeurs sachent à la fois pratiquer et se projeter dans leur contexte.