Le jeudi 29 août a eu lieu le premier Coding Dojo de l’agence Nantaise d’Ippon Technologies.

Notre retour à été décomposé en deux parties :

1. Présentation et feedback organisationnel
2. Feedback technique et bilan

Qu’est-ce qu’un Coding Dojo ?

Le Coding Dojo “traditionnel”

Le Coding Dojo est une pratique déjà existante dans le milieu du développement, elle possède :

• Un déroulement précis : l’exposé du défi (technique ou fonctionnel), le Kata phase pour montrer une résolution possible et le Randori phase avec plusieurs tentatives de résolution du même défi (en général en binôme) pour voir les autres alternatives de solutions possibles.
• Un objectif : apprendre et partager ses connaissances techniques entres pairs.

Le Coding Dojo “made in Ippon”

Ippon a voulu se réapproprier / expérimenter cette pratique en modifiant quelque peu son déroulement pour parfaire d’autres objectifs :

• Se former aux dernières technologies (Open Source).
• Travailler avec son équipe Ippon (les équipes Ippon sont constituées de 10 à 12 personnes, sous la direction d’un Manager Technique), et ainsi mieux apprendre à se connaître.

Cet article a pour but de vous décrire cette variante du Coding Dojo avec un retour d’expérience sur les points forts et les points faibles constatés.

Déroulement de la variante “made in Ippon”

Les défis fonctionnels

Du fait de réaliser le Coding Dojo sur une journée, il n’y a pas un mais plusieurs défis.

Qui plus est, ceux-ci porteront forcément sur un besoin fonctionnel, chaque besoin étant censé apporter de “la valeur” métier.

Les défis avaient une thématique globale, thématique empruntée à Nicolas De Loof pour refondre le site du Breizhjug sous forme de concours : http://blog.loof.fr/2013/07/breizhjug-coding-challenge.html 

Le but étant de créer un site pour le JUG de Rennes présentant les fonctionnalités suivantes :

• Informations
• Présentation des événements
• Présentation des membres
• Inscription aux événements

Son idée s’est orientée vers un site statique (avec générateur basé sur Jekill). Choix probablement raisonnable étant donné son besoin mais malheureusement pas assez sexy pour notre Coding Dojo. De plus il n’aurait pas été juste de participer collectivement à un challenge plutôt destiné aux individus.

Les défis vont simplement conserver ses besoins fonctionnels et s’éloigner de l’implémentation technique préconisée.

Voici les défis … bon appelons ça les User Stories 😉

Cette approche peut laisser penser que cela dénature totalement la phase Randori ou les binômes sont censés montrer des alternatives de solutions.

En fait cela a été déporté sur la “stack” technique.

Le Kata et la “stack” technique

Un des objectifs étant de monter en compétence sur les technologies montantes du moment, une “stack” technique full Web (pour ne pas dire JavaScript), au menu : AngularJS, Bootstrap, Compass, Node.js, Yeoman (Grunt/Bower) et MongoDB.

Le Randori consistant alors à réaliser un CRUD, du front jusqu’à la persistance afin de montrer sa solution et les astuces de développement par la même occasion.

Le Kata a donc été une présentation “rapide” (1h tout de même) en live coding des différentes technologies utilisées sur un CRUD existant, tout en essayant de procéder par baby-step :

• Présentation des possibilités front end (AngularJS / Bootstrap / Compass) avec des données en dur.
• Présentation des appels services pour le front (AngularJS) avec des mocks (fichiers JSON pré-existants).
• Présentation de la couche de persistance (NodeJS / MongoDB).

Le Randori

Les participants sont scindés en quatre binômes codant sur 3 sprints d’environ deux heures.

Chaque sprint devant :

• Servir à effectuer une démonstration (montrer des fonctionnalités ayant de “la valeur”)
• Moment de coordination et de partage
• Changement de binôme pour une meilleure diffusion des connaissances

Une personne reste en soutien permanent pour les questions / support et pour synchroniser les binômes.

Plateforme collaborative

