Traditionally, there are two fundamental approaches when it comes to organising your development teams: the Architecture-Oriented approach and the Feature-Oriented approach. The first privileges teams that focus on the different architectural layers or components, whereas the second prefers to organise teams around deliverable application features.
Architecture-Oriented or Feature-Oriented?
By:
Posted in:
Federico Cargnelutti 
2 responses to “Architecture-Oriented or Feature-Oriented?”
Usually the kind of project dictates the way teams are divided. If i am doing a web project that is migrating existing systems to web 2.0-ish style. Then I’d have a team for the backend that job is to maintain functionality of the system and I’d have a big UI team that is focus on the different aspects of UI. I might have, for example, a textarea team. Which job is to provide rich functionality to the textarea component.
If I’m doing an enterprise login system. Then I might have an application team and then the db team. Each with it’s own security team. The UI ‘team’ might be an extra developer that create a html login form to the system.
Some times there might be a QA or testing team depending on size of the project.
I belive there is no hard and fast rule for this either. It all depends on the project and also your resources. I’d like to have an independent outside QA team that reviews all my team;s code. But most of the time I just settle with the coders eyeballing each other’s code.
Interesting, thanks paan!