[现在不支持直接从论坛导入了,所以直接手工copy过来]
前一阵我对Agile迭代中architecture的相关话题有些疑惑。Architecture是Scrum和XP都没有非常直接讨论到
的东西。我感觉脑子里有些东西还需要澄清一下。正巧在看《硝烟中的Scrum和XP》(Scrum and XP from the
Trenches),这本书也没涉及到这个话题,就写信给作者Henrik
Kniberg把我的疑惑提出来。我感觉他的回答还是印证了我的之前的想法和猜测。也许有人对这个也有兴趣,不妨随便看看,希望有帮助。
下面是我写给Henrik的信:
Thanks for writing Scrum and XP from the Trenches! I’ve read it twice and I love it!
However I didn’t find the answer that I’ve been looking for for a long time… Let me brief the question that puzzles me first.
Although
Agile doesn’t say “it’s forbidden to have a stable architecture design
as early as possible”, it doesn’t provide any practice about
architecture. Actually it encourages simple design – focus on the
current iteration. It seems that with Agile, the architecture is result
from continuous refactoring. For example at the very beginning, if we
don’t look at the whole product backlog, but only the first sprint
backlog, the architecture can be very simple but totally different from
the architecture of the 8th sprint. Of course theoretically you can
always get the architectural design “updated” by refactoring, but is
that cost-effective? Is it wise to look at the whole picture, i.e.
product backlog, not just the 1st sprint backlog, to get a different
but more reasonable solution? I mean, there’re too much energy wasted
in the refactoring – I didn’t say refactoring is not necessary. Maybe
it should be a trade-off – somewhere between the “big picture” and the
current sprint. But where is it? If architecture is required at early
stage, then there’s no big difference between RUP and Agile - let’s
neglect the collocation, TDD and etc.
Can you pls help me understand the Agile way of doing this?
Moreover,
back to your book. In chapter 15, you introduced the approaches to
“break down a product backlog for 2 teams”. If you don’t have
architecture in advance or at early stage, how can you make sure all
teams will finally work out the same architecture (or compatible
architectures)? No matter what approaches you adopt (one product owner,
one product backlog; two owners, two backlogs…), the synchronization
between the two teams is difficult!
下面是Henrik的回信:
In
agile & iterative development youbasically have to balance between
BUFD (big up front design) and NUFD (no upfront design). Some people
misunderstand Agile and think that agile means NUFD,but what you actual
need in most contexts is a compromise. RUFD (rough up frontdesign).
That means you are still delivering running, tested features
everysprint. But the first sprint you spend a little more time with
architecture anda little less time with features. The exact proportions
is of course extremelycontext dependent.Another
difference is that thearchitecture in an agile process is primarily
expressed as code. Diagrams canof course be created, but we try to keep
them at a high level only. Anotherdifference is that, even though there
may be some kind of architectural vision(we will have X layers and
using language Y and platform Z and protocol P) wetry to implement as
little architecture as possible to support only thefeatures being built
now. That allows to learn and improve the architecture insmall steps
instead of making a really big and complex architecture that solvesthe
wrong problem.
You said it pretty well yourself:
"Maybe it should be a trade-off – somewhere between the “big picture” and the current sprint."
As
soon as you have multiple teamsworking on the same system you need to
have communication between them, or thearchitecture will tend to break
down. For big systems you might start with onlyone team until they find
a fairly stable way to partition the system, thenimplement the
appropriate interfaces so that multiple teams can be spawnedafterwards
and work independently on different subsystems. But even in
thatscenario the teams will need to communicate because sometimes
the"stable" architecture will need to be updated as the teams learn
moreabout the problem they are solving.
That
is why agile is all about keepingthe architecture simple and changable
rather than trying to create an advanced,generic architecture that
solves all problems and never has to be changed. Ifthe architecture is
simple and changable then multiple teams can work togetheron it and
improve it when necessary.
It
is quite common for architectureteams to form, basically a virtual team
like scrum of scrums. One guy from eachteam meets once per week to talk
about architectural decisions and tradeoffsand synchronize between the
teams.