« Utilisateur:Jeremy.bossut/Brouillon » : différence entre les versions
| Ligne 103 : | Ligne 103 : | ||
| consulté le = 9 décembre 2014 |
| consulté le = 9 décembre 2014 |
||
}} |
}} |
||
</ref>. Par ailleurs, cette pratique améliore les compétences communicationnelles |
</ref>. Par ailleurs, cette pratique améliore les compétences communicationnelles<ref name="Framework"> |
||
{{Article |
|||
| langue = en |
|||
| auteur1 = Mustafa Ally |
|||
| auteur2 = Fiona Darroch |
|||
| auteur3 = Mark Toleman |
|||
| titre = A framework for understanding the factors influencing pair programming success |
|||
| périodique = Proceedings of the 6th international conference on Extreme Programming and Agile Processes in Software Engineering |
|||
| année = 2005 |
|||
| lire en ligne = http://core.kmi.open.ac.uk/download/pdf/11034646.pdf |
|||
| consulté le = 9 décembre 2014 |
|||
| format = pdf |
|||
}} |
|||
</ref>. |
|||
* '''Satisfaction:''' 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<ref name="Strengthening"> |
* '''Satisfaction:''' 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<ref name="Strengthening"> |
||
Version du 9 décembre 2014 à 12:39
- → N'hésitez pas à publier sur le brouillon un texte inachevé et à le modifier autant que vous le souhaitez.
- → Pour enregistrer vos modifications au brouillon, il est nécessaire de cliquer sur le bouton bleu : « Publier les modifications ». Il n'y a pas d'enregistrement automatique.
Si votre but est de publier un nouvel article, votre brouillon doit respecter les points suivants :
- Respectez le droit d'auteur en créant un texte spécialement pour Wikipédia en français (pas de copier-coller venu d'ailleurs).
- Indiquez les éléments démontrant la notoriété du sujet (aide).
- Liez chaque fait présenté à une source de qualité (quelles sources – comment les insérer).
- Utilisez un ton neutre, qui ne soit ni orienté ni publicitaire (aide).
- Veillez également à structurer votre article, de manière à ce qu'il soit conforme aux autres pages de l'encyclopédie (structurer – mettre en page).
- → Si ces points sont respectés, pour transformer votre brouillon en article, utilisez le bouton « publier le brouillon » en haut à droite. Votre brouillon sera alors transféré dans l'espace encyclopédique.
La programmation en binôme (de l'anglais pair programming), parfois appelée programmation par paires 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
Qualité et productivité
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. Pour éviter l’ambiguïté entre temps passé et temps total par programmeur, Kim Man Lui 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.
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 reporte 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.
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[2]. De manière générale, un binôme conçoit des applications de meilleure qualité qu'un programmeur seul[6]. 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é[7]. La programmation en binôme amène alors à des applications passant davantage de tests[5] et ayant des fonctionnalités implémentées avec moins de lignes de code[2].
É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[2].
Communication
La programmation en binôme favorise la communication au sein d'une équipe puisqu'elle encourage les développeurs à parler entre eux[8]. Par ailleurs, cette pratique améliore les compétences communicationnelles[9].
- Satisfaction: 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[5].
Apprentissage
Milieu Universitaire
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[1], sans pour autant diminuer les notes des plus forts[10] ; de plus, il permet une meilleure intégration des femmes et des minorités au sein des cursus informatiques. Enfin, on note une augmentation de la poursuite d'études des étudiants ayant travaillé en binôme.
La mise en place de binômes au sein d'un cours à l'université favorise également la communication des étudiants, améliorant la qualité du travail effectué. De plus, on constate que le travail en binôme permet un échange plus conséquent entre les étudiants, mais également avec le professeur, améliorant parfois la structuration du cours[2], voire de réduire les différences pédagogiques entre les professeurs[11].
En Entreprise
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'une 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[2].
Indicateurs de non-performance
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[12], 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[13].
- Problèmes relationnels : Les deux membres du binôme ne s'entendent pas et ne souhaitent pas travailler ensemble[14].
Programmation à distance
La programmation en binôme peut également être établie à distance[15]. 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, Saros), de communiquer à distance (Skype), ou encore d'exécuter des instructions sur une machine distante (SSH)[16].
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[15]. 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[16]. Enfin, on note également certains avantages, comme les modifications mineures de code sans perturber le binôme[15].
On constate également que 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[15].
Références
- (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, (résumé)
- (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, (lire en ligne [PDF], consulté le )
- (en) John T. Nosek, « The case for collaborative programming », Communications of the ACM, vol. 41, no 3, (résumé)
- (en) Laurie Williams, Robert R. Kessler, Ward Cunningham et Ron Jeffries, « Strengthening the Case for Pair Programming », IEEE Software, vol. 17, no 4, (lire en ligne [PDF], consulté le )
- (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 », Software, IEEE, vol. 24, no 6, (résumé)
- (en) Zhen Li et Eileen Kraemer, « Social effects of pair programming mitigate impact of bounded rationality », SIGCSE '14, (résumé)
- (en) Mark Zarb, « Understanding communication within pair programming », Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity, (résumé)
- (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, (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) Grant Braught, L. Marlin Eby et Tim Wahls, « The Effects of Pair-Programming on Individual Programming Skill », SIGCSE '08, vol. 40, no 1, (résumé)
- (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, (lire en ligne [PDF], consulté le )
- (en) « Agile Pair Programming » (consulté le )
- (en) « Guide to Agile Practices » (consulté le )
- (en) Julia Schenk, Lutz Prechelt et Stephan Salinger, « Distributed-pair programming can work well and is not just distributed pair-programming », ICSE Companion 2014, (lire en ligne [PDF], consulté le )
- « Pair-programmer à distance facilement », (consulté le )
Vous êtes ici sur la page personnelle d’un utilisateur de Wikipédia en français.
Cette page ne fait pas partie de l’espace encyclopédique de Wikipédia.
Si vous avez accédé à cette page depuis un autre site que celui de Wikipédia en français, c’est que vous êtes sur un site miroir ou un site qui fait de la réutilisation de contenu. Cette page n’est peut-être pas à jour et l’utilisateur identifié n’a probablement aucune affiliation avec le site sur lequel vous vous trouvez. L’original de cette page se trouve à l'adresse suivante : https://fr.wikipedia.org/wiki/Utilisateur:Jeremy.bossut/Brouillon.