XpEtLeRecrutement

Un article de Agora2ia.

Sommaire

Ma vision

Bonjour Laurent,

Je tiens à te remercier pour cette définition du développeur parfait, qui, par définition et comme chacun sait n'existe pas ;o)

Je ne sais pas si t'as essayé de recruter une personne récemment, mais pour avoir suivi de l'extérieur le recrutement de quelques prestataires, je peux te dire que ce genre de profiles est soit utopique, soit synonyme d'une « longue » expérience et donc incompatible avec les grilles de facturation...

Pour être utilisable, je pense que ta liste de compétences doit être pondérée, prioritisée, certaines étant obligatoires, une incensée !...


COMPETENCE TECHNIQUE

Je pense au fait de « ne pas embaucher quelqu'un sans avoir vu son code »...

A la fin de ma toute première mission de quelques mois, heureusement que Dominic n'a pas agit ainsi, car pour avoir relu mon code par la suite, je ne pourrais pas revendiquer 4 ans et demi de pratique XP à ce jour : merci Coach ! Je n'avais jamais entendu parler de « Principes Objet » ou de « Design Patterns »...

Il faut juger du potentiel de la personne plus que de ses compétences actuelles.

Mais si vous voulez une compétence technique, je pense que les tests et le TDD sont incontournables : d'une car c'est celle qui est la plus difficile à maîtriser, et de deux car elle amène plein de bonnes choses, dont la Qualité à plusieurs niveaux...


L'ASPECT SOCIABLE

