Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Découvrir les avantages du Pair/Mob Programming

Promyze
February 10, 2021

Découvrir les avantages du Pair/Mob Programming

Rendue populaire par l'Extreme Programming, la programmation par binôme (ou Pair programming) est une méthode de développement qui consiste à écrire du code source de manière collaborative à 2 personnes, chacune ayant un rôle bien défini : le driver rédige le code et l'observer relit en temps réel le code. Par extension, le Mob programming rassemble tout ou partie de l'équipe et s'applique généralement sur des tâches plus spécifiques : refactoring, fonctionnalités core business, utilisation d'un nouveau langage ou framework.

Dans cette présentation, nous présentons les concepts du pair programming et du mob programming, et les bénéfices et avantages que l'on peut en tirer : gains en qualité de code, en cohésion d'équipe et en diffusion des connaissances, baisse du nombre de bugs, ...

Nous présentons comment les mettre en œuvre, et à l'inverse aborderons les pièges à éviter. Nous nous appuyons sur l'état de l'art scientifique pour consolider nos propos avec les résultats de différentes études sur ces sujets.

Nous discutons également de certaines idées reçues autour de ces pratiques, notamment en ce qui concerne le mythe de baisse de productivité.

"2 développeurs ensemble sont forcément moins productifs que 2 développeurs qui travaillent séparément !"
Il est nécessaire d'analyser la production du code sous l'angle d'une faculté à délivrer des fonctionnalités attendues implémentées avec un code lisible, bien structuré et qui sera facile à maintenir + tard par des personnes autres que son auteur. Et puis aussi, on attend aussi un code sans bug. Nous verrons comment le Pair/Mob Programming répondent à ces enjeux.

Enfin, si le Pair Programming est un moment d'échange sur les bonnes pratiques, nous verrons comment gagner en efficacité en s'appuyant sur un référentiel de bonnes pratiques depuis notre IDE, grâce à Promyze.

Promyze

February 10, 2021
Tweet

More Decks by Promyze

Other Decks in Programming

