Programmation en binôme

Planification

Les développeurs sont capables de travailler en binôme sur un même poste de travail : pendant que l’un code, l’autre fait la revue de code pour une correction au plus tôt

Planification

Qu'est-ce que la programmation en binôme ?

La programmation en binôme (PP) est peut-être la pratique de codage la plus connue qui a émergé entre 1996 [Wells 2013] et 1999 du cadre agile Extreme Programming (XP) de Kent Beck [Beck 2004], bien que cette pratique ait déjà été signalée en 1995 [Nosek 1998] et également en tant que modèle organisationnel [Coplien 1995].

Elle consiste à faire travailler deux personnes sur le même poste de travail. Elles [Beck 2004] :

  • "Gardez les autres sur la tâche"
  • "Brainstorming sur les améliorations à apporter au système"
  • "Clarifier les idées"
  • "Prendre l'initiative lorsque leur partenaire est bloqué, ce qui réduit la frustration".
  • "Se tenir mutuellement responsables des pratiques de l'équipe".

Généralement, deux rôles émergent [Kniberg 2015] :

  • le pilote/driver: c'est celui qui tient le clavier
  • le copilote/navigateur : il s'agit de la personne qui assiste le pilote, examine le code, tente de remettre en question ce qui est fait afin que l'artefact généré soit le meilleur possible et réfléchit stratégiquement aux implications de la conception [Williams 2000].

Les rôles sont régulièrement échangés afin d'obtenir une appropriation collective [Kniberg 2015]. Le PP immature ressemble à "J'ai une idée, donne-moi le clavier", tandis que le PP mature est plutôt "J'ai une idée, prends le clavier". Il existe plusieurs recommandations liées au PP [Llewellyn 2014], mais la plus importante concerne les égos forts avec un état d'esprit "àma façon ou pas" qu'il faut éviter [Williams 2000].

Le PP fonctionne mieux si les personnes se connaissent et il est fortement recommandé de séparer les paires qui ne correspondent pas [Naresh 2018]. Le PP avec deux débutants devrait également être évité [McConnell 2004].

Il existe de nombreux avantages à travailler en PP [Williams 2000] [Vanhanen 2007] :

  • elle réduit la probabilité de produire une mauvaise conception [Flor 1991].
  • il élimine les défauts à la volée, comme le propose l'approche Kaizen.
  • il est également utile pour le partage des connaissances et la formation en mode pratique.
  • il aide les gens à faire face à des tâches difficiles 
  • il améliore la satisfaction professionnelle et la confiance globale dans leur travail

En ce qui concerne la productivité, il apparaît que les paires passent 10 à 60 % plus de temps sur les tâches que séparément, tout en terminant la tâche 40 à 45 % plus vite que les groupes de contrôle, et en produisant de meilleurs algorithmes et codes [Nosek 1998] [Shull 2002].

La résolution des problèmes à la volée est également bénéfique pour le rendement du premier passage et est beaucoup plus rentable, car la résolution des problèmes après coup augmenterait les coûts de résolution de 15 à 60 % [Williams 2000].

D'autres études révèlent que [McConnell 2004] [Moustier 2019-1] :

  • 1 heure de PP permet d'éviter 33 à 100 heures de maintenance et de reprises.
  • 40 % de retouches en moins pour 20 % consacrés au PP
  • Hewlett-Packard aurait économisé 21,5 millions de dollars avec le PP.

Par conséquent, les heures de travail des programmeurs ne doublent pas avec la programmation en binôme et les résultats sont plus rapides et de meilleure qualité [Williams 2000].

Impact de la programmation en binôme sur la maturité des tests

Les testeurs devraient collaborer avec les développeurs qui écrivent le code de test. Même si le testeur ne sait pas coder, le développeur gardera le clavier et parlera du test en cours de codage pour permettre au testeur d'améliorer les idées de test sous-jacentes [Kniberg 2015].

Lorsqu'il s'agit de TDD, il semble que la programmation en binôme soutienne fortement le TDD puisque 

  • la révision du code à la volée garantit que les tests sont de haute qualité [Parsons 2011].
  • puisque le TDD est une question de conception, le PP renforce une conception solide.
  • La TDD peut également être utilisée pour transformer la PP en "programmation ping-pong" [Hoover 2005] :

          1. Le développeur A écrit un test unitaire (UT) qui doit échouer ("Rouge") et remet le clavier au développeur B.

           2. Le développeur B essaie de rendre l'UT "verte" et finit par remanier le code.

           3. Le développeur B ajoute un nouvel UT qui devrait être "Red" et rend le clavier au développeur A.

La programmation en binôme peut être utilisée pour tout type d'activité, y compris les tests. Par exemple, l'atelier "3 Amigos" est en fait une session de PP avec un développeur et un testeur autour d'une histoire d'utilisateur. Test Oracle qui fournit des réponses aux questions du développeur et du testeur. Faire du Pair-Testing aboutira à [McConnell 2004] [Vanhanen 2007] [Moustier 2019-1] :

  • fausses notes
  • plus grande concentration 
  • Les tests en mode PP sont 20 fois plus efficaces que les tests fonctionnels traditionnels.
  • PP diviserait le nombre de bugs restant dans le code par 5

Le point de vue d'Agilitest sur la programmation en binôme

Appliquer PP dans la création de scripts avec Agilitest semble évident, au moins sur les scripts à automatiser qui sont censés durer. Tirer profit des avantages connus de PP est quelque chose de vraiment intéressant à essayer, surtout lorsque le Testeur fait équipe avec le Développeur de les US. Cela conduit à des améliorations à la fois dans les scripts et le code de production notamment en termes de

  • scénario de test - achèvement concernant ce que le développeur et le testeur ont compris. les USLa fonctionnalité implémentée devrait converger plus sûrement vers ce qui est réellement attendu.
  • méthode de récupération des widgets - le dispositif peut adapter la création de widgets pour accélérer et consolider la reconnaissance des widgets
  • Puisque le PP permet l'apprentissage, il conduit à des personnes T-Shape et permet également l'automatisation des tests.
  • tout autre besoin de testabilité peut être rapidement pris en compte par le Dev pour faciliter le Jidoka
  • Grâce à cette collaboration, l'automatisation des scripts peut se faire en mode juste-à-temps et aboutir à des écocycles synchronisés de développement et d'automatisation des tests.

Pour découvrir l'ensemble des pratiques, cliquez ici.

Pour aller plus loin

  • [Beck 2004] : Kent Beck & Cynthia Andres - feb 2004 - "Extreme Programming Explained : Embrasser le changement" - ISBN : 9780321278654
  • [Coplien 1995] : J.O. Coplien, "A Development Process Generative Pattern Language," Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, Reading, Mass, 1995, pp. 183-237.
  • [Flor 1991] : N.V. Flor et E.L. Hutchins, " Analyzing Distributed Cognition in Software Teams : A Case Study of Team Programming during Perfective Software Maintenance" - Proc. Empirical Studies of Programmers : Fourth Workshop, Ablex Publishing, New York, 1991, pp. 36-64.
  • [McConnell 2004] : Steve McConnell - " Code Complete - un manuel pratique de construction de logiciels " - Microsoft Presse - 2004 - ISBN 0-7356-1967-0
  • [Moustier 2019-1] : Christophe Moustier - JUIN 2019 - " Le test en mode agile " - ISBN 978-2-409-01943-2
  • [Shull 2002] : Shull, et al. - " What We Have Learned About Fighting Defects " - Proceedings, Metrics - 2002- IEEE ; 249-258
© Christophe Moustier - 2021