Pair Programming :: Agile Portugal 2014

1,864 views

Published on

Published in: Internet, Technology, Travel
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,864
On SlideShare
0
From Embeds
0
Number of Embeds
536
Actions
Shares
0
Downloads
14
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • NCIS 2 IDIOTS 1 KEYBOARD video
  • eXtreme Programming (XP)
    Software development methodology
  • code is produced by two people programming:
    on one task
    on one workstation
    Two keyboards (optional)
    Two mice (optional)
    Two monitors mirroring (ideally)
  • How should the driver and navigator seat?
    Which hardware should they have to pair programme effectively?
  • All the times:
    In front of a working station

    Except in:
    meetings (finishing each other sentences)
    Bathroom (taking a leak)
  • Engagement / Commitment
    Valuable Stand ups
    Better integration of new team members
  • Should I stay or should I go?

    It really depends how obsessed you are with reviews…but I would say no.
    One of the members of the pair is already reviewing
    With proper rotation everybody gets a chance to review the code
  • Less bugs
    More fun
    Less distractions
    Less interruptions from “outsiders” (changed from stopping one dev to stopping two)
    Less slacking on important stuff (testing, coding properly, adding comments, etc...)
  • Because you are pairing:
    you have better ideas
    stay in the zone for longer
    More courage to take “risky”/”unconfortable” tasks
    Opportunity to learn and to teach
  • [Image] Dude coding and listening to music

    [Image] Dude coding on workstation and having facebook on the laptop
  • No music (at least headphones)
    No youtube
    No facebook
    No twitter
    No instagram
    No tumblr

    Basically No social crap

    (your manager is going to love this part)
  • * Nop!
    * You must:
    Be willing to give it a try
    Be social
    Be confident
    Embrace/deal with partners feedback
    Manage conflict
    Accept differences (not everything will be like you want)
    * It’s quite exausting
    It’s not rainbows and unicorns
    You will have a learning curve ahead
  • BUT... It should be highly recommended!

    (Story at sky where the team stick to pp because of not wanting to do code review.)
  • The non believers think so:
    Twice the salary / cost?
    Half the speed?
    So what about:
    Bugs?
    Technical debt?
    Bus factor?
    Team spirit? Morale?
    WIP limit?
    It wont be expensive on the mid/long term
  • BSkyB
    2degrees network
    NotOnTheHighStreet.com
    Virgin Media
    Orange
    O2
    eBay
    Hashrocket
    Pivotal Labs
    Facebook
    Square
    Twitter
    Groupon
    SaludOnNet
    Feelunique.com
    CustoJusto.pt
  • * Couple of days a week
    * Just one team
    * Just one pair (in a team)

  • Pair Programming :: Agile Portugal 2014

    1. 1. Pair Programming
    2. 2. Who am I? @_pedro_torres | pedrogustavotorres.com Pedro Gustavo Torres
    3. 3. A little bit of background
    4. 4. What is Pair Programming? • code is produced by two people programming: – on one task – on one workstation • Two keyboards (optional) • Two mice (optional) • Two monitors mirroring (ideally)
    5. 5. Driver…
    6. 6. …navigator
    7. 7. Change roles multiple times a day
    8. 8. Change roles multiple times a day
    9. 9. Change roles multiple times a day
    10. 10. ¡Quiz time! In which scenarios are the developers properly pairing? A B C D
    11. 11. Setup #1
    12. 12. Setup #2
    13. 13. Setup #3
    14. 14. Setup #4
    15. 15. All the times in front of…
    16. 16. …except in…
    17. 17. …and in!
    18. 18. Task BTask B Task ATask A Rotation between pairs Monday Wednesday
    19. 19. Pair rotation lader Source: Rachel Davies, Agile Coaching
    20. 20. Collective code ownership…
    21. 21. …bus factor…
    22. 22. …beginners mind
    23. 23. Engagement / Commitment…
    24. 24. …valuable stand-ups…
    25. 25. …better integration of new team members…
    26. 26. …limit WIP…
    27. 27. … to skip code reviews?
    28. 28. Less bugs…
    29. 29. …more fun…
    30. 30. …less distractions…
    31. 31. …less interruptions…
    32. 32. …less slacking…
    33. 33. …and comfort zone wise…
    34. 34. …bigger comfort zone!
    35. 35. Two heads think better than one
    36. 36. “Common” habits…
    37. 37. …no music / social “stuff”
    38. 38. So is Pair Programming for everyone?
    39. 39. It should not be imposed
    40. 40. Remotely works?
    41. 41. Are estimations affected?
    42. 42. What about size or length of tasks?
    43. 43. Is it €xp£n$ive?
    44. 44. Is it only for mature teams?
    45. 45. Does it scale?
    46. 46. Companies that use it?
    47. 47. Scholars and hands-on fans?
    48. 48. Maybe slow…
    49. 49. …or all in!
    50. 50. Thank you Next time I’ll pair present! 

    ×