Agile Development, Software Architecture

Architecture-Oriented or Feature-Oriented?

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.

How do you organise your development teams?

2 thoughts on “Architecture-Oriented or Feature-Oriented?

  1. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s