Pair, Solo, Mob, quelles sont les différences ?

Introduction

Le postulat est aujourd’hui très clair. Si la majorité des développeurs ont jusqu’alors appris à développer seul face à leur clavier, l’émergence des principes du « clean code » et l’obligation d’adaptabilité du développeur face aux nouveaux outils ont favorisé l’apparition des techniques de Pair et de Mob Programming. Cet article met en comparaison les trois techniques de programmation en déterminant comment utiliser leurs atouts à leur maximum et exceller dans chacune de ces méthodologies.

Bon nombre d’entre vous ont déjà connu l’expérience de coder seul un programme. Pour les autres qui ont eu la chance de monter en compétences via le pair programming ou le mob programming, il peut être compliqué d’appréhender et d’adopter la confiance nécessaire en ses connaissances pour se lancer seul sur un projet de programmation.

Pourtant, le solo programming possède de nombreux atouts. Le premier étant le fait de contrôler à 100% l’avancée et les différents aspects techniques de votre programmation. Ainsi, vous devez être à même de développer votre autonomie à travers de nombreux objectifs tels que l’organisation du projet, le choix des outils qui vous seront nécessaires et surtout votre méthode de travail.

Par ailleurs, cela vous permet de développer un profil « full-stack » puisqu’il vous faudra répondre tant au problématique Front que Back. Le développement en solo possède un aspect éducatif puisqu’il se base sur une méthode de try/fail qui permet de donner un sens concret et surtout personnel à votre programmation.

💡Être full stack signifie dans la plupart des cas que vous ne serez excellent ni sur les problématiques « back-end » ni sur «celles « front-end » mais que vous développerez un niveau « intermédiaire » sur les deux.

Nos conseils pour un solo programmer

Mais alors, comment bien programmer en solo ? Je vais vous donner une liste d’étapes à suivre lorsque vous décidez de vous lancer dans cette entreprise en solo :

Bien choisir votre langage informatique. Quitte à tout gérer, le langage en C++ ou C# vous permet de tout contrôler puisque la majorité des interpréteurs de langage sont, de base, en C. Si votre projet est « lourd », il sera intéressant d’utiliser un langage de bas niveau tandis que si vous vous portez vers un projet demandant ‘seulement’ une automatisation, portez-vous plutôt vers les langages dits de haut-niveau.

Choisir le bon framework. Pour la partie Front-End, cela peut simplement dépendre de votre préférence entre Google (Angular) ou Facebook (React) entre les deux mastodontes ou, si aucun de ceux là ne convient, vous pouvez tout à fait vous orienter vers Vue.js. Pour la partie Back-End, le langage n’aura que peu d’importance tandis que la taille et la gestion de votre base de données aura une incidence très importante. Aussi, posez-vous la question de savoir si vous souhaitez un schéma strict qui ne bougera pas (base de données relationnelle), de la gestion Big Data (NoSQL). Ensuite, à vous de choisir entre Oracle et Microsoft (Oracle, MsQL).

Accordez-vous du temps pour apprendre. Le solo programming a un défaut, il ne permet pas le transfert de compétences entre développeurs et il vous sera donc important d’accroître vos connaissances en autodidacte.

Ne vous faites pas trop confiance! Les phases tests doivent être une routine et survenir après chaque implémentation d’un nouvel élément afin d’en vérifier l’intérêt et que la fonctionnalité qui lui est rattachée soit fonctionnelle.

Déployer votre programme en corrigeant les bugs détectés durant les phases tests et en automatisant au maximum la détection des erreurs récurrentes de votre dû. Cela vous permettra entre autres d’améliorer la qualité de votre code et de le rendre lisible pour ceux qui – il faut y penser – vous succéderont sur ce poste.

Créer une documentation conséquente sur chaque test déployé, chaque fonctionnalité implémentée et surtout sur l’évolution de vos différentes phases test et comment vous avez su régler les problèmes. En plus de vous aider à vous y retrouver, cela permettra à votre employeur de garder confiance en votre travail et à vos successeurs de facilement pouvoir nettoyer votre code ou implémenter de nouvelles fonctionnalités lorsqu’il sera temps de le faire évoluer.

Conclusion sur le Solo programming

En somme, le solo programming vous apportera une formation en autodidacte ainsi qu’un grand sentiment de satisfaction personnelle lors du déploiement final de votre projet. Cependant, il possède aussi de gros désavantages puisqu’il implique une durée de développement du programme longue et donc coûteuse pour l’employeur. Un même projet pouvant prendre plusieurs années, le solo programmer peut vite devenir las et choisir de s’en aller.