Transcript

  1. 2 Depuis 2016, nous accompagnons vos équipes à monter en

    excellente technique grâce au partage de connaissances et une démarche dʼamélioration continue des pratiques de développement 12 Personnes @Bordeaux Lʼéquipe fondatrice Cédric Teyton CEO Arthur Magne CTO Xavier Blanc Expert Scientifique
  2. 3 Pair Programming et Mob Programming Pair Programming (popularisé avec

    lʼExtreme Programming) • Un « Driver » tient le clavier • Un « Navigator » relit en temps réel, réfléchit, prend du recul, suggère Variante : Strong-style Pair programming “In order for an idea to go from your head into the computer, it must go through someone elseʼs hands” (Llewellyn Falco) Mob Programming : • > 2 personnes (souvent, toute lʼéquipe) • 1 Driver et N Navigators
  3. 4 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  4. 5 Un impact positif sur le code produit Revue du

    code en temps réel (et non a posteriori) A plusieurs, une réflexion + poussée sur le design et lʼarchitecture “productivity when using pair programming, seems to be comparable to that of two people working independently. The reason is that programming in pairs will discuss the system before developing it, so there will probably be fewer errors and less rework. [14]” [14] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018)
  5. 6 Lʼimpact sur le code produit Diminue le risque dʼover-engineering

    Moins de blocage, moins dʼeffets liés au « Sunk Costs » Credits : fastexposure
  6. 7 Mesurer la qualité dʼun code ? “Another quality metric

    used in this study is comment ratio, which is calculated as the ratio of comment lines and total (i.e. physical) lines of code” [4] [4] A multiple case study on the impact of pair programming on product quality
  7. 8 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  8. 9 Productivité ? Qualité de code Productivité Moins de bugs

    Focus Cohésion dʼéquipe Partage de connaissances Satisfaction et bien-être
  9. 10 Comment mesurer la productivité ? Métrique récurrente : Temps

    de complétion des tâches « Pair programming technique can take around 15% longer » [1] « The effort expenditure increases more after the initial transition to PP, but gradually the productivty of the pair rises above the productivity of solo developers » [4] [1] The Costs and Benefits of Pair Programming (A. Cockburn & L. Williams, 2000) [4] A multiple case study on the impact of pair programming on product quality (H. Hulkko & P. Abrahamsson, 2005)
  10. 11 Temps de compléter une tâche ? It's in the

    doing of the work that we discover the work we must do Woody Zuill « (At Microsoft), 37,5 % of respondents agree that pair programming takes more time to do the same work that one person could have done alone » [8] [8] Pair programming : Whatʼs in it for me ?
  11. 12 La productivité dʼaujourdʼhui et de demain La dette technique

    fait référence à des choix de conceptions et dʼimplémentations qui semblent opportuns à court terme qui forment un contexte technique pouvant rendre coûteux voire impossible tout changement futur. Cʼest un passif dont lʼimpact se situe principalement sur la maintenabilité et lʼ évolutivité dʼun système. Philippe Kruchten, Robert Nord, Ipek Ozkaya, 2019 Managing Technical Debt The Developer Coefficient – Stripe/Harris Poll (Sept. 2018)
  12. 13 La productivité dʼaujourdʼhui et de demain “Mob programming might

    increase initial development time, especially when people are new to the approach. However, the total development time, including testing and fixing decreases dramatically with the reduction or even elimination of technical debt” [15] [15] Joining the Mob at Clearlink (2019) Productivité = Temps de faire la tâche + Temps de rework futur + Temps de corrections des potentiels bugs ?
  13. 14 The « Pair-Jelling » ou la phase de montée

    en puissance des pairs “Initially code generation was slower using a mobbing approach. For example, if someone in the mob had limited understanding of the area being worked on, the learning overhead would slow the entire team’s work pace. Over time this has become less of a problem and in fact contributes to benefit” [14] [14] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018)
  14. 15 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  15. 16 Un impact sur le nombre de bugs ? «

    Pair programming technique […] produces 15 % lesser defect » [1] « The results shows that the defect rate in the code appears to be lower for the parts of code involved during pair programming practices than other parts. On the basis of this observation, we formulate a hypothesis that pair programming helps to reduce the introduction of new defects when existing code is modified.” [10] [1] The Costs and Benefits of Pair Programming (2000) [10] Pair Programming and Software Defects--A Large, Industrial Case Study (2013)
  16. 17 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  17. 19 Une plus grande résistance aux distractions “When the developers

    work alone they spend 34% of their time in Visual Studio and when they work in pairs they spend 64% of their time in this application. Furthermore, the developers working alone spend 21% of their time in Outlook; however, when they are paired this number decreases to only 13% » [9] “We have found that developers working in pair switch less often between tools, both in general and within specific working sequences. Moreover, when they switch they tend to gather the needed information faster, with less switches and such information is typically new” [9] [9] Understanding the Impact of Pair Programming on Developers Attention (2012)
  18. 20 Une plus grande résistance aux distractions [12] Understanding the

    Impact of Pair Programming on the Minds of Developers (2018) “Altogether, a “reasonable” interpretation of this limited tomographic images could lead us to think that during pair programming developers are more relaxed than when doing solo programming, exercise their mind in a similar way to solve tasks, but do not need to put effort in repressing distracting stimulus” [12]
  19. 21 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  20. 22 Un exercice dʼapprentissage continu “Engineers know new languages and

    are practicing coding techniques that they have learned from their peers. Our engineers are constantly learning from each other. Their skills are sharper than ever, projects are being completed more quickly, the quality of the end product is superior, and the team has increased its efficiency” [15] “The interviewees credited this shift to the increased rate in shared knowledge and work understanding through developing and working together as a team” [16] “84% of the class agreed with the statement “I learned Active Server Pages faster and better because I was always working with a partner.”” [1] [1] The Costs and Benefits of Pair Programming (2000) [15] Joining the Mob at Clearlink (2019) [16] Exploring The Impact Of Mob Programming On The Well-Being Of Developers: Insights From a Software Company (2020)
  21. 23 Quels sont les gains du Pair/Mob Programming ? Qualité

    du code ? Productivité ? Bugs ? Focus ? Partage de connaissances ? Satisfaction et Cohésion dʼéquipe ?
  22. 24 Une influence positive sur les équipes « It appears

    that pair programming has a significant, positive influence on the satisfaction of developers. This comes with increased communications between developers, speed of communication of design chances ». [3] (Sondage auprès de 108 développeurs, 54 faisant du PP et 54 non) “Team morale has improved since the team starting mobbing regularly. Written feedback from team indicates that regular mobbing was a factor in this. In the weekly retrospectives team members regularly stated that they were enjoying mobbing and the learning it was enabling” [18] Responsabilité collective = moins de stress = + de bien-être et de motivation ! [3] Preliminary Analysis of the Effects of Pair Programming on Job Satisfaction (2002) [18] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018)
  23. 25 Bilan des bénéfices du Pair Programming [8] Pair programming

    : Whatʼs in it for me ? Etude du PP chez Microsoft [8]
  24. 27 [5] The social dynamics of Pair Programming (2007) [7]

    Exploring The Impact Of Mob Programming On The Well-Being Of Developers: Insights From a Software Company (2020) « The less knowledgable programmer reported a tendency to become ʻpassiveʼ, disengaging from the task as not to impeded his or her partnerʼs ability to make timely forward progress on the task » [5] « Individuals who had an inferior coding experience concerning the person's team members tended to become a passive spectator instead of actively participating in the mob. This could result in reduced motivation when using Mob Programming for some individuals » [16] Un Equilibre entre mentoring & apprentissage
  25. 28 Un Equilibre entre mentoring & apprentissage “He now found

    himself as the only senior engineer in the mob […] He performed at a very high level for the first few weeks but began to feel fatigued and lost his excitement as he felt he wasnʼt progressing past the storming phase. He felt like he was carrying the load, solely responsible for completing tasks in a timely fashion, and responsible to teach the engineers that were less experienced. Ultimately he lost his enthusiasm for mob programming and left the team. We quickly learned that the composition of the mob needed to have a balance » [15] [14] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018)
  26. 29 « Donʼt force the culture » (1) http://blog.cleancoder.com/uncle-bob/2021/01/17/Pairing.html [13]

    Mob Programming – A Whole Team Approach (2014) “Pairing should always be voluntary, never be forced, never be scheduled by a manager, and never tracked. It is an informal process that is entirely under the control of the individual programmers.”1 Si 2 personnes ont une relation tendue, éviter le PP : ce nʼest pas une méthode pour apaiser les conflits ☺ “We do not insist that people participate if they donʼt feel comfortable. Everyone is expected to contribute in the way they feel they best can, but no one is forced to sit and work with the team. Itʼs a personal choice. All are invited to join in but are free to work alone if they so choose” [13]
  27. 30 Prendre en compte les personnalités de chaque personne “There

    is a risk that team members who have a preference to work on their own are more visible and may be perceived as non-team players and become isolated from the rest of the team. There is also a risk that a team member who does not have good interpersonal skills may find it difficult to communicate with the rest of the team, who may have better developed interpersonal skills. This may result in that person feeling isolated“ [14] “As a result of the qualitative study mentions, some individuals felt like they were constantly being watched, overlooked, or judged by their work. This resulted in an uncomfortable feeling which could be hard to deal with. Therefore, it could be hard for some individuals to get used to the ways of Mob Programming” [16] [14] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018) [16] Exploring The Impact Of Mob Programming On The Well-Being Of Developers: Insights From a Software Company (2020)
  28. 31 Rotation des pairs et « Context Switching » “However,

    we use a heuristic to help guide us in regards to “how many is too many”: For each individual, if you do not feel you are either contributing or learning we take that as a sign that this might be a good time to work on your own for a bit, or to split off with a pair or a few others to start your own Mob ” [13] « Rotating late in the task may break up an effectively functioning pair and introduce a new programmer in a disavantaged position» [5] Taille des “mobs”, rotations : pas de règles dʼor [5] The social dynamics of Pair Programming (2007) [13] Mob Programming – A Whole Team Approach (2014)
  29. 32 Généraliser et démontrer les gains ? « The existence

    body of empirical evidence indicates that PP affects duration, effort and correctness, and we are reasonably sure that these effects are not simply due to chance. […] However, weʼre still far from being able to explain why we observe the given effects » [6] « We had an increase of approximately 10 times the number of projects delivered. There are many factors we are not taking into account using this measurement, such as project size or number of features. While this general comparison is meaningful to us internally based on our knowledge of the work involved for these projects, it might not be meaningful to anyone else.” [13] Le développement logiciel est un process fait de changements & dʼincertitude [6] The social dynamics of Pair Programming (2007) [13] Mob Programming – A Whole Team Approach (2014)
  30. 33 Envie de démarrer (en remote) ? Visual Studio Live

    Share (VSCode & Visual Studio) 2018 GitDuck (JetBrains, Android Studio, VSCode, …) 2019 CodeTogether (Eclipse, Jetbrains, VSCode ) 2020
  31. 34 Une pratique compatible en full-remote “Our results show that

    when programmers can see where their partner is looking, they concurrently look at the same code more often. With the visualization, they are able to communicate about locations in the code more successfully, efficiently, and effectively. Thus, the design serves as a helpful aid for coordinating remote work” [11] [11] Improving Communication Between Pair Programmers Using Shared Gaze Awareness (2017)
  32. 36 Références [1] The Costs and Benefits of Pair Programming

    (2000), A. Cockburn & L. Williams [2] Experimental Evaluation of Pair Programming (2001), J. Nawrocki, A. Wojciechowski [3] Preliminary Analysis of the Effects of Pair Programming on Job Satisfaction (2002), Succi et al. [4] A multiple case study on the impact of pair programming on product quality (2005), H. Hulkko & P. Abrahamsson [5] The Social Dynamics of Pair Programming (2007), J. Chong & T. Hurlbutt [6] Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise (2007), Erik Arisholm et Al. [7] An experimental investigation of personality types impact on pair effectiveness in pair programming (2008), P. Sfetsos [8] Pair Programming: Whatʼs in it for Me ? (2008), Andrew Begel & Nachiappan Nagappan [9] Understanding the Impact of Pair Programming on Developers Attention (2012), A. Sillitti [10] Pair Programming and Software Defects--A Large, Industrial Case Study (2013), E di Bella et Al. [11] Improving Communication Between Pair Programmers Using Shared Gaze Awareness (2017), S D'Angelo et Al. [12] Understanding the Impact of Pair Programming on the Minds of Developers (2018), S. Busechian et Al. [13] Mob Programming – A Whole Team Approach (2014), W. Zulli et Al. [14] Leveraging the Mob Mentality: An Experience Report on Mob Programming (2018), J. Buchan [15] Joining the Mob at Clearlink (2019), T. Powell et Al.
  33. https://promyze.com @ProMyze_QL @ProMyze 37 Cédric Teyton CEO [email protected] 06 71

    75 84 63 Arthur Magne CTO [email protected] 06 88 53 84 17 La plateforme collaborative dédiée aux bonnes pratiques de développement 11 Cours du 30 Juillet 33000 Bordeaux Contact