BT

Êtes-vous prêts pour InfoQ 3.0? Testez le nouveau design et dites-nous ce que vous en pensez!

Des Lego pour Apprendre les Pratiques Techniques

| par Stéphane Wojewoda Suivre 15 Abonnés , traduit par Stéphane Wojewoda Suivre 15 Abonnés le 06 juin 2016. Durée de lecture estimée: 4 minutes |

Expliquer les techniques de craft est compliqué, surtout au plus haut niveau de hiérarchie. La compréhension étant une des clés pour changer l'état d'esprit, et les pratiques techniques un pré requis pour créer du code de qualité, il est important de les expliquer. Mike Bowler a facilité un atelier à  l'Agile Games Conference 2016, montrant l'usage des Lego pour expliquer les pratiques techniques.

L'Agile Games Conference 2016 a eu lieu à Cambridge, MA, des 28 au 30 avril. Ce papier reprend les pratiques présentées par Mike. Il a également accepté de répondre à quelques questions sur l'usage des Lego pour expliquer les pratiques techniques, le type de feedback possible avec ce type d'atelier et la manière dont cela aide les organisations.

L'atelier de Mike Bowler est le même que celui de Bryan Beecham. Ils le font d'habitude ensemble. L'atelier est plutôt simple à mener si vous comprenez les pratiques, bon marché (il vous faut des Lego), et très efficace : vous pouvez passer les pratiques principales en moins d'une heure. Les principales pratiques expliquées sont :

  • Le TDD
  • Le Pair Programming
  • Le Refactoring
  • La dette technique
  • L'Integration continue

L'atelier n'est pas Lego Serious Play (R)[LSP]. Vous pouvez trouver les instructions sur le site de Mike (la partie TDD devrait bientôt être en ligne).

L'atelier se déroule de la manière suivante :

  • Un peu d'échauffement avec la construction d'une maison et d'une personne : c'est un point structurant dans une démarche LSP pour favoriser la sécurité et l'engagement.
  • La première question venant après cela est le coût de la maison ou du personnage : combien de briques avez-vous ? Combien vous en faut-il vraiment ? Ces questions touchent la pensée Lean et le principe du "juste assez".
  • Mike introduit les TDD et Pair Programming : par deux, l'un écrit un test tandis que l'autre construit pour faire passer les tests.
  • La phase d'après touche au refactoring : tous les tests sont jetés, et sont relancés, en refactorant au fil de l'eau.
  • La partie Dette Technique est sans doute la plus drôle : Mike jette des tests les uns après les autres, et il faut construire pour les faire passer, sans enlever aucune des briques utilisées. Le résultat est... pas terrible. Pour comprendre la différence, Mike refait la même chose (en mélangeant les tests), en enlevant la contrainte. L'image du dessous montre la différence entre avec et sans dette technique.
  • La partie sur l'Intégration Continue est possible avec au moins trois équipes (et beaucoup de Lego) : chaque équipe doit construire quelque chose qui accueille le travail de l'équipe précédente. Evidemment, le premier résultat est peu en phase, et mieux le suivant.

InfoQ : Mike, merci pour cet atelier. Pourquoi utilisez-vous des Lego pour expliquer les pratiques techniques ?

L'idée de base était d'enseigner les concepts de ces techniques à des personnes non techniques, ce qui signifie qu'utiliser du code était impossible. Il fallait une sorte d'abstraction non technique pour illustrer les concepts. Bryan Beecham avait construit un exercice de TDD avec des LEGO et cela marchait si bien que nous avons prolongé l'usage de ce format avec d'autres exercices. Le ludique de tout le monde ressort avec des LEGO, ce qui rend les gens plus prompt à apprendre et essayer.

InfoQ : Qui est votre cible avec un tel atelier ? Tout le monde peut-il participer ?

Nous utilisons ces exercices de plusieurs manières. En parlant à des responsables, nous nous concentrons sur les LEGO et les concepts. En formant des développeurs, nous mélangeons les exercices LEGO avec de vrais exercices de code. Nous introduisons d'abord un concept en LEGO, puis nous plongeons dans le code pour consolider la leçon.

InfoQ : En voyant le résultat après l'activité de refactoring, je reste sous le choc. Quel type de feedback avez-vous à la fin de tels ateliers ?

La première chose que nous entendons est le plaisir que les participants ont pris. Puis viennent les concepts et les leçons qu'ils ont retenus. Pratiquement tout le monde ressort avec au moins une chose - un élément appris qu'ils pourront appliquer dans leur travail.

InfoQ : Cet atelier paraît simple d'utilisation. Comment cela permet-il d'aider les équipes et organisations sur du long terme ?

Le sujet ici est d'aider à la compréhension des concepts. Pour aider les équipes sur le long terme, elles doivent appliquer les concepts à leur travail.

Nous encourageons les participants à prendre des photos de leurs constructions, d'abord parce que cela enrichit l'expérience de le montrer à ses amis, et aussi parce que cela sert de rappel pour les leçons. Un élément pour renforcer le concept.

InfoQ : Il est des organisations qui refusent les "jeux". Dans ces cas, auriez-vous des idées pour les convaincre ?

Je ne parle pas de jouer. J'explique la manière de transmettre des concepts et le fait d'y arriver avec des jeux n'est pas significatif. Même dans les organisations les plus sérieuses, personne ne m'a jamais dit d'enlever les briques de LEGO une fois que je les avais sorties.

Evaluer cet article

Pertinence
Style

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

Donnez-nous votre avis

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

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

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

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

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

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter
BT