Toutes ces fautes peuvent apparaître lors de la restitution du projet à un autre développeur et si, par malheur, la documentation est mauvaise ou inexistante, il y a forte à parier que la période que passera le prochain développeur à nettoyer et refactorer le code soit elle aussi chronophage, décourageante et coûteuse. 

En revanche, sur des projets courts, le Solo Programming peut être une solution très efficace si tant est que la communication entre le Product Owner (PO) et la partie technique (développeur) soit suffisante lors des différentes étapes : brief, user-stories, conception, tests, déploiement, retours client.

Le Pair programming

introduction au pair programming​

Le Pair programming est, contrairement au solo programming, une méthode de travail qui met en exergue l’importance de la communication et de l’entraide. Cette technique permet en effet d’accroître directement et quotidiennement ses compétences grâce au transfert de connaissances entre les deux développeurs travaillant conjointement.  

En revanche, tout comme le Mob programming, il fait partie d’un ensemble de méthodes collaboratives parmi lesquelles : la collaboration asynchrone, la collaboration synchrone, le brainstorming qui sont plus des outils de travail que de véritables méthodologies.

Comment bien réalisé son programme en pair programming​​

La première notion à intégrer avant de débuter en Pair Programming est de savoir si vous êtes apte à travailler en binôme durant un laps de temps qui peut atteindre plusieurs mois voire année. Une fois la prise de connaissance faite, l’esprit autocritique et la confiance entre les deux dev est plus que nécessaire puisque, à force d’échanger les rôles, ils doivent être à même de comprendre et lire le code du partenaire.

Les cycles de changement de rôles entre l’observer et le driver doivent ainsi être respectés afin que chacun y trouve son compte. Pareillement, aucun sentiment d’infériorité ne doit émerger au sein du binôme afin que chacun puisse apporter sa pierre à l’édifice et se sentir en mesure de demander une explication sur telle implémentation, telle résolution de problème ou sur la documentation à produire.

L’excellent Peter Kofler a institué comme doctrine du Pair Programming l’agglomérat de notions d’unité au sein du binôme avec : « Two Programmers work together on the same thing at one workstation. »

Comment on pratique le pair programming ?​

Si la communication est la pierre angulaire de la réussite d’un méthode en Pair Programming, il faut tout de même respecter certains points clés. Ainsi, les deux développeurs se séparent les rôles. Ils deviennent tour à tour driver (conducteur) puis observer (observateur).

Le premier manie le clavier en rédigeant le code tandis que le second a une tâche de guetteur (problèmes) et de conseiller. Les échanges de postes doivent être fait de manière régulière.

💡 Il est tout à fait possible d’effectuer du pair programming à distance en utilisant des outils comme Skype pour la communication et Saros ou Cloud9 pour le partage du code source.

Quelles différences et quelles ressemblances avec le solo programming ?

Comparons maintenant le pair programming au solo programming en détails. Là où le premier cité permet un transfert de compétence entre les deux acteurs techniques du projet, le Solo Programming oblige à une formation en autodidacte qui peut être tout aussi formatrice mais bien plus chronophage et moins ‘fun’.

En parlant de chronophage, le Pair Programming a aussi cet avantage de ne pas vous laisser l’opportunité de gaspiller votre temps sur des sites tiers (Facebook, Twitter, news, etc.) puisque vous travaillez sur le même ordinateur que votre collègue. Ce temps gagné est mis à contribution lorsque, comme dans tout travail de groupe, aucun des deux développeurs n’a la solution et doit donc se confronter à un véritable brainstorming d’idées et de questionnements.

Mais quoi de mieux qu’une émulsion commune pour trouver une solution ? Lorsqu’un programmer solo met parfois des heures, des jours, à trouver une solution, le Pair Programming permet une rapidité d’action par la stimulation bipartite. 

Vous l’aurez compris, le Pair Programming permet une meilleure efficience surtout un grand gain de temps et donc de coûts sur un projet. Notons tout de même que le fait d’être deux sur un même écran peut aussi instituer dans l’esprit du chef de projet que le coût en ressources humaines est trop élevé.

Soulignons aussi le fait qu’un binôme peut tout à fait se séparer de temps en temps afin de laisser une liberté à l’un ou l’autre des développeurs. Cependant, cette particularité est étroitement liée à la relation de confiance et la mise en place d’outils communs de communication entre les deux développeurs. En dehors des aspects dialogues et communication, il existe une véritable valeur de partage qui se créée grâce au fait de pair programmer. 

Ce partage permet aussi de casser les différences de niveau entre un profil de développeur junior et un véritable expert en faisant apparaître de nouveaux standards de travail et révélant parfois des talents cachés. Valeur qui trouvera sa finalité ultime dans l’atmosphère de travail, au moins aussi importante que les outils mis à disposition.