Les User Stories ont été saisies dans Azendoo (http://app.azendoo.com) sous la forme de tâches.

Les binômes s’abonnent aux tâches qui leur sont attribuées afin de suivre les évolutions, et de saisir l’avancement (chaque User Storie étant décomposée en sous tâches).

L’utilisation d’Azendoo permettant de suivre l’avancement de l’implémentation et d’éviter l’effet tunnel avant les démos.

Retour d’expérience

Après une journée intense et le retour de tous les participants voici notre SaMoLo (Same as / More of / Less of).

Same as : les points à garder

Coder en binôme

C’est de loin le meilleur cas de figure pour apprendre, cela permet un échange direct des connaissances et c’est également un excellent moyen pour se stimuler. Si vous êtes en nombre impair, faites un groupe de 3 afin que personne ne se retrouve tout seul.

Fournir une machine virtuelle complète

Ceci afin d’éviter de perdre du temps à mettre en place l’environnement. Nous en avions préparé une mais ce ne fut pas nécessaire car nombre de personnes avaient téléchargé le nécessaire avant. Toutefois cela reste une bonne pratique.

Découpage en 3 Sprints

Nous avions opté pour un planning avec trois démonstrations. Bien évidemment la première nous a permis de remonter les points bloquants pour une démonstration et ainsi corriger le tir pour les suivantes. Cette approche permet des synchronisations plus rapprochées et moins de dérive, ce qui nous a permis d’avoir un résultat cohérent lors de la dernière démonstration.

Le Kata, la présentation en live coding

Ne surtout pas négliger cette phase et préférer une présentation live plutôt qu’un document à lire, c’est beaucoup plus vivant comme démarche d’apprentissage.

De plus cela permet d’avoir un exemple tangible de ce qu’il faut faire, à la fin de la présentation les participants ont beaucoup moins d’hésitations sur le contexte technique et fonctionnel du projet, ils ont le minimum requis pour commencer à coder.

More of : les points à améliorer

Alternance des binômes non réalisées

Les binômes sont restés identiques toute la journée. Faire évoluer la composition des équipes aurait permis d’accentuer les échanges et la diffusion des connaissances. Malheureusement, dans notre cas les user stories n’avaient pas une granularité assez fine pour permettre facilement ces échanges, il faudra revoir ce découpage.

Trop de nouvelles technologies à assimiler

La “stack” technique était intéressante mais elle était un peu trop conséquente pour tout digérer en une journée. Il faudrait soit partir sur une stack moins ambitieuse, soit découper en 2 stacks par exemple, avec des binômes spécialisés dans le front et d’autres dans le back.

Le rôle du soutien

La personne au soutien était présente pour répondre aussi bien aux questions techniques bloquantes qu’à la synchronisation des avancées, ce poste était un goulot d’étranglement. Privilégier 2 soutiens, un uniquement technique et un autre à la synchronisation.

Des niveaux hétérogènes

Les binômes s’étant constitués sur des critères fonctionnels, les niveaux techniques pouvaient être disparates, il faut savoir identifier les “sachants” avant de constituer les binômes pour ainsi les équilibrer.

Less of : les points à enlever

Dépendances entre les user stories

Notre dépendance dans les users stories (à cause des données) nous a rajouté une complexité supplémentaire pour la réalisation. Cette complexité aurait pu être justifiée si le but avait été l’apprentissage du travail d’équipe mais ce n’était pas le cas.

Outil collaboratif

L’outil collabaratif Azendoo n’a pratiquement pas été utilisé. Pas à cause de la qualité de l’outil mais parce que ce genre d’outil n’est pas adapté à un Coding Dojo ou en tout cas à des personnes ne l’utilisant pas habituellement. Ce genre d’outil n’est donc pas recommandé lors d’un Coding Dojo.

Conclusion

Tout n’a pas été parfait dans cette variante du Coding Dojo, il existe de nombreux axes d’amélioration. Néanmoins tous les participants ont apprécié ce cadre d’apprentissage qui s’est déroulé dans une bonne ambiance. Cela a même aiguisé l’appétit de certains sur des technologies sur lesquelles ils ne se seraient pas aventurés spontanément.

La journée en images

A suivre sur le blog le retour d’expérience technique de cette journée …