Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a Pair programming
Semelhante a Pair programming (20)
Último
Último (20)
Pair programming
- 1. Pair Programming Andy Gray and Paul Flewelling
- 2. Who are we? ‣ We're from Boost New Media ‣ We use Scrum Andy Gray & Paul Flewelling |
- 3. Why are we here? ‣ We’ve started to use Pair Programming more and more. ‣ We want to share some of our experiences. Andy Gray & Paul Flewelling |
- 4. What’s your experience? 5 = I think pair programming is great, and would encourage my team to use it 4 = I’ve heard about pair programming and am keen give it a try 3 = I don’t know very much about pair programming 2 = I’m not convinced pair programming adds value 1 = I’ve tried pair programming and wouldn’t use it again Andy Gray & Paul Flewelling |
- 5. What is Pair Programming? ‣ Two developers working together on one problem, on one computer ‣ One acts as the driver ‣ The other as the co-driver Andy Gray & Paul Flewelling |
- 6. What is Pair Programming? ‣ The keyboard / roles are exchanged regularly ‣ Pairs change often ‣ each story ‣ each day Andy Gray & Paul Flewelling |
- 7. What is Pair Programming? ‣ It’s biggest proponent is Extreme Programming. ‣ XP Coding Rule: All production code is pair programmed ‣ We don’t pair program everything Andy Gray & Paul Flewelling |
- 8. What is Pair Programming? It works well with other Agile Methodologies like Scrum because: ‣ Teams are self organising ‣ Teams have collective ownership ‣ Scrum is an empirical process which allows teams to experiment Andy Gray & Paul Flewelling |
- 9. What is Pair Programming? It is problem solving which is ‣ Co-operative ‣ Social Andy Gray & Paul Flewelling |
- 10. Setting the scene... Andy Gray & Paul Flewelling |
- 11. Barriers to Pair Programming It isn’t for every team, members must be ‣ sociable ‣ be able to talk about what they’re doing ‣ prepared to co-operate ‣ able to accept collective ownership Andy Gray & Paul Flewelling |
- 12. Barriers Pair Programming for sustained periods can be exhausting Andy Gray & Paul Flewelling |
- 13. Barriers Can be hard for management to accept ‣ Aren’t two developers working on one problem half as productive? Andy Gray & Paul Flewelling |
- 14. Benefits of Pair Programming Counter-intuitively, productivity isn’t halved ‣ Two heads are better than one at solving problems and spotting mistakes ‣ Pairs stay focused for longer ‣ Our velocity has stayed consistent, but with less re-work Andy Gray & Paul Flewelling |
- 15. Benefits Pairs produce higher quality code with ‣ fewer defects ‣ better design decisions Andy Gray & Paul Flewelling |
- 16. “The benefits of getting a product out faster, reducing maintenance expenses, and improving customer satisfaction with product quality outweigh the minimal programmer hour increase that was seen.” Strengthening the Case for Pair-Programming Laurie Williams et al Andy Gray & Paul Flewelling |
- 17. Benefits Pairs encourage each other to follow good agile practices such as ‣ Test Driven Development ‣ Code Refactoring ‣ Collective Ownership Andy Gray & Paul Flewelling |
- 18. Benefits ‣ Pairing encourages a sense of team ‣ The sense of vulnerability diminishes as the team becomes stronger, the team will tackle any task ‣ The team becomes increasingly cross-functional Andy Gray & Paul Flewelling |
- 19. Benefits ‣ Pairs working together ‣ focus each other ‣ peer review each other ‣ boost courage to tackle problems ‣ share knowledge ‣ learn from each other Andy Gray & Paul Flewelling |
- 20. Benefits Pairing makes it easier to add developers to a project. Andy Gray & Paul Flewelling |
- 21. Summary ‣ Simple discipline of two developers working together on one machine ‣ Requires developers to be sociable and co-operative ‣ There are some barriers to it’s uptake Andy Gray & Paul Flewelling |
- 22. Summary The pros far outweigh the cons: ‣ High-level of focus ‣ Higher quality ‣ Knowledge sharing ‣ Higher team confidence Andy Gray & Paul Flewelling |
- 23. Any Questions? Andy Gray & Paul Flewelling |
- 24. References Strengthening the Case for Pair Programming Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries Andy Gray & Paul Flewelling |
Notas do Editor
- \n
- Paul\n
- Paul\n
- Paul\n
- Andy\n
- Andy\n
- Andy\n
- Andy\n
- Andy\n
- Paul: Lets talk about a typical pair programming session\n
- Paul: The best pair programmers know when to say "let's try your idea first."\n
- Paul: We’ve found 3 hours to be the upper limit, pair programming sessions that have lasted all day often end up in going home exhausted. That said, endurance does increase the more often you use it.\n
- Paul\n
- Paul\n
- Andy\n
- Paul: They’re study showed pair programmers solved a problem in 60 to 80% of time with better quality \n
- Andy: The study “Strengthening the case for pair programming” also showed that pairs increased test coverage, up to 10% higher than their individual counterparts.\n
- Andy\n
- Paul, share knowledge around the team, knowledge of the domain, the business.\n\nWe also learn from each other in terms of coding and processess\n
- Paul\n
- Paul - Andy - Paul\n
- Andy\n
- \n
- \n