I. Qu'est ce qu'un stagiaire ?▲
Un stagiaire est par définition un étudiant à la recherche d'expérience. Il n'a donc pas (encore) les fonctions d'un ingénieur. Il nous est donc inutile de lui demander une obligation de résultat de la même manière qu'à un autre ingénieur !
Cela ne veut pas pour autant dire qu'un stagiaire est incompétent ! Un stagiaire est une excellente solution pour renforcer une équipe et/ou pour travailler sur des sujets connexes à votre projet (dans les limites du cadre légal).
Attention : le stagiaire n'est pas de la main d'œuvre low cost !
II. Qu'est-ce qu'un tuteur ?▲
Si vous lisez cet article, c'est très certainement par ce que vous voulez et devez tutorer un stagiaire dans un avenir proche. Quels sont donc vos engagements ?
Comme nous l'avons dit plus haut, le stagiaire à pour objectif principal d'obtenir de l'expérience. Vos engagements sont donc limités à lui fournir cette expérience.
Pour cela vous devez :
- former le stagiaire sur le métier de développeur et plus particulièrement sur les technologies associées ;
- coacher le stagiaire tout au long de son stage ;
- accompagner le stagiaire dans son insertion professionnelle. En effet, la plupart des stagiaires ont peu d'expérience du monde professionnel. Il est de notre devoir de lui fournir les clefs lui permettant d'appréhender ce nouveau monde.
En tant que tuteur il est aussi très important pour vous d'assurer le « Team Building » en intégrant votre stagiaire à la vie de votre entreprise et celle de votre équipe. Cela peut prendre la forme d'invitation aux points de l'équipe, aux repas de service, aux afterworks ou encore aux activités CE.
Par ailleurs, j'aimerais rajouter qu'aucune formation n'est réellement nécessaire pour tutorer un stagiaire. Tout le monde peut s'occuper d'un stagiaire à condition d'avoir la volonté de partage de sa propre expérience.
III. Le recrutement▲
Le recrutement est l'étape la plus importante du processus de tutorat. Un stage compliqué ne viendra jamais d'un mauvais stagiaire. Cela n'existe pas ! Un stage compliqué provient d'un recrutement raté.
Tous les stagiaires sont différents et leurs aspirations le sont aussi. Certains seront passionnés et arriveront avec un CV plutôt bien fourni, alors que d'autres seront plus scolaires et arriveront avec un CV moins rempli, attendant les périodes de stage pour le densifier. Par ailleurs, les profils atypiques (i.e. : n'étant pas sortis du classique cursus Bac S / Prépa / Grande école) ne doivent pas être écartés : ces derniers peuvent être une véritable source de fraîcheur et de nouveauté à votre équipe ! La règle d'or est de n'avoir aucun a priori et d'analyser chaque profil à sa juste valeur.
Pour cela, l'important est de bien déterminer votre besoin en termes de stagiaire. Avez-vous besoin de quelqu'un d'expérimenté ? Quelqu'un de passionné ? Quelqu'un ayant un socle technique solide ? Quelqu'un ayant besoin d'autonomie, de fortes compétences relationnelles ou une forte connaissance de votre domaine métier (ou celui de votre client) ?
Le choix du profil dépendra donc de vos besoins. Si vous avez des doutes, consultez votre manager et/ou vos ressources humaines qui seront d'un grand support pour vous accompagner pendant ce processus.
III-A. L'entretien technique▲
Pouvez-vous me donner la signification du mot clef « native » en Java et dans quel cas doit-il être utilisé ? À quoi sert la méthode « finalize » ?
Évitez ces questions dédiées aux ingénieurs expérimentés. Elles sont hors de propos ici. Nous l'avons déjà dit plus haut : le stagiaire est venu vers vous pour acquérir de l'expérience. Ne lui demandez donc pas de prouver qu'il l'a déjà !
Personnellement, j'ai toujours préféré les questions plus vagues et non directement techniques permettant de déterminer le réel profil de mon futur stagiaire.
Par exemple, une vraie analyse de son CV permet généralement d'extraire un ou deux projets notables dans son cursus universitaire. Demandez-lui simplement de décrire fonctionnellement et techniquement l'un de ces projets. N'oubliez pas également les aspects organisationnels de ces projets (méthodologie, équipe, outils…).
La capacité du stagiaire à restituer ces premières expériences sera bien plus révélatrice pour déterminer le réel profil du candidat que ce soit au niveau du « savoir-faire » (technique ou fonctionnel, par exemple) qu'au niveau du « savoir être » (communication, maturité, motivation, adaptabilité, travail en équipe, remise en question...).
En plus de l'analyse des premières expériences, voici un exemple de questions que je pose fréquemment en entretien :
- qu'est ce qui t'intéresse dans notre métier ? Pourquoi as-tu choisi l'informatique ?
- comment te vois-tu dans trois ans ? cinq ans ?
- je vois que tu aimes faire du XXX pendant ton temps libre. Peux-tu nous en parler ?
- je vois que tu as utilisé la technologie XXX. Peux-tu m'expliquer à quoi sert-elle ?
Personnellement, j'ai toujours préféré travailler avec des stagiaires ayant un bon « savoir-être » plutôt qu'avec des stagiaires ayant un meilleur « savoir-faire ». L'expérience m'a montré qu'ils sont d'excellents stagiaires, car très à l'écoute.
IV. L'agilité au service du tutorat▲
IV-A. Les outils que nous allons utiliser▲
Les outils que nous allons utiliser sont issus de l'Agilité et du Lean. Plus particulièrement, nous allons utiliser plusieurs outils fournis par la méthode Scrum. Pour plus d'informations sur l'Agilité et la méthode Scrum, je vous invite à lire les articles dédiés à ces sujets sur developpez.comAgilité sur Développez.com.
Si votre équipe travaille déjà dans un mode « Agile », le stagiaire doit obligatoirement être totalement intégré au processus Agile déjà en place. Les éléments de cette partie deviennent ainsi caduques.
Dans le cas contraire, j'utilise les outils suivants issus de l'Agilité et du Lean afin de tutorer au mieux mes stagiaires :
- le sprint de Scrum ;
- les rôles « Équipe », « Scrum Master » et « Product Owner » de Scrum ;
- le daily meeting de Scrum ;
- le whiteboard Kanban ;
- le sprint planning, la rétrospective et la review Scrum ;
- les users stories de Scrum.
Ces outils sont utilisés dans le cas où l'équipe dans laquelle est accueilli le stagiaire n'est pas déjà Agile ou que ses missions se situent en dehors de ce cadre. Ils permettront d'ailleurs de sensibiliser l'équipe en place (et vous-même peut-être) à l'Agilité.
IV-B. Règle numéro un▲
Ne jamais imposer la démarche à votre stagiaire et ne jamais l'assommer avec les processus liés à cette méthodologie. Il faut que cette démarche émane de lui-même. Pour cela, demandez-lui de proposer son propre cadre Agile en tant qu'exercice. Laissez-lui donc déterminer :
- les rôles « Équipe », « Scrum Master » et « Product Owner » ;
- la durée de ses sprints ;
- les colonnes de son whiteboard ;
- la durée des cérémonies Scrum « Planning », « Rétrospective » et « Review » ;
- l'horaire des « Daily Scrum ».
Ne jamais rejeter directement les premiers choix de votre stagiaire. S'ils ne sont pas en accord avec vos idées, il faut que vous considériez dans un premier temps les siens, car c'est comme cela que l'on apprend de ses stagiaires. Si des améliorations ou des recadrages sont à apporter, des discussions arriveront naturellement lors de rétrospectives pour retravailler ces choix. L'idée est de rester pragmatique !
IV-C. Le sprint de Scrum▲
L'une des principales caractéristiques de la méthode Scrum est le découpage du développement en portions de temps fixes. C'est le premier outil que nous allons utiliser pour notre stagiaire.
Un sprint commence par un « Sprint Planning » et se conclu par (dans l'ordre) : une « Review » et une « Rétrospective ».
L'utilisation des sprints permet de suivre au plus près notre stagiaire et ainsi détecter au plus tôt et corriger les éventuelles difficultés rencontrées.
Le premier sprint (i.e. : sprint 0) doit être utilisé pour donner le temps au stagiaire de s'intégrer à son environnement (projet, équipe, technologies) et définir son cadre agile (cf. Règle numéro un). Ce premier sprint ne devrait pas dépasser trois semaines.
Attention : le sprint 0 ne doit pas être utilisé pour monter totalement en compétence sur les technologies du projet. Cette montée en compétence doit être réalisée progressivement au fur et à mesure des sprints.
IV-D. Les rôles « Équipe », « Scrum Master » et « Product Owner » de Scrum▲
La méthode SCRUM propose trois rôles principaux :
- l'équipe de développement qui est en charge de la conception du produit ;
- le « Scrum Master » qui est en charge de porter la méthode et de coacher l'équipe ;
- le « Product Owner » qui est responsable du produit. Il représente le client et ses besoins.
Nous allons réutiliser ces rôles pour notre stagiaire. Ils vont lui permettre de définir son équipe et ainsi une partie de son cadre de travail.
Ainsi, dans notre cas :
- l'équipe de développement permettra de répondre aux questions techniques de notre stagiaire, mais aussi à certaines questions fonctionnelles sur le projet. Le stagiaire devra être totalement intégré dans cette équipe. Elle lui permettra notamment de se former sur les technologies du projet et son architecture ;
-
vous devriez être naturellement désigné par votre stagiaire comme le « Scrum Master » de son stage (même si ce n'est pas obligatoire). Le Scrum Master devra :
- planifier et animer les cérémonies Scrum telles que les « Daily Scrum », les « Sprint Planning », les « Rétrospective » et les « Reviews »,
- coacher le stagiaire ;
- vous devez désigner un autre membre de l'équipe pour réaliser la priorisation des tâches du stagiaire. Si la personne désignée manque de temps, vous pouvez prendre une partie de ses tâches. Dans tous les cas, elle devra être la personne qui valide les développements du stagiaire lors des « Reviews ».
IV-E. Le Daily Scrum▲
Le « Daily Scrum » de la méthode Scrum est un « Stand Up Meeting » permettant aux membres d'une équipe Scrum de faire le point sur ses activités au jour le jour.
Dans le cas du tutorat, nous allons réutiliser cet outil pour faire un point journalier de cinq minutes maximum dans lequel nous allons demander au stagiaire :
- Qu'as-tu fait hier ?
- Que prévois-tu de faire aujourd'hui ?
- Est-ce que tu rencontres des difficultés ?
C'est cette dernière question qui est la plus importante. En effet, si votre stagiaire vous fait part de certaines difficultés, la première règle est : ne pas résoudre directement ces difficultés. Tout d'abord, il faut lui donner les clefs (ressources documentaires ou web ou encore un autre membre de l'équipe) pour résoudre par lui-même son problème. En effet, nous sommes expérimentés et avons trop vite le réflexe de donner la solution au problème, tout de suite. Mais c'est une erreur fondamentale : il faut que votre stagiaire trouve les solutions de lui-même. Si, et seulement si, le problème est vraiment bloquant et que le stagiaire est dans une impasse, demandez-lui d'organiser une réunion dédiée à la résolution de cette problématique.
Par ailleurs, le « Daily Scrum » peut prendre plusieurs formes. Il peut être sous forme de « Stand Up Meeting » comme traditionnellement conseillé ou une forme plus dématérialisée (mail ou visioconférence, par exemple) dans le cadre d'un tutorat où vous ne pouvez être géographiquement tout le temps présent.
IV-F. Le whiteboard Kanban▲
Le whiteboard Kanban n'est pas originellement un outil agile mais un outil Lean permettant de modéliser le flux du processus de développement.
Dans notre cas, nous allons le réutiliser pour matérialiser le DoD (« Definition Of Done ») de Scrum : chaque colonne du tableau devra modéliser une tâche à réaliser pour terminer une « User Story ».
Comme conseillé dans la partie Règle numéro un, les colonnes doivent être définies par le stagiaire lui-même mais avec notre aide. Si des colonnes sont (réellement) manquantes, ne vous inquiétez pas, votre stagiaire vous les suggérera naturellement lors d'une Rétrospective.
Voici les colonnes que j'ai constatées comme les plus utilisées :
- Design ;
- Développement ;
- Tests Unitaires / Tests Intégration ;
- Refactoring ;
- Code Review ;
- Test fonctionnels ;
- Documentation (Spécification, Conceptions, Wiki…).
J'ai souvent vu les colonnes « Refactoring » et « Code Review » venir plus tard dans le stage. En effet, elles sont souvent ajoutées après avoir fait plusieurs remarques sur les codes sources produits.
IV-G. Les cérémonies Scrum▲
Les cérémonies Scrum constituent une des plus grande force de la méthode. Dans le cadre de la gestion des stagiaires nous allons réutiliser :
- Le « Sprint Planning » (maximum 1 h pour un stagiaire) ;
- La « Review » (maximum 30 minutes pour un stagiaire) ;
- La « Rétrospective » (maximum 30 minutes pour un stagiaire).
IV-G-1. Les Users Stories et le « Sprint Planning » Scrum▲
Le « Spring Planning » vous permet de définir ensemble les tâches que votre stagiaire va réaliser lors du prochain sprint.
Lors de cette étape, vous devez arriver avec un ensemble d'« User Stories » (Récits utilisateur) à proposer à votre stagiaire, idéalement sélectionnées par le « Product Owner » (Propriétaire du produit) comme il est stipulé dans la méthode Scrum.
Il est de votre devoir de veiller à ce que les « User Stories » que vous allez proposer à votre stagiaire soit bien définies et d'un coût faible. En effet, des « User Stories » trop importantes ou mal définies sont impossibles à réaliser par des équipes Scrum classiques, alors imaginez la difficulté que cela représente pour un jeune stagiaire…
Lors du sprint planning, exposez clairement les objectifs de chacune des « User Stories » et vérifiez que votre stagiaire en a perçu les enjeux.
Par la suite, demandez à votre stagiaire de les estimer avec la suite de Fibonacci du Planning Poker. Il est important que votre stagiaire s'affranchisse d'un quelconque chiffrage en termes de charge ou de délai. Laissez-lui donc l'entière liberté de son évaluation mais posez-lui des questions pour qu'il explique son choix. Pour l'aider à évaluer son travail et mettre en place son échelle d'estimations (notamment lors des premiers sprints), faites le parallèle avec ces précédentes estimations. Par exemple : « lors du sprint N-1, tu as estimé l'US X à cinq points. Pour ce sprint, l'US Y qui est similaire à X. Aujourd'hui tu mets trois points. Qu'en penses-tu ? » Vous pouvez également utiliser une US « étalon » si votre stagiaire est déjà expérimenté.
Si certaines « User Sorties » ont un poids relativement important (supérieur ou égal à 13), vérifiez que votre stagiaire a bien compris l'US. Si c'est bien le cas, il est fort à parier que vous lui proposiez des US trop importantes… À vous de corriger le tir !
IV-G-2. La « Review »▲
La « Review » doit être organisée en trois parties :
- La première partie doit être organisée avec la participation de toute l'équipe, du « Scrum Master » et du « Product Owner ». Lors de cette première partie, demandez à votre stagiaire de présenter ses travaux aux autres et demandez au « Product Owner » sa validation (si cela n'a pas pu être réalisé au fil du sprint) ;
- La seconde partie consiste à faire un bilan du sprint : il faut déterminer quelles sont les « User Stories » achevées (i.e. : validées par le « Product Owner »). Calculez ensuite ensemble la nouvelle vélocité ;
- La dernière partie doit être dédiée à la review du code produit par le stagiaire, notamment lors des premiers sprints et à une review du rapport et du diaporama de soutenance dans les derniers sprints.
Cette cérémonie est très importante, car elle permet deux choses :
- Apprendre au stagiaire à présenter son travail et faire face aux retours de son équipe ;
- Communiquer sur les travaux du stagiaire si ce dernier ne travaille pas directement sur le projet.
Ne condamnez pas votre stagiaire si plusieurs « User Stories » n'ont pas été validées par le « Product Owner ». C'est tout à fait normal, surtout si vous n'êtes qu'au début du stage. Par contre, posez-vous la question : « ne serait-il pas intéressant de retravailler le DoD de votre stagiaire en ajoutant / supprimant des colonnes de son whiteboard ? ».
IV-G-3. La « Rétrospective »▲
La « Rétrospective » Scrum est l'un des outils les plus importants de votre tutorat : elle va permettre à votre stagiaire de s'auto-évaluer et de proposer des actions d'améliorations.
Pour cet exercice, j'utilise majoritairement une technique dérivée du Turn The Table :
- prenez chacun deux post-it : un rouge et un vert ;
-
pendant cinq minutes, chacun donne :
- sur le post-it vert : un seul mot pour décrire quelque chose qui a bien fonctionné lors du dernier sprint,
- sur le post-it rouge : un seul mot pour décrire quelque chose qui a mal fonctionné lors du dernier sprint ;
- échangez les post-it ;
- chacun à son tour analysez le point positif de l'autre rédigé sur le post-it vert ;
- chacun à son tour analysez (ou extrayez) l'axe d'amélioration rédigé sur le post-it rouge ;
- à partir des informations récoltées en D & E, mettez ensemble en place une seule et unique action pour les prochains sprints.
V. Le rapport de stage & la soutenance de fin de stage▲
Le rapport de stage et la soutenance de fin de stage sont deux lourds exercices obligatoires pour le stagiaire. Ils sont souvent source de stress en fin de stage.
V-A. Le rapport de stage▲
Afin d'éviter une rédaction du rapport « à la va vite » en fin de stage, l'une des astuces est de lui proposer une rédaction progressive. Personnellement, je propose à mes stagiaires de rédiger à chaque sprint une petite partie du rapport sous la forme d'une « User Story » dédiée. Il est d'ailleurs intéressant de demander à votre stagiaire de proposer au plus tôt un plan pour son rapport.
Les premières parties à rédiger, et ce dès les premiers sprints, sont les suivantes :
- Les objectifs personnels. Il faut demander au stagiaire de penser « avant le stage » et de faire le point sur ses ambitions au moment de sa recherche de stage. Cela vous permettra de savoir qu'elles sont ses aspirations et d'adapter, autant que faire se peut, son périmètre de stage. Vous pourrez le faire pendant l'entretien de stage, par exemple (cf. L'entretien de stage) ;
- Les objectifs professionnels. Cela permet au stagiaire de réellement prendre pleinement conscience de ses missions et de les formuler avec ses propres mots. S'il y a certaines incompréhensions, vous pourrez ainsi les traiter au plus tôt ;
- La présentation du contexte. Cette partie permet au stagiaire de découvrir en profondeur son environnement (entreprise(s) accueillante(s), projet(s), équipe(s)...).
Il ne faut surtout pas oublier de demander la rédaction du bilan des objectifs en fin de stage qui permet au stagiaire de répondre point par point à l'ensemble de ses objectifs
L'un des avantages de cette démarche est de pouvoir relire progressivement le rapport et de s'affranchir d'une relecture mouvementée et à la va-vite en fin de stage.
V-B. La soutenance de fin de stage▲
La soutenance de fin de stage devrait être préparée au moins un mois avant la fin du stage. D'ailleurs, si le rapport de stage a été rédigé progressivement, votre stagiaire devrait avoir une bonne matière pour préparer son diaporama.
Je vous conseille d'ailleurs d'intégrer cet exercice aux derniers sprints comme « User Story », remplaçant ainsi celles dédiées au rapport qui devrait être terminé. Avec cette démarche vous pouvez lui demander d'organiser une soutenance blanche avec un auditoire varié (membres de l'équipe, responsables et personnes extérieures au projet) tout en l'accompagnant.
Il est impératif que cette soutenance blanche soit exécutée dans les conditions les plus proches de celles de la véritable soutenance. Nous devons donc lui demander d'utiliser la version finale de ses diapos et présenter ses travaux devant un auditoire avec un projecteur. Il faut aussi prendre en compte le temps de la soutenance en utilisant un chronomètre afin de s'assurer que le stagiaire respecte les limites de temps qui lui sont imparties par sa formation. Si ce dernier les dépasse ou à l'inverse s'il n'utilise pas le temps accordé, vous pouvez l'aider à retravailler sa soutenance, que ce soit au niveau du contenu de son support ou de son discours.
Plus l'auditoire de cette soutenance blanche sera varié, plus les retours seront pertinents. Vous aurez ainsi pu proposer la meilleure préparation possible à votre stagiaire.
VI. L'entretien de stage▲
Quand nous sommes dans le feu de l'action, nous nous rendons très vite compte que le stage arrive à son terme sans avoir fait un bilan réel de ce dernier. Êtes-vous satisfait du travail de votre stagiaire ? Plus important encore, est-ce que votre stagiaire est satisfait de son stage ? Comment corriger le tir si ce n'est pas le cas ?
Malheureusement, les rétrospectives décrites plus haut ne sont pas adaptées à ce genre d'exercice, car trop axées sur le projet et non pas sur le « management » humain.
Si vous faites un bilan uniquement en fin de stage, il est bien trop tard pour donner votre avis sur le travail du stagiaire. En effet, il n'a plus le temps de prendre en compte vos remarques et de s'améliorer. De la même manière, vous n'aurez pas le temps de prendre en compte ses remarques et de vous améliorer.
Il est très important important de pouvoir faire le point dans un cadre privilégié tous les six mois. Pendant ces entretiens de stage, il faut :
- Demander à votre stagiaire quels sont ses points forts pendant de son stage ;
- Demander à votre stagiaire quels sont ses axes d'amélioration et ses futures attentes ;
- Faire le bilan ensemble de ses points forts et de ses axes d'améliorations ;
- Mettre en place ensemble les actions nécessaires.
VII. S'améliorer en tant que tuteur ▲
Il ne faut jamais prendre sa méthodologie comme acquise. Il est toujours possible de s'améliorer en tant que tuteur.
La question est de savoir : qui peut nous aider à nous améliorer en tant que tuteur ? La réponse la plus évidente est : nos stagiaires.
Pour cela, quoi de mieux que leur proposer une rétrospective sur vous-même ? Personnellement, j'ai toujours demandé un retour à mes stagiaires à la fin de leur stage en utilisant la technique de « l'étoile de mer ». Si vous avez établi une relation de confiance avec vos stagiaires, il est certain que vous obtiendrez les meilleurs retours possibles pour vous améliorer pour les prochains :).
VIII. Remerciements ▲
Tout d'abord, je tiens particulièrement à remercier Sylvain CambonSylvain Cambon pour les conseils avisés qu'il m'a donnés lors de ma première expérience avec des stagiaires et qui ont constitué la base de cet article. Je le remercie également pour son indispensable relecture.
Je ne pourrais terminer cet article sans remercier également mes stagiaires (Romain, Mathias, Flavien, Matteo, Cédric & Damien) qui m'ont tellement appris et sans eux cet article n'aurait jamais existé.
J'aimerais également remercier Mickaël Baron et Alain Bernard pour m'avoir permis de démarrer l'aventure Developpez.com.
Pour finir, j'aimerais remercier Guillaume Sigui et Jacques Thery pour leur relecture de cet article et leurs précieux conseils.