De plus, je reste persuadé, que les raisons qu'une équipe XP n'est pas efficace sont (pour ne parler que de celles qu'elle maîtrise) : soit le non respect d'une valeurs ou pratique, soit un membre de l'équipe... Sur mes missions XP, j'ai à chaque fois été confronté à un moment donné à un développeur qui posait problème. Le problème a toujours été relationnel et jamais technique (pour revenir sur « ne pas embaucher quelqu'un sans avoir vu son code »).

Quelqu'un d'ouvert et courageux deviendra bon techniquement.

Quelqu'un de fier, d'orgueilleux, de lâche restera sur sa position, ne se remettra pas en question, ne soulèvera pas les problèmes.

Et puis va faire binômer efficacement et durablement un ermite avec... un autre ermite !


L'EQUIPE

De plus, ce qui me dérange dans ta liste, c'est que j'ai l'impression :

  • Qu'elle s'adresse à un développeur unique, et non à une équipe. Le coach doit mettre en place une équipe qui respecte ta liste (en passant par des développeurs complémentaires plus que tous parfaits).
  • Et que l'efficacité d'une équipe XP s'inscrit dans la durée (comme le préconise le Toyota Way) et la dynamique : les développeurs doivent être capables d'apprendre pour évoluer, s'adapter (aux besoins, aux techniques...).

Un développeur qui aurait toutes ces compétences serait un développeur expérimenté... Ils sont soit « Architectes Logiciel », soit très chers. Il faut donc créer une équipe complémentaire pour contourner cela.

Tu es donc plus dans la peau de Roger Lemerre, qui a pris 11 inconnus d'une équipe de Tunisie déchirée, et a remporté la Coupe d'Afrique des Nations en 2004 et à les amener à tenir en échec l'Espagne hier en Coupe du Monde. Ce qui est mieux au final que d'être dans celle de Raymond Domenech, dont la plupart de ses joueurs jouent dans les meilleurs clubs européens, mais qui est incapable de former une équipe qui marque et qui gagne.

Enfin, sachant qu'une bonne équipe ne pourra naître que de l'osmose de ses membres, pourquoi ne pas faire participer ces derniers aux processus de recrutement, ne serait-ce qu'a titre consultatif ?


DES AMIS EN DEHORS DU TRAVAIL

Enfin, je voudrais rebondir sur le fait qu'il serait intéressant que le candidat ait participé à des Dojo, des groupes de praticiens, des projets Open Source (en mode XP), des conférences XP...

Ce genre de pratiques se fait sur son temps libre. Or, j'ai des collègues actuellement (et j'ai eu précédemment), qui en sortant du bureau le soir arrêtent toute activité s'y rapportant jusqu'au lendemain matin... Et se sont de très bons praticiens XP, avec qui j'apprécie binômer. A l'inverse, il m'est arrivé de rencontrer au cours de ces assemblées des personnes que j'espère ne jamais avoir comme collègue...


CONCLUSION

Au final, je pense que le candidat idéal est une personne :

  • sociable avec qui on aime travailler (on passe quand même 8h assis à 10 cm l'un de l'autre),
  • courageuse pour dire « je ne sais pas » ou « ça ne va pas »,
  • et ayant envie de progresser.


Désolé d'avoir été aussi long.


Mails d'XP-France

Selon Thierry Cross, la réussite dépend plus selon mon expérience de qualités humaines qu'uniquement techniques. Je rechercherais ce que j'appelle le CARA chez les futurs équipiers :

  • Courage, qui est de base dans XP, concrètement courage de participer à une équipe autogérée,
  • Attention, car justement l'autogestion suppose une bonne dose d'attention: à ce qui se passe, aux autres coéquipiers
  • Responsabilité, que l'on retrouve par ex dans le stdupmeeting quand il s'agit de réaliser une tâche,
  • Assertivité, qui est un peu un corollaire, en termes de "savoir-être" dans cette équipe


Selon Laurent :

On peut traiter (je me suis limité à ça dans les deux premiers articles) des généralités: "esprit d'analyse", "de synthèse", "savoir communiquer", etc. Cela dit l'objectif est de pouvoir interroger ou observer quelqu'un et d'avoir des éléments concrets, spécifiques pour évaluer le "fit".

Une idée, d'abord: ne jamais embaucher quelqu'un pour programmer sans avoir préalablement vu un bout de code qu'il (ou elle) a écrit.

Ensuite, je te propose la liste ci-dessous, pas du tout exhaustive, mais qui résulte de mon observation "in situ" de programmeurs exerçant leur métier. Je la complète au fur et à mesure.

  • Savoir poser des questions; c'est essentiel. Le candidat maîtrise-t-il les différents types de questions, les utilise-t-il à bon escient?
  • Savoir répondre: c'est le corollaire. Le candidat va-t-il à l'essentiel, répond-il de façon précise et tranchée ?
  • Savoir estimer: cela mobilise un sens du "plan d'action", à la fois esprit d'analyse (découper en tâches) et de synthèse (rester au niveau de détail immédiatement en dessous de celui de la tâche à estimer, ignorer les ramifications non critiques)
  • Avoir un sens du style: savoir écrire du code qui ressemble à celui du voisin, "faire de l'objet" quand l'équipe programme en objet, etc.
  • Savoir remettre à plus tard: ne chercher à avancer vers la perfection ou la complétude qu'en deuxième étape, la première étant d'atteindre l'objectif fixé
  • Savoir être précis: connaitre la différence entre "syntaxe" et "sémantique" (et par exemple classer des bugs comme provenant d'erreurs dans l'un ou l'autre), entre "expression", "instruction" et "variable", etc.
  • Savoir apprendre. Le programmeur est-il capable de se remettre en question, par exemple d'accepter qu'on critique du code qu'il a écrit? D'utiliser en l'adaptant une technique qu'on lui a démontrée dans un contexte différent ?
  • Savoir être présent. Arriver le matin à l'heure dite, ou bien anticiper ses retards ou ses absences; ou, si on a un retard imprévu, penser à demander ce qu'on a raté. Le corollaire est de savoir être absent: rester chez soi quand on est malade, quand on a trop de soucis pour être efficace au boulot.


Selon Bernard :

Le principal critère pour moi est "avoir envie d'apprendre et de s'améliorer", au sens le plus large du terme:

  • apprendre à mieux coder
  • apprendre à mieux communiquer
  • apprendre à mieux estimer
  • apprendre à mieux reduire les risques
  • etc...

Cela implique aussi un certaine dose d'humilité, et peux expliquer pourquoi certains programmeurs "star" ne s'adaptent pas bien à un contexte XP.


Selon Oazeau :

Une idée : quand on évalue un candidat sur les aspects techniques d'un langage, genre "expliquez moi ce que fait ce bout de code", il arrive un moment où (avec des exercices graduels bien choisis) que le candidat, quel que soit son niveau, ne connaisse pas la réponse.

A ce moment là, on constate plusieurs attitudes :

  • celui qui tente de noyer le poisson en expliquant que c'était évident et qu'il le savait parce que ceci et cela.
  • celui qui se braque en critiquant les tests et en justifiant que de tels problèmes n'arrivent jamais dans un "vrai" projet
  • celui qui se résigne et ne dit plus rien
  • ....
  • celui qui admet qu'il ne connaissait pas tel point de langage et qui pose des questions pour aller au bout de la compréhension du problème

J'ai constaté cela de nombreuses fois tout en ayant clairement précisé aux candidats en préambule que ces tests "n'avaient pas pour objectif de tester la compétence technique mais de regarder leur attitude face à un problème posé"


Ressources