lundi 8 mars 2010

Intégrer un nouveau membre dans une équipe projet

On m'a récemment demandé si j'avais des suggestions ou des idées sur l'intégration d'un nouveau membre dans une équipe projet.

J'ai évidemment directement suggérer de faire du Pair programming. Le pair programming est une des pratiques de eXtreme Programming

Les bénéfices du pair programming ne sont plus à démontrer mais cette pratique est particulièrement intéressante dans le cadre de l'intégration d'un nouvel arrivant dans une équipe :
  • L'intégration se fait par l'exemple mais dans des conditions réelles.
  • Le nouveau membre a tout de suite une vision de comment faire concrètement.
  • Le risque de "laisser" le nouveau travailler seul n'existe plus. (Principe du "je ferme les yeux, ça va passer, ça va passer...")
  • Pour le membre de la paire qui fait déjà parti du projet, il va devoir reprendre du recul par rapport à ce qu'il fait pour pouvoir répondre aux questions. Prendre du recul, c'est toujours favorable.
  • Le nouveau membre se sentira membre de l'équipe beaucoup plus rapidement.
  • Le nouveau membre sera "opérationnel" beaucoup plus rapidement.
  • Cela permet de ne pas se retrouver avec le nouveau membre, le jour de son arrivée, assis à un bureau sans rien faire sans login mot de passe et sans poste de travail... (si si, je vous vois sourire, ça arrive tout le temps, il doit d'ailleurs y avoir une "loi" derrière tout ça, c'est à creuser :-)).
Le principal argument qu'on peut entendre en général pour ne pas faire du pair programming : 
"Ça va me couter du temps et donc de l'argent car ça va monopoliser un membre de l'équipe."