En termes de matériel, le pair programming est également plus coûteux que le Solo Programming puisque le binôme effectue tout sur un seul et même écran, un seul et même clavier, avec une seule et même souris.

Le Mob programming

Introduction au mob programming​

Puisque le pair programming est peu à peu rentré dans les mœurs des équipes techniques, pourquoi ne pas pousser plus loin et intégrer la totalité d’une équipe sur un seul outil ? C’est chose faite avec l’émergence d’une nouvelle méthode de travail baptisée Mob Programming.

Vulgarisée et structurée pour la première fois par au début des années 2010 par Roy Zuill (alias Woody Zuill), la méthode du Mob Programming est, en principe, une vision élargie du Pair Programming.

Comment pratiquer le mob programming ?​

Peu utilisé de manière générale, nous nous basons sur les dires de Woody afin d’expliciter la meilleure façon de pratiquer le Mob Programming. D’après lui, 5 étapes sont nécessaires au bon déroulement de la programmation en mob programming.

• Adapter une zone de travail assez large.
  Les équipes pouvant aller jusqu’à une trentaine de développeurs, assurez-vous d’avoir choisi un espace de travail assez important afin que chacun puisse avoir son siège et son espace vital minimum afin d’effectuer la programmation dans un espace sain. Par ailleurs, tout le monde doit avoir une visibilité parfaite sur les écrans mis à disposition du groupe.
• Disposer d’un outillage informatique et visuel suffisant.
  Si le fait d’avoir une chaise par personne est essentiel, la qualité du matériel informatique l’est tout autant. Comme chacun doit avoir un bon visuel sur la programmation en cours, il est conseillé de relier, à minima, deux vidéoprojecteurs à l’ordinateur central sur lequel le driver effectue la programmation en direct. Si un seul ordinateur est utilisé pour le code, chacun des participants doit posséder son écran afin de pouvoir travailler à une solution parallèlement au navigateur et ainsi avancer de façon rapide et effective. Enfin, l’hygiène est un principe important lorsqu’on travaille sur un seul outil. Aussi, plusieurs claviers, plusieurs souris doivent être à disposition des développeurs n’étant pas à l’aise avec le partage de matériel.
• Adopter des rotations itératives sur le style du Pair Programming.
  De manière semblable au Pair Programming, le driver se doit d’interchanger son rôle avec les observers de façon régulière et en suivant des cycles courts (environ 15 à 20 minutes). Ainsi, tandis que le conducteur est le cerveau du groupe et est capable d’assimiler une grande dose de données, les observateurs sont ses yeux et détectent les erreurs que ce premier peut faire.
• Adopter une position de groupe face à toutes les composantes d’un projet.
  Une relation de confiance dans un groupe passe par la passation d’informations de toutes les parties prenantes du projet. Aussi, lorsque le groupe reçoit un mail ou un coup de fil, il est de bon ton d’adopter une attitude transparente en faisant la rédaction à haute voix du mail et en mettant le téléphone en haut-parleur.

Conclusion

Tandis que l’individu représente le groupe technique en Solo Programming, il n’est qu’une entité parmi d’autres en Mob Programming. Il faut donc comprendre qu’aucune de ces méthodologies de travail n’est plus mauvaise qu’une autre mais qu’elles ne font que répondre à des critères de capacité des développeurs et surtout de la scalabilité du projet.

Le point fort des techniques de Pair Programming et de Mob Programming est qu’elles sont des méthodologies à même de produire un code d’excellente qualité. Si l’écosystème de travail en Mob Programming n’est pas facile à adopter pour certains, c’est avant tout au(x) porteur(s) de projet de déterminer ce qui convient le mieux pour répondre aux objectifs.

Il ne faut pas non plus mettre de côté la difficulté à construire un groupe de travail avec des capacités sociales et surtout technique permettant d’avancer d’un seul pas. Et, si la montée en compétence est l’un des atouts du Pair et du Mob Programming, elle est le talon d’Achille du solo developper.

Dans le sens inverse, dès lors qu’un collectif de développeur se rompt pour quelques raisons que ce soit, il met en danger tout le processus de programmation Chose impossible chez le développeur qui travaille seul et qui a pu, dès le début du projet, choisir ses outils et son mode de fonctionnement.

En somme, il est important de prendre en compte tous les facteurs avant de décider de se lancer sur telle ou telle méthode de travail et surtout aviser avant tout début de projet que les outils choisis, l’atmosphère de travail, la communication interne et externe seront bien pris en compte avant, pendant et à la fin du processus.