13Fév
Le « Learning Hour » : pour des équipes de développement qui s’améliorent en continu
J’ai toujours trouvé qu’il était important de partager nos connaissances, de s’appuyer sur le travail publié par nos prédécesseurs et d’établir des bases communes afin d’être efficace et de nous améliorer en tant qu’équipe. C’est pourquoi à un moment de ma carrière j’ai eu l’idée d’implanter des sessions d’apprentissage s’inspirant des problèmes vécus par les développeurs au quotidien. Le but était non seulement d’améliorer la qualité du code produit, mais aussi la qualité de vie des membres de l’équipe. Car on va se le dire, travailler sur du code mal structuré, ce n’est jamais hyper motivant. À ce moment, comme j’étais aussi développeur dans l’équipe, j’avais non seulement l’occasion de vivre moi aussi ces douleurs, mais aussi la chance d’inspirer le changement et de consolider les apprentissages faits lors de ces sessions dans nos projets de tous les jours. J’étais loin de me douter que ces sessions d’apprentissage avaient un nom : les Learning Hour.
C’est lorsque j’ai rencontré Emily Bache dans une formation où elle présentait la méthode Samman que j’ai eu une impression de déjà vu. Sa façon de travailler avec les équipes de développement ressemblait étrangement à ce que je faisais intuitivement: une heure d’activité dirigée suivi d’une immersion dans le quotidien de l’équipe.
C’est quoi un Learning Hour?
Selon le livre Technical Agile Coaching with the Samman method d’Emily Bache, les Learning Hour sont de courtes sessions de formation au cours desquelles les participants mettent en pratique leurs compétences de programmation et apprennent de nouvelles techniques. Pendant le Learning Hour, le coach utilise des exercices et des techniques d’apprentissage dynamiques pour enseigner la théorie et la pratique de nouvelles compétences telles que le test-driven development (TDD), le refactoring et l’identification de code smells.
Idéalement, on combine le Learning Hour avec l’ensemble working (ex. : mob programming) dans des sessions où toute l’équipe collabore avec le coach pour appliquer les mêmes techniques et compétences dans leur codebase de tous les jours.
Pourquoi faire un Learning Hour?
L’objectif ultime est d’améliorer la façon dont les logiciels sont conçus! Mais selon Emily Bache, les avantages sont multiples :
- Si vous apprenez de nouvelles compétences et devenez meilleur dans votre travail, vous deviendrez plus productif et plus heureux.
- Les petits gains de productivité non seulement s’additionnent, mais se manifestent rapidement et compensent amplement le temps que vous consacrez aux sessions d’apprentissage.
- Les bonnes pratiques techniques permettent à l’organisation de créer de nouvelles fonctionnalités dans des délais plus courts et avec une meilleure qualité.
- La collaboration et la communication entre les membres de l’équipe est améliorée et l’environnement beaucoup plus sécuritaire psychologiquement.
De plus, un point important de la gestion du changement est d’y aller une étape à la fois, par petits incréments répétés constamment, en démontrant les bénéfices des nouvelles pratiques mises en place.
Les gens ne vont pas commencer à travailler différemment du jour au lendemain, mais on peut montrer des méthodologies, présenter les avantages et les situations dans lesquelles ça s’applique pour semer des graines dans la tête des développeurs.
C’est un travail de longue haleine : il faut répéter régulièrement le même discours et la même vision pour tendre vers le changement. Pour moi, le meilleur véhicule pour y arriver est le Learning Hour, puisqu’il me permet d’amener un flot continu d’apprentissages qui nous amènent vers des cycles de développement beaucoup plus courts. Et il y a tellement de trucs à apprendre et à maîtriser que de dédier une heure à la formation, c’est assurément rentable!
Plusieurs chemins, plusieurs façons d’apprendre
Le plan général est de revoir les principes fondamentaux (ex. : smells, refactoring, tests, bases de l’infra) et d’évoluer vers des techniques plus avancées qui vont nous permettre d’avoir un cycle de développement plus court. Par exemple, le TDD, le continuous deployment, un meilleur découpage du travail à exécuter, l’ architecture évolutive et le «shift left», sont tous des techniques et principes qui vont aider vous aider à livrer de la qualité rapidement et à garder cette vitesse de croisière avec le temps, malgré la complexité.
Bien que le plan général soit bien établi, je laisse place à la flexibilité pour répondre à des enjeux prioritaires dans les équipes, tout en insérant des notions de TDD, de refactoring et de reconnaissance de smells dans les sujets qui me sont demandés.
Déjà après quelques itérations de l’initiative, j’observe des retombées positives dans l’équipe. Plusieurs développeurs m’ont partagé avoir mis en pratique des apprentissages du Learning Hour dans leur projet. D’autres en sont simplement venus à comprendre leurs erreurs commises par le passé ou encore les «douleurs» qu’ils ressentaient dans leur quotidien, tout simplement en faisant un lien avec les bonnes pratiques proposées par le Learning Hour.
C’est normal de continuer à faire des erreurs : le but du Learning Hour n’est pas de devenir parfait et rigide. Il s’agit d’exposer les développeurs aux problèmes qu’ils pourraient vivre, leur offrir des bases auxquelles se rattacher afin de comprendre pourquoi ils devraient travailler différemment, puis les laisser expérimenter et faire des erreurs. L’objectif est de partager des solutions pour éviter de faire la même erreur deux fois et de stimuler leur sens critique. En ce sens, le Learning Hour sème donc déjà des graines vers l’amélioration continue.
Quel avenir pour le Learning Hour?
Dans un premier temps, je souhaite amener les développeurs à réfléchir plus régulièrement à ce qu’ils font : pourquoi ils le font? Qu’est-ce qu’ils veulent réellement accomplir? Quels sont les paramètres à définir? Une des techniques que je préconise pour nous inciter à faire ce questionnement en continu est le TDD! Identifier le prochain petit incrément à livrer, écrire un test pour notre hypothèse, réaliser l’implémentation la plus simple, s’arrêter et améliorer le tout … Puis recommencer le cycle. Ça nous oblige à ralentir pour réfléchir et se réaligner constamment.
En révisant les bases (ex. : code smells, refactoring, design patterns, écriture de tests), mon objectif est d’ouvrir la discussion autour des pratiques et de commencer à assembler les pièces du casse-tête vers un TDD efficace. Je m’attends à passer encore plusieurs Learning Hour sur ces sujets, parce que pour reconnaître et corriger les smells, il faut en voir beaucoup, lire du code et en discuter entre développeurs.
Un des prochains sujets qui sera abordé pendant les Learning Hour se situera moins dans les techniques de travail du développeur et davantage dans la synergie avec le volet business, les designers et l’assurance qualité : comment favoriser la collaboration en continue au lieu de travailler en silo!
Et vous, connaissiez-vous les Learning Hour? Avez-vous mis en place des pratiques similaires dans vos équipes? Je suis curieux de vous entendre sur le sujet!
Autres billets
Contribuez au blogue
Publicité