Code review et pair programming : 2 méthodes essentielles pour maximiser le travail en équipe
Lorsqu’on souhaite donner davantage de responsabilités à une équipe, on a tendance à augmenter son effectif. L’hypothèse sous-jacente est que si une équipe passe de 2 à 4 membres, elle sera 2 fois plus rapide dans le delivery (livraison). Or plus une équipe est grande, plus ses membres doivent s’accorder entre eux pour avancer de manière coordonnée et efficace. On peut alors utiliser 2 méthodes clés du travail en équipe : le code review et le pair programming.
Le code review
Le code review consiste à vérifier le code qu’a délivré un membre de l’équipe. Il est effectué par toute l’équipe à l’exception de celui qui a réalisé la tâche. Il doit être fait avant la mise en production.
Il y a 2 intérêts à rendre systématique le code review :
Cela permet de déceler les erreurs commises par le développeur dès la fin de son développement et avant la mise en production. A chaque retour effectué par ceux qui review la tâche, le développeur va mettre en place les correctifs associés. Un ou plusieurs aller-retours vont alors se produire entre l’étape “en cours” de la tâche et l’étape “code review”, ceci autant de fois qu’il faudra pour que le code soit correct sur tous les aspects (respect des spécifications, clean code…). On s’assure ainsi de mettre en production un code qui a été validé par l’équipe : on livre en équipe.
Cela favorise également le fait que toute l’équipe ait un même niveau de connaissances sur les sujets. En effet, pour reviewer une tâche, il faut bien comprendre le cahier des charges et comprendre techniquement comment on y a répondu. Ça demande de rentrer dans le code si l’on veut faire un code review de qualité.
Le pair programming
Le pair programming consiste à travailler en binôme sur une même tâche. J’ai l’habitude de l’utiliser dans 2 situations :
Lorsqu’il y a un nouvel arrivé dans l’équipe qui est en phase d’onboarding. Dans ce cas, le pair programming va permettre une meilleure montée en compétence de la personne. En général, sur les premières tâches, je partage mon écran (si on est en télétravail) lorsque je code et explique ce que je fais. Le nouvel arrivant suit la réalisation de la tâche avec moi et pose des questions. Dans une phase plus avancée, on inverse les rôles et c’est à la jeune recrue de partager son écran et de coder alors que je suis en back-up.
Lorsque la tâche à réaliser est complexe ou délicate. Si elle est complexe, brainstormer et challenger les idées sera utile pour en venir à bout. Si elle est délicate, elle requiert plusieurs pairs d’yeux pour éviter les erreurs.
Outre ces 2 cas, je recommande de faire du pair programming régulièrement car à l’instar du code review, l’équipe aura le même degré de connaissances.
Le code review et le pair programming sont des outils indispensables à la croissance d’une équipe. Ils devraient être davantage démocratisés.
Laquelle de ces 2 méthodes serait la plus bénéfique pour ton équipe ?