Monday, October 16, 2006

One developer per feature

When you're planning an iteration, you start with user stories, break them into tasks, make estimates, commit to the iteration scope, and then begin working (as a collaborative, sel-organizing team, of course).

My past 2 project teams have both concluded that it's better to have 1 person (or pair of programmers) develop an entire feature than to have different people working on different sub-tasks. Avoid the temptation to break a story into layered tasks such as "build the DB", "build the domain objects", and "build the UI" -- with each task worked by different people. You may have people who specialize in only one of these layers, but your team will be more productive and flexible in the long run if everyone has broader skills. Besides, having 3 different people working on 1 feature requires lots of coordination and presents lots of opportunities for miscommunication. Instead, have one person (or pair, for you pair-programming zealots) build the whole shebang.

In OO development, we aim to minimize coupling between components and maximize cohesion within components. This is the same concept. Each developer is a component of the team, and you want to minimize the amount of coupling required between developers; when coupling (communication) is required, you use the most effective means of communication possible - face to face conversation. At the same time, you want to maximize developer's internal cohesion - by letting him/her focus on a single feature.

Of course, to do this, you need to have stories/features which are small enough for 1 person to complete within a single iteration. But that's a worthy goal for many other reasons, too.

No comments: