Agile development and architecture [closed]

Closed. This question is opinion-ba开发者_JAVA技巧sed. 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 5 years ago.

Improve this question

How does a formal architecture specification fit in with agile development - if at all?

I'm thinking specifically of Scrum, which makes no mention of an architecture amongst the official artifacts.

Do you just let the architecture evolve "accidentally" (so to speak), do you spec it informally, or is there room for doing something like a 4+1 spec up front, before assembling your first product backlog?

---

Agile is often described as "only do what you need to do now, and you can refactor later if more things are needed".

This is rather misleading. It can be read as "bodge something in quickly now, and then work out how to upgrade it to do more things in the future". Which will lead to a world of pain and technical debt.

For any system you need a design. For small/simple systems this design can be in your head, but you still need to think before you start about what the system will do, and how best to do it.

So IMHO the correct way to include design into an Agile approach is to design enough now that you know what the system is ultimately expected to do, and broad strokes describing how it will do it. Come up with a flexible enough design that you don't burn any bridges. But don't waste time writing a formal detailed specification for every nut and bolt. Design down to a level where you know where and how a subsystem will fit in, but it can be treated as a "black box" that in itself can be designed only when you need to implement it.

Agile development shouldn't exclude a formal architecture - it just means that you should only design enough of the formal architecture that all the bits will fit together well when you are finished, and you flesh out the smaller details of that design only as and when they are needed. Sometimes that means you still need a fairly detailed design up front.

---

Depends on your scope. Could be a given, could be green-field. Just enough architecture, just in time. You need something to be able write your first tests, do continuous integration.

It is a document, so who is going to need it, and to do what?

• your team needs something to describe where to put functionality and where tests;
• when you have to grow your team the new guy might like an introduction;
• marketing might need beautiful pictures;
• someone might have to buy and install hard- and software; ...

---

Scrum is mainly a project management technique, that's the reason why it does not mention architecture.

As much as possible the architecture is defined incrementally. Implementation done end-to-end rather than layer by layer helps in that regard: it leads to implement a part in each layer.

Architectural decisions can be hard to revert, so they have to be well though and taken at the last responsible moment, when you have more knowledge of the system and the customers needs.

There is no strong need for a formal specification.