The classical view on pair programming (as popularized by Extreme Programming camp) is two programmers coding together at one workstation. I think a more practical approach is two programmers working together to implement a single feature. They can do the design together or even work together in a single work station to code the critical components. However, they don't have to necessarily sit next to each and do the entire development in a shared work station. I think it is more effecient for the programmers to try to split the work into small chunks that can be developed in parallel working individually. The developers can probably sit togehter in pair every morning to catch up with each other's progress or jointly review each other's code and plan the next steps. If required they can even swap some of their low level tasks as they deem fit. They can even test each other's work, jointly create test cases, etc.
The point I am trying to make is that every individual need some physical and mental space to think and work. Working together with another developer by sharing the same work space daily could be emotionally and psychologially tiring.
However, I do think that it really makes a difference if developers work together in pairs to implement a single feature. Let us say we have a six member team and 12 features to implement in an iteration. It makes better sense for the team to pick 3 features and complete them by working in pairs in the manner described above. Thereafter, as and when the pairs complete working on a feature, they pick the next feature in order of priority. If the team size is not an even number, then adjustments have to be made so that the team members take turns to serve as the odd man out who has no choice but to work alone on a task.
No comments:
Post a Comment