敏捷与架构——不共戴天，抑或和谐共处？

很多评论人士一直在讨论：人们认为，在敏捷技巧和架构思维之间存在对立关系。

在敏捷世界中，架构通常被认为是BDUF（Big Design Up Front，大规模预先设计），因而在“YAGNI”（You ain’t gonna need it，你不会需要它）信条的指引下被忽视或者推迟。

从另一方面来看，正如IEEE Software Magazine2010年3/4月刊指出的一样：

敏捷开发已经极大地影响了软件行业的开发实践。然而，暂且不论它在全世界的流行，敏捷方法中存在这一个日趋强烈的关于软件架构师角色和重要性的困惑：很多人坚持“在大型软件密集型的系统中，架构师在达成质量目标的过程中扮演着关键性角色”这一观点，而他们质疑任何对架构不够重视的开发方法能否普遍适用。

……

IEEE推出的特别版关注在敏捷和架构之间的关系，探究由敏捷和架构之间的冲突派生而出的“错误的对立关系”。

在该特别版的介绍文字中，编辑们引用了一些敏捷思想领袖在架构方面的观点：

另外还有一个因素是从第一个sprint或者迭代一开始就“向利益干系人交付价值”。但开发人员，而不仅仅是最终用户，是否属于利益干系人的一个关键类别？Alistair Cockburn构思了一个策略，是始于“可行走的骨架”（walking skeleton），然后再迭代地演化。Mary和Tom Poppendieck提出了“可分割系统架构”的概念。最后，Kent Beck的建议是“架构在XP项目里面跟在其他软件项目中一样重要。架构的一部分是通过系统隐喻[XP实践之一]来捕捉的。”

这篇文章继续甄别出了在解决敏捷和框架之间的冲突时，需要明确的“真正问题”：

• 明确语义 —— 组织或项目使用“架构”，究竟是指什么。不是所有的设计决定都关乎架构，事实上，很少的设计决定达到了架构级别的重要性，很多项目团队在开发流程的非常早期就做出了这些决定。
• 上下文是关键 —— 该项目的环境：如组织、业务领域、现有技术、项目规模、变化率、系统寿命、重要程度、治理、市场状况和预期寿命等等方面都影响了需要做出的架构决策。
• 在生命周期中的阶段 —— 架构决策应该在生命周期中及早地作出，因为“架构包含了一组关于系统结构和行为的重大决定”。这些决定在后期将很难改变，因此架构的故事应该在早期的迭代中就融入到功能性故事之中。
• 架构师的角色 —— Martin Fowler谈及了架构师的两个方面：
  • Architectus reloadus —— 重大决策的制定者和坚持者、注重对外的协调。
  • Architectus oryzus —— 亲自写代码、导师、榜样和困难解决者、注重开发团队内部的协调。
• 不是所有的文档都是坏的 —— 在大多数情况下，架构需求可以表示为一个“walking skeleton”原型，仅仅针对于由少量可靠的隐喻支撑的最终目标框架。然而，也许是为了证明框架与外部规则的兼容性，或者向一个大型的、分布式团队传达，有时可能也会需要更明确的架构文件。
• 架构有方法 —— 敏捷方法在如何定义架构方面通常陷于沉默，即便是那些明确指出架构价值的方法。花一些时间和精力探索可用的架构方法（文章列出了其中一些方法）是值得的。
• 架构有价值 —— 架构成本很容易显现，特别是针对于BDUF方法，但价值可能并不总是立刻显现。用业务价值术语表达架构方面的需求，有助于揭示架构在项目中交付的价值。

（Martin）Bob大叔在他的Object Mentor博客中写道：

关于敏捷开发更阴险和流传深远的神话之一是：前期的架构和设计不好，你永远都不应该花时间在前期制定架构上的决策。相反，你应该让你的架构和设计一次一个测试用例地、从无到有地进行演化。

请原谅我，但那种说法确实是扯淡。

这个迷思根本不是敏捷的一部分。相反，它是针对“真正的敏捷取缔大规模预先设计（BDUF）”的、过于激进的言论。毫无疑问，BDUF是有害的。设计人员和架构师花费连续几个月，基于由菊花链连接起来的、未经检验的假设来设计系统，实在是毫无意义。套用John Gall的话：从头设计的复杂系统从来都工作不了。

但是，有些架构上的问题也需要在前期解决。有些设计决定必须尽早做出。埋头代码可能会把你带向肮脏的死胡同，如果提前做一些考虑，这很可能就可以避免。

请注意这里强调的大小。大小非常重要！ “大”是糟糕的，但“小”是很好的。事实上，LDUF是绝对必要的。

敏捷Architect网站也给出了一些具体的建议：

敏捷开发方法试图改善软件开发过程，使得我们可以更频繁地、更快地交付有效的解决方案。然而，尽管存在着一些成功案例，大型企业和项目在采纳敏捷上还是非常缓慢。其中一个原因是，很多敏捷方法被认为在架构方面比较弱，与复杂企业环境中交付大型系统的现实完全脱节。同时，许多架构流程被视为缓慢、笨拙和官僚。他们将从一个更敏捷的方法中受益。本网站通过把敏捷带给架构和把架构带入敏捷，来找出解决这一困境的方法。

该网站讨论了敏捷架构师的角色和一些敏捷架构的原则。

你的团队如何克服BDUF和LDUF之间的隔阂？你是否认为敏捷与架构之间存在着冲突呢？

查看英文原文：Agile Architecture - Oxymoron or Sensible Partnership?