La réponse à cela est "c'est pas faux" pour ne pas dire "c'est pas vrai" :-) :
  • L'intégration d'un nouveau membre dans une équipe à un coût. Il faut l'accepter. Cela n'a rien à voir avec le fait de faire du pair programming.
  • Ce coût est beaucoup moins facile à quantifier quand on laisse le nouveau membre se débrouiller car il est dilué (qualité moyenne des premières réalisations, temps de "parasitage" du nouveau membre envers l'équipe lorsqu'il aura besoin de savoir quelque chose, temps passé à corriger les anomalies découvertes des premières réalisations, ...)
  • Le membre de l'équipe qui va travailler en pair programming avec le nouveau n'arrête pas de développer, il va juste développer un peu moins vite (mais à contrario c'est directement quantifiable :-)).
  • Faire du pair programming, ne veut pas dire de faire que du pair programming. Il peut être intéressant d'alterner pendant la durée d'intégration les phases de travail en paire et les phases en autonomie. Cela peut permettre au nouveau membre de monter sa plateforme de développement, de "digérer" la phase de travail en paire, de lire des documentations, de trouver une date pour payer son coup...
Pair programming se dit en français programmation en binôme.

lundi 1 mars 2010

Coding Dojo en entreprise

x
x
x
J'organise avec Thomas, Guillaume et Jay (amis, collègues et membres de la direction technique de Norsys) des Coding Dojos en interne. J'ai réalisé avec Guillaume un document descriptif / retour d'expérience sur l'organisation de ce type d'évènement. En voici une adaptation :

Un Coding Dojo, Qu'est-ce que c'est ?
Un Coding Dojo est une réunion où un ensemble de personnes se retrouvent pour travailler sur un défi de programmation de façon collective. Un défi de programmation est un problème à résoudre ou un besoin à implémenter.
Chaque coding DOJO se porte sur un sujet particulier qui est décliné en un exercice à réaliser. Il représente le challenge de programmation du DOJO.
Un Coding Dojo permet de mettre en œuvre différentes techniques de programmation notamment lié à l'extrême proggramming :
  • Pair Programming.
  • TDD.
On pourrait assimiler un Coding Dojo à un Coding party. Ce n'est pas le cas. L'objectif n'est pas de réussir à résoudre le défi de programmation mais plutôt de d'apprendre de façon collective sur la manière d'y arriver.

Un Coding Dojo, Pourquoi faire?
"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, président de l'association XP-France (Extreme Programming).

Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d'entraînement pour parfaire leurs techniques. Le principe d'un Coding  dojo est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d'un projet.
Les personnes qui participent à ce type de réunion doivent le faire par envie et pour améliorer leurs compétences en programmation.

Les principales motivations qui doivent pousser les personnes à participer à un Coding Dojo sont :
  • l'envie d'apprendre.
  • l'envie de partager.
  • l'amélioration continue.

Les caractérisitiques d'un Coding Dojo
Le coding DOJO doit être "un lieu sûr " :
  • Tous les niveaux de compétences en programmation sont acceptés.
  • Seule une personne volontaire peut participer à un Coding Dojo.
  • Ce n'est pas une compétition.
  • L'erreur est humaine.
  • Il n'y a pas de jugement.
  • Le Coding Dojo doit être un moment convivial.
  • Tout le monde doit participer.
Voici un ensemble de points qui caractérisent un Coding Dojo :
  • Chacun doit pouvoir s'améliorer à son rythme.
  • Le but n'est pas de terminer l'exercice mais bien d'apprendre.
  • Il permet un apprentissage continu/régulier.
  • Il permet un apprentissage par petits pas.
Il existe 2 types de Dojos :
  • le kata.
  • le randori. 
Qu'est-ce qu'un Kata?
PRINCIPE :
Le kata est une des formes de Coding Dojo. C'est une démonstration en live de la réalisation d'un défi de programmation en partant de zéro.

image provenant de Dojo@SP (São Paulo)



Un présentateur (un seul programmeur ou un binôme) présente sa solution du défi. Il explique continuellement son cheminement et il affiche sa progression en déroulant continuellement les tests. Le défi est réalisé en entier en TDD (Test-Driven Development). L'interactivité avec le reste du groupe est primordiale.

Le but n'est pas de trouver la meilleure solution mais de comprendre la solution proposée par le présentateur.

CHARTE :
La pratique du TDD appliquée au Kata pour le présentateur (ou binôme) est la suivante :
  • Rédaction d'un test.
  • Le test est au rouge (en echec). Si le test ne passe pas, le présentateur doit expliquer aux participants la raison de l'échec. il doit mettre en œuvre le code permettant de réussir le test. 
  • Le test est au vert (réussite). Le présentateur peut souligner de bonnes ou de mauvaises pratiques. La salle peut interrompre le présentateur dans le seul cas où il ne comprend plus le déroulement de la solution.…
  • Refactoring du code.
Toute restructuration doit être expliquée
et ainsi de suite…

Qu'est ce qu'un Randori
PRINCIPE :
Le randori est l'autre forme de Coding Dojo. L'objectif est d'implémenter une solution de façon collaborative pour un défi. Le principe de base est que tout le monde effectue les rôles de pilote et co-pilote pendant la session.
 image provenant de Dojo@SP (São Paulo)

Le binôme de développement est composé d'un pilote qui a le clavier et d'un co-pilote qui implémentent une solution pour le défi en respectant la démarche TDD (Test-Driven Development). Le binôme est changé toutes les 5 à 7minutes par une rotation :
  • le pilote retourne parmi le reste du groupe.
  • le co-pilote devient pilote.
  • une personne du groupe devient co-pilote. 
CHARTE :
La pratique du TDD appliquée au randori pour chaque binôme (durée 5 à 7 minutes) est la suivante :
  • Rédaction d'un test.
  • Le test est au rouge (en echec). 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. Le binôme doit mettre en œuvre le code permettant de réussir le test.
  • Le test est au vert (réussite). Les participants peuvent intervenir pour proposer des améliorations, faire des remarques, poser des questions…
  • Refactoring du code.
Toute restructuration doit être discutéé et avoir l'accord de la majorité des participants.
et ainsi de suite…

Du coté de l'organisation...
QUI PEUT PARTICIPER?
Toutes les personnes qui adhèrent aux principes d'un Coding Dojo.

QUI PEUT ORGANISER?
Toutes les personnes qui adhèrent aux principes d'un Coding Dojo qui ont envie d'organiser ce type d'évènement.

LES CONTRAINTES D'ORGANISATION :
Pour organiser un Coding Dojo, il faut :
  • Un lieu.
  • Une date.
  • Une durée fixe est définie avant le Coding Dojo.
  • Un sujet + langage de programmation.
  • Un mode de fonctionnement kata ou randori.

LA LOGISITIQUE À PRÉVOIR:
D'un point de vue logistique il faut :
  • Que les participants possèdent une adresse mail pour les communications qui précédent et suivent une session.
  • Une salle.
  • Une table (au moins).
  • Des chaises pour l'ensemble des participants
  • Un video projecteur.
  • Un ordinateur portable.
  • Un paper board ou white board.
  • Des post-its.
  • Des stylos.
  • Un appareil photo (optionnel)
  • Une Caméra (optionnelle)
Exemple : Un Dojo à Norsys
AVANT :
Il faut :
  • Choisir une date.
  • Choisir le lieu.
  • Choisir le sujet (soit par un vote public, soit par un choix au niveau des organisateurs).
  • Réserver les éléments logistiques nécéssaires (video projecteur, salle, …).
  • Préparer un système d'inscription en ligne et de choix de sandwich(doodle ou formulaire google docs).
  • Envoyer l'annonce du Dojo (date, lieu, contenu, lien vers le système d'inscription.
  • Solliciter les personnes qui doivent préparer des choses pour la session pour s'assurer qu'il n'y ai pas de malentendu.
JUSTE AVANT :
  • Envoyer un mail de rappel aux inscrits avec le choix de leur sandwich.
  • Gérer la commande de sandwich.
  • S'assurer que les éléments logistiques réservés sont bien disponibles.
PENDANT :
  • 12h00-12h30 :  arrivée progressive des participants. Préparation de dernière minutes. Distribution des sandwichs et récupération de l'argent.
  • 12h30-13h30 : Coding Dojo.
  • 13h30-14h00 : Discussion autour du Dojo. Rangement . Départ progressif des participants.
APRÈS :
  • Mettre à disposition le code de la session.

Difficultés
Un coding Dojo réprésente malgré tout un défi d'organisation :
  • Cela prend du temps.
  • Il faut résoudre les difficultés logistiques en amont d'une séance.
  • Il faut se mettre d'accord sur un sujet et ça n'est pas toujours évident.
  • Durant la séance : Ne pas oublier que l'ojectif premier est d'apprendre et non pas de terminer l'excercice. Il faut trouver un bon equilibre entre le développement l'échange.
  • 1 heure, c'est très court. Le souhait de de développer le plus possible et de faire participer tout le monde.
  • Travail collaboratif. Il faut faire des choix dans un temps restreint et dans le cadre d'une rélfexion commune.
Quelques références :
A vous de jouer :-)