"Il y avait vraiment du gâteau":
pair-programming un retour d'expérience
En fait on n'a pas amené de gateau. Explications de Davidplan
qu'est-ce que le pair programming? notre expérience la littérature un résumé de la structure du talks finalement rien sur le remote working. Pourquoi temps de méfiance (david: expérience scrum beer) quels bilan tirer de la pratique. Gains mesurables? 0. est-ce que ça vaut la peine 1. définition 2. histoire 1. notre expérience 2. 2. un sondage ms (qui confirme un peu notre expérience) 3. les études académiques. 4. Que Faire.Andreas Kundig @andreaskundig
David Hodgetts @David_Hodgetts
bio respectivesqu'est-ce que le pair programming?
définition (wikipedia)
La programmation en binôme (ou pair programming en anglais) est une méthode de travail dans laquelle deux développeurs travaillent ensemble sur la même partie de code, en binôme sur un même poste de travail
le premier, appelé pilote (driver), a le clavier. C'est lui qui va travailler sur la portion de code à écrire. le second, appelé copilote (partner), est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes.Les rôles s'échangent régulièrement pendant la séance de programmation.
2. L'histoire
Kent Beck popularise la pratique avec les méthodologies de l'Extreme Programming...
...la pratique est néanmoins plus ancienne:
Dans les années 50, Fred Brooks, l'auteur de "Mythical man month" évoque un projet qu'il a réalisé en pair à l'époque de ses études: "we produced 1500 lines of defect free code; it ran correctly the first time"
Dans les années 70, Dick Gabriel, le concepteur de Common Lisp et "l'inventeur" des patrons de conception évoque des sessions de binomage.
Dans les années 80, Larry Constantine parle de "dynamic duos".
Dans les années 90 James Coplien, publie dans un papier de recherche de Bell Labs "Developing in pairs": "Some problems are bigger than any one individual"
Constantine, human centered computing. structured design. cohesion coupling Avec l'extreme programming Kent Beck formalise la démarche appliquée dans un projet qui devait remplacer une grosse application cobol par du smalltalk. Après un succès initial et de nombreuses péripéties comme le rachat de l'entreprise, le smalltalk a finalement été remplacé par du cobol. david. Je viens d'une autre métier. La pratique s'y retrouve sans le nom.notre expérience
gongfu.io
L'idée de gongfu.io est de se voir régulièrement pour travailler en binôme sur un projet avec des technologies qu'on ne maitrise pas encore pour les apprendre. Au départ plusieurs binomes se réunissaient tous les jeudis à 17h30 à uni mail. Nous sommes la seule équipe qui a survécu aux vacances d'été de 2012. Gongfu n'existe plus vraiment, nous nous voyons toujours une fois par semaine, mais ou et quand ça nous arrange.Exquis
"Cadavre exquis" pour des animations javascript.Vanilla js + canvas + un peu de node.jsFonctions et structures de données plutôt que de l'orienté objet.
L'idée du projet est de faire une espèce de cadavre exquis pour des animations javascript. (montrer exquis) La technologie que nous voulions explorer était javascript avec canvas. Nous avons utilisé aussi peu de librairies que possible (require.js pour organiser le code, async pour quelques tests). L'idée était aussi de programmer dans un style plutot fonctionnel en évitant les différentes variantes du javascript orienté objet et la chaine des prototypes.Cadre de l'expérience
Projet personnel: pas de délai, pas d'obligation de résultat. Deux heures par semaine. Dans un bar le plus souvent.... ...avec un petit laptop. vim, puis sublime, finalement emacs -> apprendre à faire des compromis En remote pour quelques mois. A la fin de chaque session, on fixe les buts de la session suivante, qu'on choisit parfois d'ignorer Les conditions physiques, la gestion de l'espace et du bruit. être les deux à l'aise avec le même éditeur. forme d'intimité à gérer.Bilan
cerveau + cerveau = ?
A priori les cerveaux ne s'additionent pas, on ne fait pas quelqu'un d'intelligent avec plusieurs imbéciles. On n'accélère pas un projet en ajoutant des développeurs et neuf femmes ne font pas un enfant en un mois. En travaillant à deux sur le même projet, nous avons quand même eu l'impression de disposer de davantage de ressources mentales comme la discipline, la concentration, l'imagination.Aspects positifs
Plus de patience, discipline, concentration Live code review Bugs plus faciles à trouver Conception (algorithmes, architecture) Transmission de savoir et exercice de communication Apprendre à deux Motivation++Aspects négatifs
Aspects négatifs
Les bonnes pratiques ne sont pas automatiquement au rendez-vous Toutes les tâches ne se prêtent pas au pair programming Lâcher son partenaire en allant trop vite (in the zone alone) Demande plus d'énergie Triple programming? Un seul committeurL'expérience du remote pair programming
Skype (voix uniquement) Teamviewer Et le bilan est très positif bilan positif peut-être du à notre setup un peu serré d'habitude (bar + petit laptop) description de teamviewer (partage de la souris se fait naturellement) we each have our keyboard (link to "making software" passage) aussi efficace que le physical pair programming. chacun à son écran, on est confortable, plus facile de passer de l'un à l'autre. difficulté du setup en pp physique (gestion de l'espace). perte de contrôle du navigateur. pas faire dans un bar chacun peut chercher de son côté.options techniques (téléprésence)
Voix ou voix + vidéo
accrocher des ipads avec skype pour simuler la présence les options et question à se poser pour réussir le remote pp.options techniques (coding)
Screen sharing (teamviewer, skype, etc.)
Terminal sharing (screen, tmux)
Funky cloud stuff (floobits, screenhero.com, cloud 9)
littérature
"Pair Programming: What’s in it for Me?" (microsoft research 2008)
une étude sur les bénéfices et problèmes perçus (sondage). took form of a survey sent to a randomly selected 10% of engineers at Microsoft that 22% pair program or have pair programmed in the past. tried to sort the perceived benefits and problems487 sondés106 ont déja pratiqué le pair programming (21.7%)
64.4% pense que la pratique fonctionne pour eux
62.8% pense que la pratique fonctionne pour leur partenaire
48.2% estime que la pratique est bénéfique pour l'équipe
39.2% estime que la pratique est bénéfique pour l'organisation.
This reflects the grassroots nature of pair programming adoption at Microsoft. Individual teams are trying out pair programming, but are finding it difficult to get management buy-in to spread the practice. les gens pensent que c'est bien mais qu'il auront de la peine à convaincre l'organisation.Réactions positives
“greater understanding of a larger codebase across the team.”
“higher quality code in terms of consistency with guidelines.”
“quickly ramp-up new members,”
enables “users to learn new techniques faster.”
“every-one learns constantly from each other.”
le top ten des réactions positives
1. Fewer Bugs
2. Spreads Code Understanding
3. Higher Quality Code
4. Can Learn from Partner
5. Better Design
6. Constant Code Reviews
7. Two Heads are Better than One
8. Creativity and Brainstorming
9. Better Testing and Debugging
10. Improved Morale
ça ressemble pas mal à notre expérience.Réactions négatives
“if I have a choice, I can employ one star programmer instead of two programmers who need to code in a pair.”
Pairing “reduces the freedom of work hours of individual contributors.” (scheduling)
“Many partnerships fail due to personality conflicts,” (personality clash) - “pairs get sick of each other.”
“Sometimes we waste time on discussion,”
“tends to drag the faster/smarter/better person down.”
“if the partners‟ abilities are imbalanced, it could be that one partner become obsolete in the process.”
le top ten des réactions négatives
1. Cost efficiency
2. Scheduling
3. Personality clash
4. Disagreements
5. Skill differences
6. Programming style differences
7. Hard to find a partner
8. Personal style differences
9. Distractions
10. Misanthropy
10. Bad Communication
10. Metrics/Hard to Reward Talent
les qualités du bon partenaire
“usually looks at things from a different angle.”
“able to think … even [from] a different role (e.g. test and dev together).”
“blocks on different things than I do,”
“some-one who complements my thinking and skills in terms of technical and design skills.”
“willing to cooperate and step away from the PC with me to work on design or other details.”
“able to adapt to different working styles.”
“good listener,”
“articulate,”
“enjoy debating and discussing code,”
“sense of humor,”
“comfortable with people around them.”
le top ten des qualités du bon partenaire
1. Complementary Skills
2. Flexibility
3. Good Communications
4. Smart
4. Personable
6. At Least the Same Skills as Me
7. Strong programmer
7. Better Skills than Me
7. Able to Focus
10. Knowledgeable
les qualités d'un team qui pratique le PP
“Communication, communication, communication.” (this is MS after all ; ))
An ideal team “consists of easy-going people who want to listen and share ideas with each other.”
“A little diversity here is good.”
“cooperative personalities, they work well together, rather than trying to compete with one another.”
“permissive to mistakes.”
le top ten des qualités d'un team qui pratique le PP
1. Good Communications
2. Complementary Skills
3. Compatible Personalities
4. Team Works Effectively
5. No Ego
6. Fast and Efficient
7. Flexibility
8. Common Goals
8. Good Quality
10. Same programming skills
10. Collaborative
10. Work Well Together
"Pair Programming Illuminated", Laurie Williams, 2002
On peut aussi faire un effort
Take breaks
Practice humility
Be confident / be receptive
Communicate
Listen
Be a team player
Hone the balance between compromise and standing firm
"Making Software: What Really Works, and Why We Believe It", Andy Oram, Greg Wilson, 2010
A retenir
"suitable length for pairing session 1.5h to 4h (pairing can be mentally exhausting)"
"frequent pair rotation is beneficial for knowledge spread"
"rotating roles (driver, navigator) is important to keep both partners engaged."
"possession of keyboard as a subtle effect on decision making, with the driver often being the final decision maker"
"frequent switching of the keyboard helps keep both partners engaged."
"PP must be structured and organised (proclaimed hours for PP) (space layout, large desk, large screen, wireless mouse and kb, whiteboards, and isolation, pairs make noise)"
tête à tête (Pivotal labs)
oui mais les gains du binômage, ça se mesure?
Une étude examine deux projets dans l'industrie. Dans le premier, le pair programming n'a pas d'effet sur le nombre de bugs. Dans le second, le pair programming produit six fois moins de bugs. Une autre étude mesure une réduction de 39% du nombre de bugs. D'autres encore montrent des gains certains dans les phases de Design, et le travail sur les parties complexes, mais pas pour le travail plus simple. ???Laurie Williams 1999
39 étudiants avec une certaine expérience de la programmation, répartis en 14 binômes et 13 solos. 4 travaux pratiques à réaliser. Les binômes passent 15% de tests en plus (90% au lieu de 75%), donc 0.1/0.25 = 40% de bugs en moins. Les binômes rendent toujours à temps, les solos sont parfois en retard. Les binômes écrivent 20% de code en moins (+ de cohésion et des classes aux responsabilités mieux définies). Les binômes prennent 15% plus de temps (quand on multiplie par deux). Mais ce n'est pas statistiquement significatif.Estimation du gain de productivité
Williams combine ses résultats avec des mesures de moyennes tirées d'autres études:
22 lignes de code écrites par heures 6 bugs pour 1000 lignes 1 semaine pour corriger un bug trouvé chez le clientElle calcule la productivité en lignes de code correctes par heure-personne et obtient:
4.3 en solo 7.4 en binôme restons méfiant sur ces études. Difficile de mesurer le code. On a lu pour vous certain de ces papers, et c'est pas convainquant.En résumé
Gain de qualité du code
Meilleure répartition du savoir
Cycle plus rapide
Plus de motivation et meilleur esprit d'équipe
malgré ces avantage, l'adoption reste basse
Les habitudes du solo programming
Les raisons économiques ("ça coûte le double")
Les difficultés de coordination
Les solutions de Williams
Les habitudes du solo programming
coding dojo, code retreat, petit projet pilote
pingpong tests.Les solutions de Williams
Les raisons économiques
Commencer petit, gagner une meilleure compréhension de la pratique, projet pilote
Les solutions de Williams
Les difficultés de coordination
Meeting quotidien pour dynamiquement créer les paires en fonction des tâches du jour
Conclusion
Références:
- "Pair Programming Illuminated", Laurie Williams, Robert Kessler, 2002
- "Making Software: What Really Works, and Why We Believe It", Andy Oram, Greg Wilson, 2010
- "Pair Programming: What’s in it for Me?", Andrew Begel, Nachiappan Nagappan, 2008
- http://www.pairprogramwith.me/
- http://rubyrogues.com/126-rr-remote-pair-programming-with-sam-livingston-gray/