Le développement de logiciels se fait souvent en équipe. Cependant, il y a des défis pour travailler en équipe. Souvent, avant l’université, on apprend comment s’organiser en équipe, faire des rencontres, répartir le travail, planifier, etc. Pourtant, il y a d’autres défis dans ce travail, des défis sur le plan humain. C’est le sujet du livre « Team Geek » (2012), écrit par Brian W. Fitzpatrick (ancien employé de Google) et Ben Collins-Sussman (développeur fondateur du système de contrôle de version Subversion, employé de Google).
Aujourd’hui, la demande pour le talent en technologies de l’information est importante. Les technologies évoluent constamment, et le temps que vous investissez pour maîtriser une technologie est important. Pourtant, il y a des risques avec certains investissements de temps à long terme. Par exemple, qui développe encore du code pour Flash ? Cette technologie est maintenant désuète, et ça ne vaut pas beaucoup de mentionner cette compétence sur un CV.
La bonne nouvelle est qu’une « technologie » ne changera jamais : le comportement humain. Donc, il est toujours rentable d’investir du temps pour mieux maîtriser cet aspect du développement. Les entreprises en technologies de l’information sont toujours à la recherche de développeurs(euses) qui ont également des compétences générales (soft skills).
Fitzpatrick & Collins-Sussman (2012) abordent des problèmes dus aux tendances comportementales chez les développeurs(euses). Par exemple, une personne n’a pas toujours envie de montrer son code source aux autres membres de l’équipe pour plusieurs raisons :
- Son code n’est pas fini.
- Elle a peur d’être jugée.
- Elle a peur que quelqu’un vole son idée.
Dans tous ces cas, il s’agit d’insécurité, et c’est tout à fait normal. Par contre, ce genre de comportement augmente certains risques dans le développement :
- de faire des erreurs dans la conception initiale ;
- de « réinventer la roue » ;
- de terminer le travail plus tard que son compétiteur, qui, lui, a collaboré avec son équipe.
Fitzpatrick & Collins-Sussman (2012) le disent, et c’est un fait : si nous sommes, dans l’ensemble, plus ou moins compétent(e)s sur le plan technique, ce qui fera la différence importante dans une carrière est notre habileté à collaborer avec les autres.
12.1 Humilité, respect, confiance
L’humilité, le respect et la confiance (voir la figure 12.1) sont les qualités de base pour le bon travail en équipe. Cette section présente ces aspects en détail.
12.1.1 Humilité
Voici la définition d’humilité selon Antidote :
Une personne humble pense ainsi (Fitzpatrick & Collins-Sussman, 2012) :
- Je ne suis pas le centre de l’univers.
- Je ne suis ni omnisciente ni infaillible.
- Je suis ouverte à m’améliorer.
L’humilité ne veut pas dire « je n’ai pas de valeur » ou « j’accepte les attaques de la part des autres ». Voir la section Proposer des solutions au besoin.
Quelques exemples concrets d’humilité dans le développement :
- Les membres de l’équipe qui débutent en JavaScript, Git, etc. vont le reconnaître et vont même faire des exercices sur Internet pour s’améliorer.
- Les membres de l’équipe qui ont pris une mauvaise décision (technique ou autre) vont l’avouer. Elles et ils savent que les autres ne sont pas là pour les attaquer (il y a du respect).
- Un(e) membre de l’équipe va travailler fort pour que son équipe réussisse.
- Un(e) membre de l’équipe qui reçoit une critique ne va pas la prendre personnellement. Il ou elle sait que la qualité de son code n’équivaut pas à son estime de soi (cela n’est pas toujours facile!).
12.1.2 Respect
Une personne démontrant du respect pense ainsi (Fitzpatrick & Collins-Sussman, 2012) :
- Je me soucie des gens avec qui je travaille.
- Je les traite comme des êtres humains.
- J’ai de l’estime pour leurs capacités et leurs réalisations.
12.1.3 Confiance
Une personne démontrant de la confiance pense ainsi (Fitzpatrick & Collins-Sussman, 2012) :
- Je crois que les autres membres de l’équipe font preuve de compétence et de bon jugement.
- Je suis à l’aise lorsque les autres (membres de l’équipe) prennent le volant, le cas échéant.
Le dernier point peut être extrêmement difficile si, par le passé, une personne (incompétente) à qui vous aviez délégué une tâche n’a pas répondu à vos attentes.
12.2 Redondance des compétences dans l’équipe (bus factor)
Pour qu’une équipe soit robuste, il faut une redondance des compétences. Sinon, la perte d’un(e) membre de l’équipe (pour une raison quelconque) peut engendrer de graves conséquences, voire arrêter carrément le développement. Ce principe a été nommé en anglais bus factor. C’est le nombre minimum de personnes à perdre (par exemple, elles ont été heurtés par un bus) pour arrêter le projet par manque de personnel bien informé ou compétent. Par exemple, dans un projet de stage, si c’est vous qui écrivez tout le code, alors c’est un bus factor de 1. Si vous n’êtes plus là, le projet s’arrête !
.
Dans le cas d’une équipe, un(e) membre de l’équipe peut s’absenter ou être moins disponible pour beaucoup de raisons. Par exemple, cette personne part en vacances, tombe malade, prend un congé parental, change d’emploi, abandonne le cours (contexte de projet universitaire), etc. Cherchez à répartir les responsabilités dans l’équipe afin d’avoir un bus factor d’au moins 2. Partagez des compétences pour maintenir une équipe robuste.
Vous pouvez également garder votre solution simple et garder la documentation de votre conception à jour. L’automatisation des tests dans un processus de construction de logiciels (build process) à la devops (Chapitre 10) aide aussi, car l’équipe ne dépend pas d’une personne pour construire la solution, rouler les tests, etc. Ces pratiques vont également faciliter l’intégration de nouvelles personnes dans l’équipe.
Si un(e) membre de l’équipe quitte en cours de trimestre, il n’est pas facile de maintenir le même rythme. Cependant, les enseignant(e)s et les auxiliaires de laboratoire s’attendront à ce que vous ayez pensé à un « plan B » avant cette perte. Au moins une autre personne dans l’équipe doit être au courant de ce que faisait l’ancien(ne) membre de l’équipe, pour que le projet ne soit pas complètement arrêté.
12.3 Mentorat
Pour des raisons pédagogiques (Oakley, Felder, Brent, & Elhajj, 2004), c’est l’enseignant(e) qui décide la composition des équipes. Ça veut dire que, forcément certaines personnes de l’équipe ont plus d’expérience et de facilité à faire certaines tâches que d’autres. Les équipes doivent composer avec cette diversité.
Selon Fitzpatrick & Collins-Sussman (2012) :
Si les personnes plus fortes n’aident pas les autres, ils risquent de les éloigner de l’équipe et de se retrouver seules sur le plan des contributions techniques. Voir la section sur la Redondance des compétences dans l’équipe (bus factor).
Encadrer un(e) membre de l’équipe au début du trimestre peut prendre beaucoup de temps. Mais, si la personne devient plus autonome, c’est un gain pour toute l’équipe. Cela augmente également le facteur de bus.
Voici quelques conseils pour le mentorat :
- avoir les compétences sur un plan technique ;
- être capable d’expliquer des choses à quelqu’un d’autre ;
- savoir combien d’aide donner à la personne encadrée.
Le dernier point est important parce que, si vous donnez trop d’informations, la personne peut vous ignorer plutôt que de vous dire gentiment qu’elle a compris (Fitzpatrick & Collins-Sussman, 2012). En plus, donner un faible niveau d’orientation à une personne ayant déjà de l’expérience est plus efficace que de donner une orientation explicite (Chen, Kalyuga, & Sweller, 2017 ; Oakley & Sejnowski, 2021). Un bon(ne) mentor(e) doit pouvoir estimer le niveau de la personne et lui donner une orientation appropriée, ce qui n’est pas toujours facile. Mais sachez que « moins est plus » dans certains cas.
12.4 Scénarios
Considérez les volets HRC lorsque vous vous trouvez dans une des situations suivantes :
- Une personne à l’équipe se trouve à être la seule à faire de la programmation.
- Elle ne fait plus confiance aux autres membres de l’équipe, car leur code est trop bogué.
- Elle n’a pas la patience pour accommoder les membres de l’équipe avec moins d’expérience.
- Elle croit que les autres auraient dû apprendre à mieux programmer dans les cours préalables.
- Une personne dans l’équipe dit qu’elle a « fait ses trois heures de contribution » chaque dimanche chez elle et que ça devrait suffire pour sa partie (elle a un emploi et n’a pas beaucoup de temps pour l’équipe du projet universitaire).
- Un ou deux membres d’une équipe abandonnent le cours après les évaluations de mi-trimestre, par crainte d’échec.
- Un membre de l’équipe suit cinq (!) cours en même temps et n’a pas le temps suffisant pour travailler correctement dans les laboratoires de cette matière.
- Plusieurs membres de l’équipe ont de l’expérience, mais ont de la difficulté à s’entendre sur l’orientation du projet.
- L’équipe n’est pas cohésive : chaque membre fait avancer sa partie, mais le code ne fonctionne pas ensemble.
Vous devez en parler avec votre équipe. Si la situation ne s’améliore pas, vous devez en parler avec une personne ressource, comme votre superviseur(e) (en stage), les auxiliaires de laboratoire ou l’enseignant(e).
Des conseils pour mieux évaluer le travail de chacun(e) dans l’équipe au laboratoire sont présentés dans la section Évaluer les contributions des membres de l’équipe.