Effective Collaborative Programming3
•Télécharger en tant que PPT, PDF•
2 j'aime•383 vues
This was presented by Amit Sharma and Abhishek Agrawal at Agile NCR 2009 Conference held on 18th July at Park Premier Hotel.
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (8)
En vedette
En vedette (8)
Similaire à Effective Collaborative Programming3
Similaire à Effective Collaborative Programming3 (20)
Plus de Xebia IT Architects
Plus de Xebia IT Architects (20)
Dernier
Dernier (20)
Effective Collaborative Programming3
- 1. Agile NCR 2009 July 18, 2009 Effective Agile Software Development with Collaborative Programming
- 4. A day of a solo programmer
- 6. A day in collaborative programming
- 7. A day in collaborative programming
- 20. Questions
Notes de l'éditeur
- The two programmers are still doing two programmers' worth of work, they're just doing it together rather than individually. There's an implicit assumption there that all bugs take the same amount of time to fix. In my experience, this is very much false. When I program without unit tests or a "smart" (syntax-checking) editor, the distribution usually looks like this: 4 hours to write the code. About 6-12 bugs that can be fixed in under 10 minutes. Syntax errors, type mismatches, nulls, and general brain farts. About 2 bugs that take an hour each 1 bug that takes 8-10 hours. which is that
- Pair programming transforms what has traditionally been a solitary activity into a cooperative effort. Remote pair programming , also known as virtual pair programming or distributed pair programming, is the practice of pair programming where the two programmers comprising the pair are in different locations, working via a collaborative real-time editor, shared desktop, or a remote pair programming IDE plugin.
- Productivity and quality with distributed teams.
- A primary consideration in virtual teaming is that of communication. Poor communication can cause problems like inadequate project visibility, wherein everyone does his/her individual work, but no one knows if the pieces can be integrated into a complete solution. Coordination among the team members could also be a problem. Finally, the technology used must be robust enough to support distributed development of software, not just to provide communications.
- New extension of team (although we very strongly recommend collocation in initial phases)
- The two programmers are still doing two programmers' worth of work, they're just doing it together rather than individually. There's an implicit assumption there that all bugs take the same amount of time to fix. In my experience, this is very much false. When I program without unit tests or a "smart" (syntax-checking) editor, the distribution usually looks like this: 4 hours to write the code. About 6-12 bugs that can be fixed in under 10 minutes. Syntax errors, type mismatches, nulls, and general brain farts. About 2 bugs that take an hour each 1 bug that takes 8-10 hours. which is that