敏捷和架构的冲突

实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。当使用敏捷方法来引领所需的架构设计的时候，两者强强联手将会是双赢。

Tom Graves 认为敏捷需要一个脊柱来支撑。而软件架构提供了这个脊柱。

敏捷通常需要一个脊柱来指引方向——根据这个方向，推动一些工作的进行。这样做，相对于随意出牌，可以完成更多的工作。通常，这是个平衡问题——要在坚实的脊柱和敏捷之间有个良好的平衡。

Jan Van Til 赞同 Tom 的观点，他认为没有后台的脊柱，前端也很难看得出有多敏捷。

我们当然需要一个相对进展“缓慢”的“后台”，这样才能让我们看清我们有多敏捷（“前端”）。如果所有的东西都很时尚…我们还能从中识别出哪个是时尚吗？我们当然需要一个有点“缓慢”的“后台”，这样才能让我们看清时尚（“前端”）。换句话说，我们需要传统的东西，没有传统的东西，也就没有了时尚。

Simon Brown 觉得，甚至“绝大部分的敏捷项目”可能都有或大或小的架构方面的问题。我们需要在项目早期迭代中解决它们。Simon 认为，敏捷和架构的冲突可以归结为是通过短迭代来交付商业价值，还是做一个庞大的预先设计。这里的关键点是设计要“刚刚好”（just enough）。准备好一个初步的结构是很重要的，但这不意味着就要画出无数的详细类图。

John Bauer 则提到，在对几个项目观察了一段时间以后，他发现了一个有趣的模式。

敏捷以及那些类似敏捷的方法有个好处，对于产品来说，它能减少那些架构设计过度的软件解决方案（over architect-ed software solutions）的产生。架构设计过度的解决方案会强调软件应用项目的交付，也会使得软件开发和维护的成本上升，通常来说，是跟交付商业价值背道而驰的。

James Coplien 和 Kevlin Henney 给我们介绍了一种从项目开始的时候就进行“刚刚好”的架构设计，并且确保项目成功的有效方法。

但是，这一切在现实世界里又是怎么实现的呢？

Simon Brown 在他的博文中提出了一个有趣的挑战：他要求在 4 个月左右的时间内，重新开发一个程序来取代老迈的在线银行系统 。他要求大家仍然使用敏捷方法，但最终还是能够交付。博文中提到了大家提出的一些方案，包括 Kero 和 John Bauer 的。你可以查询到更多的方案，也可以提出你自己的想法。

这样看来，架构设计和敏捷需要共存。不是有你没我，而且相互合作。这里的关键点就是做“刚刚好”的设计。 Simon 定义了“刚刚好”：

做一个“刚刚好”的架构，可以让你条理清晰，明确愿景。换句话说，“刚刚好”让你知道了你的目标是什么，你怎么去完成这个目标。背后的关键就是架构是一个重大的决定，而“重大”是由进行改变所需要的成本来衡量的。换而言之，这就是架构，想要修改真的会很贵，而且你真的必须尽早做出正确的决定。举个例子，质量属性，比如高性能，高扩展性，高安全性以及高可用性，通常都需要在早期就把这些考虑在基础框架内，因为想要在后期重新修改现有的基础代码库会很难。这也就是架构，你不可能在某个下午很简单地就进行重构，比如核心技术选择、架构模式、核心框架等。

查看英文原文： Agile and Architecture Conflict