Coding Dojo in the Alps - Retour d'expérience

Coding Dojo : un retour d’expérience Emmanuel Hugonnet Architecture J2EE [email_address] +33-(0)476248658 Rémy Sanlaville Expert Senior en Ingénierie Logicielle [email_address] Avec l'aide des membres du Coding Dojo de Grenoble

Historique Si je veux apprendre le Judo, je vais m'inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j'aurai peut-être envie de pratiquer plus assidument. Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004. Cherchez l'erreur. -- Laurent Bossavit

Objectifs

Espace sûr

Pas de compétition

Collaboration

Tout le monde participe

Apprentissage continu/régulier

Apprentissage par petits pas

L’erreur est humaine

Chacun doit pouvoir s'améliorer à son rythme Le but n'est pas de terminer l'exercice mais bien d'apprendre

Randori co-pilote pilote On tourne (5 – 7 mn) Binôme Participants from Dojo@SP (São Paulo)

Kata from Dojo@SP (São Paulo) co-pilote pilote Binôme Participants

Retour d'expérience Tests et Expérimentations Questions Ouvertes Difficultés rencontrées Chartes Organisation Logistique Déroulement

Logistique (matériel)

Logistique (logiciel) Outils de développement Communication Site web du Cara Liste de diffusion cara-dojo scrumy dojocara IDE : Eclipse, Netbeans, Visual Studio… Build : maven 2… Langage : Java, Ruby, .NET… SCM : Mercurial… …

Déroulement Annonce : lieu, date, objectif(s), doodle pour l'inscription… discussion(s) sur la liste de diffusion 11h45-12h00 arrivée, préparation salle… Avant Pendant Après [Idéalement] CR sur le site web du CARA discussion(s) sur la liste de diffusion Séance tous les 15 jours entre 12h00 et 14h00 12h00-12h10 introduction, rappel de l'objectif 12h10-13h30 kata, randori… 13h30-14h00 rétrospective

Charte Coding Dojo Randori Objectifs Implanter une solution de façon collaborative pour un défi Le but est d'apprendre et d'avancer ensemble Acteurs

Le facilitateur (animateur) s'assure du bon déroulement de la séance :

veille au bon équilibre entre discussion et développement ;

a le souci de l'atteinte de l'objectif défini au début du dojo ;

il doit permettre l'émergence de consensus sans pour autant influencer les choix.

Les participants collaborent à la séance en suivant ce qui est fait, en proposant des questions/améliorations et en faisant partie du binôme de développement. Le binôme de développement est composé d'un pilote qui a le clavier et d'un co-pilote qui implantent une solution pour le défi en respectant la démarche TDD ( Test-Driven Development ). Le secrétaire prend des notes lors de la séance. Il n'intervient pas pendant la phase de développement.

Charte Coding Dojo Randori Règles Restructuration du code Le test est au rouge Le test est au vert

Le binôme de développement à la main :

Si le test ne passe pas, le pilote doit expliquer aux participants la raison de l'échec ;

Les participants n'interviennent que si le binôme le demande.

Toute restructuration doit être discuté et avoir l'accord de la majorité des participants Les participants peuvent intervenir pour proposer des améliorations, faire des remarques, poser des questions… L'animateur peut souligner de bonnes ou de mauvaises pratiques

Charte Coding Dojo Kata Objectifs Présentation d'une solution pour un défi Le but n'est pas de trouver la meilleure solution mais de comprendre la solution proposée par l'animateur. Un présentateur (un seul programmeur ou un binôme) présente sa solution du défi. Le défi est réalisé en entier en TDD ( Test-Driven Development ). Il explique continuellement son cheminement et il affiche sa progression en déroulant continuellement les tests. L'assistance doit comprendre en tout temps la présentation. Un participant peut interrompre le présentateur dans le seul cas où il ne comprend plus le déroulement de la solution. Le facilitateur (animateur) s'assure du bon déroulement de la séance. Il veille à ce que personne ne soit perdu. Le secrétaire prend des notes lors de la séance. Il n'intervient pas pendant la phase de développement. Acteurs

Charte Coding Dojo Kata Règles Restructuration du code Le test est au rouge Le test est au vert Si le test ne passe pas, le présentateur doit expliquer aux participants la raison de l'échec. Toute restructuration doit être expliqué La salle peut interrompre le présentateur dans le seul cas où il ne comprend plus le déroulement de la solution.… Le présentateur peut souligner de bonnes ou de mauvaises pratiques

Difficultés rencontrées Organisation Cela prend du temps ! préparation des séances résoudre les difficultés (logistique…) animer un groupe (liste de diffusion, site web…) Logistique Salle équipée et facile d'accès vidéo projecteur, tableau blanc, tables et chaises, prises électriques… taille, bonne luminosité…

Difficultés rencontrées Séance Ne pas oublier l'objectif premier qui est d'apprendre ! souvent envie de terminer l'exercice, bon équilibre entre développement et échanges… Etre un bon facilitateur (animateur) élément important pour le bon déroulement de la séance 2 heures c'est très court ! souhait de plus coder, de faire participer tout le monde… Travail collaboratif faire des choix dans un temps restreint, réflexions communes (autour d'un tableau) Compte-rendu long, pas très motivant…

Tests et Expérimentations Format de la session Kata 25/03/2009, 08/04/2009 Randori 01/14/2009, 28/01/2009, 11/02/2009, 25/02/2009,11/03/2009 Pas de codage mais discussions autour d'un thème. Possibilité de le faire autour d'un verre… Plusieurs sessions en parallèles et les personnes peuvent changer de groupe quand ils veulent Barcamp Open-space Randori-Veille 20/05/2009 Kata-TD Une personne présente et les participants (par binôme) refont ce qui a été fait au fur et à mesure Kata-Veille 06/05/2009 Randori-TD Faire le tour d'un sujet où une personne présente la problématique, les solutions et outils existants Tester différents outils en parallèle pour un même défi et faire une restitution pour confronter les résultats Développement en binôme/n-uplet en parallèle avec les mêmes outils et pour un même défi

Tests et Expérimentations Kata-Veille du 06/05/2009

Tests et Expérimentations Randori-Veille 20/05/2009 Jeu du pendu : iteration 1 (au plus simple) Pas de taille maximum et minimum (>= 1) ; pas de gestion d'accents, pas de caractères spéciaux, pasde chiffre, pas case-sensitive, pas de nom-composé. Lettre accepté = [a..z] et [A..Z] Dans un premier temps le mot secret est fixé. On prend le mot SANGLIER pour ne pas gérer les doublons Given le mot secret SANGLIER et CR=6 When le joueur tape le caractère A Then afficher le résultat CR=6 Given le mot secret SANGLIER et la lettre A trouvée et CR=5 When le joueur tape le caractère S Then afficher le résultat SA****** Given le mot secret SANGLIER et la lettre A trouvée et CR=5 When le joueur tape le caractère S Then afficher le résultat CR=5 Given le mot secret SANGLIER et CR=6 When le joueur tape le caractère Z Then afficher le résultat ******** Given le mot secret SANGLIER et CR=6 When le joueur tape le caractère Z Then afficher le résultat CR=5 Given le mot secret SANGLIER et CR=6 When le joueur tape le caractère A Then afficher le résultat *A******

Tests et Expérimentations Randori-Veille 20/05/2009 .Net/NBehave Java/JUnit Ruby/Cucumber Java/JUnit

Questions Ouvertes

Remerciements