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.

2 commentaires:

Anonyme a dit…

Bravo, brilliant idea

graphitruc a dit…

daily scrum :
aujourd'hui j'ai mangé des cookies