Effective Collaborative Programming3
•Transferir como PPT, PDF•
2 gostaram•383 visualizações
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)
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (8)
Destaque
Destaque (8)
Semelhante a Effective Collaborative Programming3
Semelhante a Effective Collaborative Programming3 (20)
Mais de Xebia IT Architects
Mais de Xebia IT Architects (20)
Último
Último (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
Notas do Editor
- 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