日志
Agile迭代中有关architecture的讨论
热度 1 |
前一阵我对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.
