Structuring a software development team - by specialization or by task? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

开发者_开发技巧

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

As a software developer for 6 years, I've had a range of experiences with different teams, from negative to positive.

One of the best experiences I had was in a certain project team at a financial organization.

There were a number of factors that made the project successful, but I think the team structure was a key aspect of it.

To summarize:

• We had developers who specialized in different aspects. 2 developers who were good at UI and 2-3 developers who were good at writing business logic and database interfacing code.

• The code was strictly divided into Presentation, Business and Data layers.

• Every developer had a basic knowledge of the whole system. Even if they weren't experts in everything, they had a general idea of how everything hung together and could write code in any layer if necessary.

• Some tasks involved the developer in a whole vertical slice of functionality (involving work on all layers).

• Other tasks involved just the area of the application that the developer specialized in (e.g. just a UI task, or just a database task).

I think this worked well because:

• Developers were able to learn the whole system, and jump into a different layer if necessary.

• Developers retained specialization, and if a developer needed help with something he wasn't familiar with, there was always a go-to person.

• The architecture was rigid, but the people were flexible, as they should be.

Is there a formal term for this kind of team structure? Does it sound like an Agile/SCRUM arrangement?

(It didn't seem entirely planned at the time.)

Any thoughts?

---

The more skills your developers are allowed to learn, the stronger, more diverse, and happier your team will be.

Cross-training is very important. What happens if your UI specialist is run over by a bus? Can someone else already on the team take over his duties?

Work assignments should be made based on how architecturally the work can be carved off (subdividing at the interfaces, for example). The developer given the work assignment should be able to work more or less autonomously on his particular piece.

---

I don't think there is a formal name for that kind of team - other than sensible ! :) To this end I certainly agree with Robert Harvey.

Every solution will (usually) cover general areas such as UI, BL, Data; you'll also usually cover cross-cutting concerns like logging, deployment packaging, etc; and all of this will be using certain technologies. So, for a team to be appropriate for the project it will need to cover all of those things well - as a start.

That's the "horizontal"view taken care of, the vertical view (implementing slices of functionality) is where those people need to interact - and that's where XP practices like peer-programming come in, and where cross-training can really start to happen.

As a contrast to this, you might be interested by the "Surgical Team" approach, as outlined by Frederick Brooks in his famous book "The Mythical Man-Month".

There's also a link on that page to "Organization and Team Patterns", which might be of interest.