Question

以我的经验，人们用“敏捷”一词指代的往往不止一件事情。首当其冲就是软件开发的敏捷方法1；快速行动，拥抱变化，持续交付，接收反馈，不一而足。与敏捷思维模式相关的第二个意思是，人们如何在敏捷环境中一起工作，通常包括了团队动态、系统思维、心理学以及其他可能会跟创建高效团队联系在一起的事情。

1http://agilemanifesto.org

先把后面提到的这些“肤浅的东西”放到一边，在我看来，给软件架构打上“敏捷”的标签就意味着它能够应对所处环境中的变化，适应人们提出的不断变化的需求。这跟敏捷团队创建的软件架构不尽相同。以敏捷方式交付软件并不能保证得到的软件架构是敏捷的。事实上，以我的经验，发生相反的事情通常是因为团队更关注交付功能，而非架构。

理解“敏捷”

要理解你的软件架构需要多敏捷，就应该看看敏捷究竟是什么。美国空军战斗机飞行员约翰•博伊德（John Boyd）提出了一个名为OODA循环的概念2。本质上，这个循环构成了基本的决策过程。想象一下，你是一个正与敌人缠斗的战斗机飞行员。为了击败对手，你需要观察情况，确定自己的方位（比如做一些分析），决定做什么，并采取行动。在激烈的战斗中，为避免被对手击落，这个循环要执行得尽可能快。博伊德说，如果你能洞悉对手的OODA循环，执行得比他更快，就能混淆视听，误导对手。如果你比对手更敏捷，就能成为最后的赢家。

2http://en.wikipedia.org/wiki/OODA_loop——观察、定向、决策和行动，Observe、Orient、Decide、Act。——译者注

在一篇题为“What Lessons Can the Agile Community Learn from A Maverick3 Fighter Pilot”（敏捷社区能从特立独行的战斗机飞行员身上学到什么）4的论文中，不列颠哥伦比亚大学的史蒂夫•阿道夫引用了博伊德的概念，将其应用于软件开发，得出的结论是敏捷是相对的，且按时间来衡量。如果你的软件团队交付的软件跟不上所处环境的变化，就不算敏捷。如果你在一个庞大而行动缓慢、鲜有改变的组织中工作，很可能交付软件要花费数月，却仍被组织认为是“敏捷”的；在一个精益初创团队中，情况多半就不一样了。

3Maverick是电影《壮志凌云》中汤姆•克鲁斯饰演的飞行员的代号。——译者注

4http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1667567

好的架构带来敏捷

产生这个讨论的动力是好的软件架构能带来敏捷。尽管面向服务的架构（SOA5）因为过于复杂、臃肿和粗糙的实现而被一些组织看作肮脏的词汇，但软件系统由小型微服务6构成仍呈一种增长趋势，每个服务只专注做好一件事。一个微服务通常可能不到100行代码。如果需要改变，服务可以用另一种语言重新编写。这种架构风格以多种方式提供了敏捷。小型、松耦合的组件和服务可以孤立地构建、修改和测试，甚至根据需求变化移除和替换。因为能够加入新组件、服务并在需要时扩展，这种架构风格也很适合非常灵活和可适配的部署模型。

5Service-Oriented Architecture,http://en.wikipedia.org/wiki/Service-oriented_architecture。——译者注

6http://www.infoq.com/presentations/Micro-Services

然而，天上不会掉馅饼。构建一个这样的软件系统需要时间、精力和准则。很多人也不需要这种水平的适应性和敏捷性，这就是为什么你看到那么多团队构建的软件系统实际上整体感强得多，各部分捆绑在一起并以单一单元部署。尽管更易于构建，然而这种架构风格在面对变化的需求时通常要花费更多精力去适配，因为功能往往交织在代码库中。

不同的软件架构提供不同层次的敏捷

在我看来，两种架构风格各有优缺点，应该在权衡利弊之后，再决定是构架一个整体系统还是几个微系统。和IT行业中所有的事情一样，在这两者之间也有中间地带。抱着实用主义的想法，你总能选择构建一个由很多定义好的小组件构成，但仍作为单一单元部署的软件系统。这也让你有可能在将来轻松地迁移到微服务架构。

你需要有多敏捷

理解组织或业务变化的速度很重要，因为这能帮助你决定采用何种架构风格，可能是整体架构、微服务架构或者介于两者之间。要理解这种权衡并做出相应的选择。敏捷不是白来的。