Si vous vous rappelez bien notre précédent article, nous avons vu Gil passé par le stade de l’entretien puis de son arrivée. Arrivée si attendue par sa nouvelle équipe. Fort de l’accueil chaleureux recueilli, ce dernier vient de passer brillamment la première semaine. Gil n’est pas dupe et sait que le plus dur reste à venir. Au mieux l’équipe aura préparé cette troisième phase d’onboarding, le plus simple ce sera pour lui de s’y intégrer.
Dans cette seconde partie, nous allons voir des techniques/méthodes pour y parvenir. Nous verrons que l’environnement de travail et le team building peuvent jouer un rôle dans ce processus. Et pas que pour ce processus, mais aussi pour avoir un turn-over le plus faible possible.
Techniques ou méthodes d’intégration
Voici quelques techniques/méthodes pour aider au mieux Gil à s’intégrer:
le pair programming
Cette technique consiste à binômer deux personnes. Les avantages de cette techniques sont nombreux:
- elle favorise la communication entre les pairs
- elle permet aux pairs d’apprendre à travailler ensemble
- elle renforce les liens entre les gens et permet ainsi de créer un esprit d’équipe Dans le cas précis de l’arrivée de Gil, le pairer avec une personne connaissant bien le logiciel sur lequel il doit intervenir, devrait lui permettre de monter en compétence plus rapidement. Le pairer avec la personne qu’il doit remplacer devrait aussi l’aider en ce sens. Prévoyez dans ce cas un temps suffisamment large pour que Gil ait le temps de récupérer toutes les connaissances de son prédécesseur. Un problème ou une question sont rencontrés, les échanges étant dynamiques, Gil est à même d’être aidé par son pair expérimenté. En dehors de sa montée en connaissances, cela va lui permettre de donner son point de vue. Gil a un regard neuf sur l’existant et les méthodes déjà en place, il pourrait donc aussi permettre d’améliorer cela.
Enfin le pair a d’autres avantages, comme le fait de permettre de développer des applications mieux pensées et de meilleure qualité: deux cerveaux valent mieux qu’un.
Vous l’aurez compris tout est bon dans le pair-programming.
Faire des feedbacks réguliers : rapports d’étonnements, points réguliers
Un feedback est un moyen de faire un retour à une personne ou un groupe de personnes sur ses/leurs actions passées (merci Captain Obvious:)) et ce dans le but d’agir sur les actions futures de celle(s)-ci, afin de les améliorer.
Faire des points réguliers afin de mieux intégrer Gil est important. Quelque soit le type de critiques, il est important de les exprimer d’un côté ou de l’autre.
- si elles sont positives par rapport à son travail et ou son comportement, cela le confortera et l’incitera à continuer. Dans le cas où les retours de Gil concernant l’équipe sont bons, cela montrera à celle-ci que ses méthodes de travail et d’intégrations sont bonnes. Avoir capitalisé dessus paie 😉
- si elles sont négatives vis à vis de Gil, cela doit lui permettre de corriger le tir. Idem si elles sont négatives vis à vis de l’équipe déjà en place. Cela est encore plus vrai si Gil n’est pas le premier à les remonter. Dans tous les cas ici, le feebback se devra d’être constructif.
Dans cette optique, faire quelques rapports d’étonnements du côté de Gil et des points réguliers devraient permettre d’aller en ce sens. La communication est la clé de voûte pour améliorer l’intégration d’un nouveau et les processus afférents.
Échanges avec le métier: formation métier pour tous les nouveaux arrivants
En tant que développeur, nous transcrivons un besoin exprimé par le métier en code. Il est important de réaliser que ce qui part en production n’est pas l’idée qu’en a le métier mais ce qu’en comprennent les développeurs. Il est donc important de bien se familiariser avec le métier sous-jacent aux applications sur lesquelles nous travaillons. Suivre une formation sur le métier peut s’avérer extrêmement utile. Cela peut paraître évident. Pourtant trop souvent, lorsqu’un développeur arrive sur un nouveau périmètre fonctionnel, on lui fait une courte présentation du métier. Par la suite il sera lâché directement sur le code. Le but étant de viser une rentabilité dès son arrivée T_T. Celui-ci se dépatouille tant bien que mal avec les objets d’un métier qu’il ne maîtrise pas. Cela pourrait le frustrer, voire le pousser au départ. De plus, le code produit sera certainement d’une qualité moindre.
Former convenablement un nouveau sur le métier permet plus que sa bonne intégration, cela permet aussi d’investir dans un code de meilleure qualité. Cela générera à moyen et long terme des économies plus importantes que le coût de la formation.
Passer au tout début du temps avec le métier ou la QA afin de bien s’imprégner du fonctionnel
En plus de former de manière académique Gil sur le fonctionnel, lui faire passer du temps avec le métier ou la QA peut lui permettre de s’en imprégner plus fortement et plus rapidement. Il partagera le même vocabulaire que le métier (ubiquitous language), et sera à même de mieux transcrire le besoin en code par la suite. Cela permet aussi de rapprocher les équipes, d’améliorer leur communication, et de produire le plus constamment possible de la valeur et du code de qualité. Autre avantage, Gil voit aussi comment est utilisé le logiciel et quels sont les cas d’utilisation les plus fréquents. Il peut aussi voir ce qui auraient échappé au Business Analyst (BA) ayant transcris le besoin du métier vers les développeurs.
Macro vers Micro et Micro vers Macro:
Lorsque Gil arrive, et qu’il ne connaît pas le fonctionnel, il est important de le lui expliquer. On commence à le lui expliquer dans les grandes lignes (Macro). Plus le temps passe, plus sa compréhension augmente, et plus on descend au niveau des détails (Micro). On commence donc d’une explication fonctionnelle macroscopique vers une explication fonctionnelle microscopique.
Concernant les développements, le cheminement est inversé. On commence du plus spécifique (Micro), pour devenir le plus généraliste possible (Macro) avec le temps. Vous ne pouvez pas décemment attendre du nouveau d’avoir une vision globale du ou des logiciels sur lesquels il va travailler en arrivant. Il faudra donc le faire monter en compétences et connaissances avec le temps. Il fuadra procéder par baby-steps en fonction de la complexité rencontrée. On commence donc par des développements spécifiques à faire (micro), et avec le temps passant on pourra lui attribuer des développements transverses (macro).
Tout cela peut sembler logique. Mais comme dit précédemment, il arrive parfois que le nouveau soit lancé directement dans du code sans aucune formation. Dans ce cas la seule qu’il acquerra sera au niveau de sa compréhension du code et de ses échanges avec les autres.
Living documentation:
Avoir une documentation de qualité peut aider Gil dans son intégration. Malheureusement bien souvent celle-ci est obsolète. De facto, elle génère encore une fois une perte de temps, de la frustration pour Gil ainsi qu’une perte d’argent pour l’entreprise.
Mais comment arriver à avoir une documentation à jour et compréhensible alors que le code ne cesse de changer? Comment éviter un écart possible entre le comportement de nos applications et ce qui en est spécifié?
Une réponse possible est de faire de la living documentation. C’est un ensemble de méthodes permettant de fournir dynamiquement de la documentation à jour. Si vous faites du BDD, chacun des tests que vous avez écrit correspond à un fonctionnement attendu de la part du métier (spécification par l’exemple). Ces tests présentent aussi les termes du métiers et permettent à Gil de s’en imprégner encore un peu plus. Le fait de faire du pair programming y contribue aussi; la connaissance est transmise de manière dynamique par la communication entre les pairs. Dans ce contexte, les connaissances sont censées être à jour.
Je vous invite à lire le livre sur la living documentation de Cyrille MARTRAIRE (@Cyriux) que vous pourrez trouver à l’adresse suivante: https://leanpub.com/livingdocumentation
Environnement
L’environnement dans lequel va évoluer Gil va aussi jouer un rôle important à son intégration. Les méthodes agiles et des événements relatifs à la fonction de développeur peuvent être aussi des facteurs décideurs en ce sens.
Agilité
L’agilité est aussi une méthode pour mieux intégrer Gil. Les méthodes agiles favorisent la communication et les interactions entre toutes les parties du processus de développement. Grâce aux différents rituels (sprint plannings, daily stand-ups, rétrospectives, reviews), Gil se retrouve directement au cœur de ce qui se passe dans l’équipe et peut interagir avec elle. Les pratiques défendues dans les principes sous-jacents au manifeste agile favorisent l’autonomie de l’équipe, la qualité et l’excellence technique. En principe tout développeur se disant appartenir à la mouvance crafts doit apprécier cela.
Le manque d’agilité peut être un frein puissant à l’intégration de Gil. Il pourrait être intéressant si vous n’êtes pas encore dans ce mode de songer à y passer. Au delà de favoriser ce type d’intégration, elles apportent d’autres avantages:
- ouverture aux changements
- meilleure visibilité entre les parties entre ce qui est attendue et ce qui est livrée
- et donc meilleure collaboration avec le client. Il en existe encore d’autres. Le but n’étant pas de tous les lister ici mais de présenter ceux que vous pouvez proposer à votre hiérarchie afin de les adopter.
Événements
Participer à différents types d’événements techniques nous permet de rencontrer nos pairs, des gens avec qui nous avons des intérêts communs. Cela permet de s’intégrer à une communauté. Ce sont des moments d’échanges, qui nous permettent de monter en compétence sur différents sujets. Certains développeurs en sont très friands. Organisés ce type d’événements en interne ou permettre d’y participer peut grandement aider à conserver vos membres d’équipe. Toutes les sociétés ne le permettent pas. C’est donc un avantage pour ses membres. Cela peut aussi faciliter l’intégration de Gil qui verra que vous portez de l’attention à ses centres d’intérêts.
Plusieurs formes existent pour ces types d’événements:
Brown Bag Lunch (BBL)
Un sujet vous intéresse et vous avez envie de l’approfondir, soit en faisant venir un expert, soit en partageant vos connaissances dessus. Mais le soir vous n’avez pas le temps car vous devez renter vous occuper de votre famille. Pourquoi ne pas faire cela le midi lors de la pause déjeuner. C’est le principe du BBL. Un expert vient vous présenter un sujet le midi. Vous ramenez votre déjeuner dans votre BBL. Pendant que l’on vous expose les bienfaits d’une technologie/méthodologie, vous savourez votre mets. Votre estomac ainsi que votre esprit en ressortent rassasiés ^^.
Meetup ou User Group
Si vous pouvez le soir, pourquoi ne pas héberger un meetup ou un User Group. Un meetup est une rencontre informelle qui peut toucher tous les types de sujets. Ils peuvent être les mêmes que pour un BBL mais plutôt que de se limiter à une ou deux heures maximum le midi, ici il est possible de pousser cela un peu plus longtemps: trois ou quatre heures. Cela aura aussi pour mérite de rencontrer des gens susceptibles d’être de futurs employés. Pourquoi cela me direz-vous? Simplement parce qu’ils partagent des points communs avec ceux en poste chez vous qui organisent ces événements. N’oubliez pas dès lors de faire un effort sur les boissons et les « mets » que vous proposerez aux gens qui viendront (qui a dit que nous sommes des gens intéressés ^^).
Conférences
Pendant deux ou trois jours, n’hésitez pas à envoyer vos internes à des conférences telles que Devoxx ou NCrafts entre autre. Cela permet à vos équipes
- de voir ou d’échanger sur des sujets connexes à vos besoins ou bien qui les passionnent,
- de trouver des réponses à des problématiques qu’ils n’avaient jusque là pas encore trouvé. Plus que les conférences, ce sont les échanges qui ont lieu à côté qui peuvent y amener; les speakers sont souvent des gens sympathiques avec qui vous pouvez échanger très simplement.
Team building
Le team building permet de renforcer la cohésion d’équipe. Cela a pour but:
- de créer des liens entre les membres de l’équipe,
- de leur apprendre à se connaître dans un lieu autre que le travail,
- d’apaiser les tensions qui pourraient y régner.
Plusieurs moyens/activités existent pour aller en ce sens:
- Organiser des petits déjeuners, des restaurants ou des soirées (dans un bar, à la boîte, etc…)
- faire des activités sportives ou autres (foot en salle, tournoi de baby-foot, etc…)
- faire des katas en équipe
- Organiser des sorties lors de certains événements (comme un cinéma lors de la sortie du dernier Star Wars). Cette liste n’est pas exhaustive, à vous de voir ce qu’il est possible de lui rajouter afin de correspondre à votre contexte.
Si tout se passe bien lors de ces événements, les membres de l’équipe ont tendance à se rapprocher, les tensions à diminuer et donc les problèmes de se régler plus facilement (si jamais il y en a). Cela permet aussi d’intégrer plus facilement les nouveaux
On voit qu’il est possible de favoriser l’intégration de Gil avec ce type d’activités. Lors du recrutement, vous avez peut être pu scanner ses goûts en la matière. Dans un premier temps, sans trop en faire, adaptez-vous à lui afin de le faire se sentir bien; par la suite, faîtes des choses qui soient plus en accord au goût de tous les membres de l’équipe.
Il ne faut pas forcément négliger ce point car mal intégrer humainement/socialement Gil pourrait amener à son départ.
Conclusion
Parfois Le processus d’onboarding sera efficace, parfois non. Rien n’est absolu en ce sens. Si la personne ne reste pas, il faut essayer de comprendre ce qui n’a pas marché et corriger cela quand c’est possible. C’est en améliorant petit à petit ce processus, que l’on arrivera à maximiser l’intégration des nouveaux et le retour à une vélocité de croisière.
Nous avons beaucoup parlé de comment bien intégrer Gil. Il ne faut pas oublier non plus que Gil doit aussi faire des efforts pour s’intégrer. Ce n’est pas à sens unique. Parfois des erreurs de casting peuvent se produire. Plutôt que d’insister alors que l’on sait pertinemment que la sauce ne prend pas, il vaut mieux se séparer avant d’avoir perdu trop de temps d’un côté comme de l’autre. Cela ne sera pas une expérience inutile non plus, car il vous sera encore possible d’apprendre de cette impair.
Dans tous les cas, rien n’étant jamais acquis, améliorez le plus possible votre processus d’onboarding. Celui-ci évoluera, s’améliorera avec le temps et correspondra de plus en plus à votre équipe. Soyez aussi créatif. Une touche d’originalité peut avoir beaucoup d’effets positifs sur l’intégration de Gil et sur l’équipe. Tout le monde y gagne ^^.
Remerciements
Je tiens à remercier mes collègues et aussi tout particulièrement les personnes qui ont voté et assisté à la présentation/table ronde du meetup Software Craftsmanship Paris du 26 janvier 2016. Certaines des idées présentes ici sont les leurs. Encore un grand merci, car sans eux cet article ne serait pas ce qu’il est.