Programmation en binôme
La programmation en binôme (de l'anglais pair programming), parfois appelée programmation par pairs ou binômage, est une méthode de travail dans laquelle deux développeurs travaillent ensemble sur un même poste de travail. La personne qui rédige le code est appelée conducteur (driver). La seconde personne, appelée observateur (observer), assiste le conducteur en décelant les imperfections, en vérifiant que le code implémente correctement le design et en suggérant des alternatives de développement. Les rôles s'échangent régulièrement pendant la séance de programmation[1]. La programmation en binôme fait partie des bonnes pratiques de l'extreme programming.
Bénéfices
[modifier | modifier le code]
Qualité et productivité
[modifier | modifier le code]Un des freins à l'adoption de la programmation en binôme en entreprise est l'idée que deux personnes travaillant sur un même projet constituent un gaspillage de ressources humaines[2]. Plusieurs études se sont intéressées à la productivité relative des binômes face aux programmeurs seuls[3]. Pour éviter l’ambiguïté entre temps passé et temps total par programmeur, Kim Man Lui (en) définit une mesure de l'effort relatif consenti par un binôme (de l'anglais relative effort afforded by pairs, abrégé en REAP) de la façon suivante[3] : où représente le temps passé par un binôme et le temps passé par un programmeur seul.
Équation en français: où représente le temps passé par un binôme et le temps passé par un programmeur seul.
Une valeur nulle de REAP indique qu'un binôme utilise exactement la moitié du temps nécessaire à un programmeur seul pour réaliser la même tâche. Une valeur de REAP comprise entre 0 et 100 % indique qu'un binôme réalise une tâche plus rapidement mais nécessite davantage d'heures-hommes. Une première étude réalisée en 1998 rapporte une valeur de 59,4 %[4]. Une autre étude complète ces résultats en indiquant qu'après une période d'ajustement, ce taux descend à 15 %[5]. La programmation en binôme est donc particulièrement utile lorsqu'il est nécessaire de réduire le délai de mise sur le marché d'un logiciel.[réf. nécessaire]
La programmation en binôme permet également une détection plus rapide des bugs, notamment par l'application continue de la revue de code par l'observateur[6]. De manière générale, un binôme conçoit des applications de meilleure qualité qu'un programmeur seul[7]. Cette différence s'explique par la nécessité pour un binôme de s'accorder au préalable sur la conception de l'application à produire en proposant un raisonnement justifié[8]. La programmation en binôme amène alors à des applications passant davantage de tests[9] et ayant des fonctionnalités implémentées avec moins de lignes de code[10].
Économiquement, le surcoût en personnel induit par la programmation en binôme est compensé par la hausse de qualité de l'application produite. Plus un défaut est décelé tard et plus il est coûteux de le corriger. Ainsi, la correction tardive des défauts supplémentaires d'une application développée par un programmeur seul est quinze à soixante fois plus coûteuse[Pas dans la source][11].
Communication
[modifier | modifier le code]La programmation en binôme est une activité sociale qui nécessite d'apprendre à travailler avec les autres. Elle favorise ainsi la communication au sein d'une équipe en encourageant les développeurs à parler entre eux[12]. En outre, elle permet d'améliorer les compétences communicationnelles qui sont généralement peu travaillées pendant l'apprentissage de l'informatique. Cette pratique a également pour effet de renforcer les liens entre les développeurs et de créer un esprit d'équipe[13].
De plus, la programmation en binôme améliore le plaisir des programmeurs et la confiance dans leur travail. De nombreux sondages attestent que plus de 90 % des développeurs préfèrent programmer en binôme plutôt que seuls[14].
Apprentissage
[modifier | modifier le code]Milieu universitaire
[modifier | modifier le code]L’utilisation de la programmation en binôme appliquée dans le milieu universitaire permet une amélioration globale des notes des étudiants les plus faibles[15], sans pour autant diminuer les notes des plus forts[16] ; de plus, il permet une meilleure intégration des femmes et des minorités au sein des cursus informatiques[17].
La mise en place de binômes au sein d'un cours à l'université améliore également la qualité du travail effectué. De plus, le travail en binôme permet un échange plus aisé entre les étudiants[18], mais également avec le professeur[19], voire de réduire les différences pédagogiques entre les professeurs[20].
En entreprise
[modifier | modifier le code]Au sein d'une entreprise, le développement en binôme encourage un transfert de connaissances techniques entre les membres de l'équipe, notamment lorsqu'un développeur considéré comme novice travaille avec un expert. Le novice peut non seulement apprendre de nouvelles technologies grâce à l'expert, mais aussi apprendre de bonnes pratiques ou découvrir de nouveaux logiciels utiles au développement[21].
Indicateurs de non-performance
[modifier | modifier le code]La plupart des développeurs sont conditionnés pour travailler seul et l'adoption de la programmation en binôme est parfois délicate. Si la transition s'effectue généralement avec succès[22], il existe quelques indicateurs qu'un binôme ne fonctionne pas :
- Silence : la programmation en binôme nécessite de programmer à voix haute et de partager son point de vue avec son partenaire. Un silence persistant indique un manque de collaboration.
- Désengagement : un des membres se désintéresse du projet et vaque à ses occupations.
- Effacement : lorsqu'un membre est plus expérimenté qu'un autre, le novice se contente d'observer l'expert réaliser la majorité des tâches de développement[23].
- Problèmes relationnels : les deux membres du binôme ne s'entendent pas et ne souhaitent pas travailler ensemble[24].
Programmation à distance
[modifier | modifier le code]La programmation en binôme peut également être établie à distance[25]. Dans ce cas, des outils dédiés au travail collaboratif sont souvent mis en place, en vue notamment de partager l’affichage (Mikogo) ou le code source (XPairtise[26], Saros[27], Cloud9), de communiquer à distance (Skype), ou encore d'exécuter des instructions sur une machine distante (SSH)[28].
La communication au sein du binôme peut être perturbée par plusieurs éléments. Différents problèmes techniques tels qu'une coupure réseau ou des messages d’erreur dans un logiciel peuvent faire perdre du temps au binôme[25]. De plus, le manque de communication non verbale rend parfois l'échange plus difficile. Cependant, des outils de dessin, la sélection de code ou le curseur peuvent compenser ces problèmes de communication[28]. Enfin, on note également certains avantages, comme les modifications mineures de code sans perturber le binôme[29].
La programmation en binôme à distance modifie les rôles définis par la programmation en binôme classique. En effet, avoir deux écrans affichant le même code source rend l’observateur souvent plus actif. Deux situations peuvent être constatées :
- soit les membres du binôme continuent à travailler ensemble sur la même tâche, auquel cas le rôle de l’observateur est conservé, celui-ci se contentant de modifications mineures du code ;
- soit chaque membre travaille sur une tâche différente. Dans ce cas, le travail commence par une phase de discussion avant une phase de développement en solo[30].
Articles connexes
[modifier | modifier le code]- La programmation en groupe qui est une extension à toute une équipe de la programmation en binôme[31].
Références
[modifier | modifier le code]- McDowell et al. 2003, p. 1
- Cockburn et Williams 2000, p. 1
- Lui et Chan 2006, p. 2
- Nosek 1998, p. 2
- Williams et al. 2000, p. 4
- Cockburn et Williams 2000, p. 6
- Dybå et al. 2007, p. 4
- Li et Kraemer 2014, p. 4
- Williams et al. 2000, p. 5
- Cockburn et Williams 2000, p. 5
- Cockburn et Williams 2000, p. 4
- Zarb 2012, p. 1
- Ally, Darroch et Toleman 2005, p. 3
- Williams et al. 2000, p. 6
- McDowell et al. 2003, p. 3
- Braught, Wahls et Eby 2011, p. 17
- Braught, Wahls et Eby 2011, p. 2
- Zarb, Hughes et Richards 2014, p. 4
- Radermacher, Walia et Rummelt 2012, p. 1
- Braught, Eby et Wahls 2008, p. 5
- Cockburn et Williams 2000, p. 7
- Williams et Kessler 2000, p. 2
- (en) « Agile Pair Programming » [archive du ] (consulté le )
- (en) « Guide to Agile Practices » (consulté le )
- Schenk, Prechelt et Salinger 2014, p. 2
- (en) « XPairtise - A Distributed Pair Programming Plug-in For Eclipse » (consulté le )
- (en) « Real-Time Distributed Software Development » (consulté le )
- « Pair-programmer à distance facilement », (consulté le )
- Schenk, Prechelt et Salinger 2014, p. 7
- Schenk, Prechelt et Salinger 2014, p. 6
- (en-US) « What is Mob Programming? | Agile Alliance », (consulté le )
Bibliographie
[modifier | modifier le code]- (en) Charlie McDowell, Linda Werner, Heather E. Bullock et Julian Fernald, « The Impact of Pair Programming on Student Performance, Perception and Persistence », Proceedings of the 25th International Conference on Software Engineering, , p. 602-607 (DOI 10.1109/ICSE.2003.1201243, lire en ligne [PDF], consulté le )
- (en) Alistair Cockburn et Laurie Williams, « The Costs and Benefits of Pair Programming », Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000), vol. 43, no 5, (lire en ligne [PDF], consulté le )
- (en) Kim Man Lui et Keith C.C. Chan, « Pair programming productivity: Novice–novice vs. expert–expert », International Journal of Human–Computer Studies, vol. 64, no 9, (DOI 10.1016/j.ijhcs.2006.04.010, lire en ligne [PDF], consulté le )
- (en) John T. Nosek, « The case for collaborative programming », Communications of the ACM, vol. 41, no 3, (DOI 10.1145/272287.272333)
- (en) Tore Dybå, Erik Arisholm, Dag I.K. Sjøberg, Jo E. Hannay et Forrest Shull, « Are Two Heads Better than One? On the Effectiveness of Pair Programming », IEEE Software, vol. 24, no 6, (DOI 10.1109/MS.2007.158)
- (en) Zhen Li et Eileen Kraemer, « Social effects of pair programming mitigate impact of bounded rationality », Proceedings of the 45th ACM technical symposium on Computer science education, (DOI 10.1145/2538862.2538968)
- (en) Mark Zarb, « Understanding communication within pair programming », Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity, (DOI 10.1145/2384716.2384738)
- (en) Mustafa Ally, Fiona Darroch et Mark Toleman, « A framework for understanding the factors influencing pair programming success », Proceedings of the 6th international conference on Extreme Programming and Agile Processes in Software Engineering, (DOI 10.1007/11499053_10, lire en ligne [PDF], consulté le )
- (en) Laurie Williams, Robert R. Kessler, Ward Cunningham et Ron Jeffries, « Strengthening the Case for Pair Programming », IEEE Software, vol. 17, no 4, (DOI 10.1109/52.854064, lire en ligne [PDF], consulté le )
- (en) Grant Braught, Tim Wahls et L. Marlin Eby, « The Case for Pair Programming in the Computer Science Classroom », Transactions on Computing Education, vol. 11, no 1, (résumé)
- (en) Mark Zarb, Janet Hughes et John Richards, « Evaluating industry-inspired pair programming communication guidelines with undergraduate students », Proceedings of the 45th ACM technical symposium on Computer science education, (DOI 10.1145/2538862.2538980)
- (en) Alex Radermacher, Gursimran Walia et Richard Rummelt, « Improving student learning outcomes with pair programming », Proceedings of the ninth annual international conference on International computing education research, (DOI 10.1145/2361276.2361294)
- (en) Grant Braught, L. Marlin Eby et Tim Wahls, « The Effects of Pair-Programming on Individual Programming Skill », Proceedings of the 39th SIGCSE technical symposium on Computer science education, vol. 40, no 1, (DOI 10.1145/1352322.1352207)
- (en) Laurie A. Williams et Robert R. Kessler, « All I really need to know about pair programming I learned in kindergarten », Communications of the ACM, vol. 43, no 5, (DOI 10.1145/332833.332848, lire en ligne [PDF], consulté le )
- (en) Julia Schenk, Lutz Prechelt et Stephan Salinger, « Distributed-pair programming can work well and is not just distributed pair-programming », Companion Proceedings of the 36th International Conference on Software Engineering, (DOI 10.1145/2591062.2591188, lire en ligne [PDF], consulté le )
