本文是由两部分组成的系列文章的第 1 部分，阐述了普遍接受的方法学（例如 Scrum、极限编程（Extreme Programming，XP）、Crystal、动态系统开发方法（Dynamic Systems Development Method，DSDM）和主要研究精益软件开发（Lean Software Development，LSD）的其他方法学）内包含的敏捷开发的基本原则。当今，必须提高业务的灵活性和速度，以应对不断变化的客户需求、市场机会和外部竞争对手的威胁。为使这些业务得以成功，可以采用面向服务的体系结构 (SOA) 的开发方法来设计以适应性（对变化和需求做出响应的能力）为目标的 IT 系统。本系列的第 2 部分详细描述了它们用于开发 SOA 的适应性。
引言
面向服务的体系结构 (SOA) 由 Mark Colan 等受人尊敬的思想领袖定义和阐述（请参阅“Service-Oriented Architecture expands the vision of Web services, Part 1”），作为普遍接受的用于设计可适应的、企业级 IT 系统的新兴风格，它已经得到了很大的发展。虽然目标十分明确，但实现目标的方法却并非如此，因为还没有受到广泛接受的 SOA 方法学。不过，在这方面还是进行了一些研究（请参见 SOA 的方法学）的。
负责设计 SOA 的每个人都会面对两个主要挑战：1) 如何设计一个系统来很好地适应业务流程、业务目标和 IT 体系结构，2) 如何构建一个能对将来的变化做出响应的体系结构？第二个挑战与敏捷性相关，通常在敏捷软件开发方法的背景下进行讨论。在本文中，我们将介绍如何将此方法的思想扩展到 SOA 的设计。我们先回顾一些最常见的敏捷开发方法，然后再研究“精益软件开发”(LSD) 的原则。最后，我们讨论在构建 SOA 的过程中对 LSD 的初步分析。
SOA 入门
什么是 SOA？
在构建 IT 体系结构（特别是企业级体系结构）时，我们的目标始终是：支持业务流程并对业务变化做出响应。在最近几年中，出现了一些构建系统体系结构的新方法，这些方法主要围绕功能单元（称为服务）来构建复杂的系统。
最新的理解是，服务包含 4 个主要方面：
Web 服务也对以上这几个方面提供基于系统和标准的支持。因此，Web 服务具有无与伦比的敏捷性这一优点。例如，使用 Web 服务基础设施可以在运行时更改服务提供者，而不影响使用者。
某个系统本身要被称为基于 SOA 的系统，应具备以下特性：
- 业务流程映射到软件服务；因此，业务可通过软件进行跟踪。
- 存在一种基础结构，支持上述服务的 4 个不同方面。这样服务级别就具有高度的敏捷性。
- 服务是监视和管理单元。因此，一个人可以跟踪业务流程的操作属性和问题。
SOA 应用程序
图 1 从应用程序角度展示了企业级 SOA 所包含的元素。业务流程 由用户界面应用程序 和服务应用程序 进行部分和完全支持。业务流程中的一个步骤或者通过人工执行，或者得到用户界面应用程序的支持。用户界面应用程序实现了许多宏工作流，而且它们还使用实现业务功能的服务。
在服务编排 层，组合服务 是通过编排语言（例如业务流程执行语言（Business Process Execution Language，BPEL））定义的。组合服务的编排通过基本服务 定义其流程和组成。编排层应由支持图形规范的编排工具提供支持，例如 IBM WebSphere® Business Integration Modeler 和 IBM Rational® Application Developer。
基本服务（由服务编排层使用，也由用户界面应用程序使用）通过服务应用程序实现。而服务实现又可以调用其他服务，这些服务通常来自另外的服务应用程序。
图 1. SOA 的元素
SOA 的方法学
构建一个合理的 SOA 应采用何种开发方法？从前面的部分可以看出，有业务流程、应用程序和服务。显然，对服务建模是此类方法必须支持的主要任务。另一个重要的方面是确保业务流程和服务之间的链接（请参见什么是 SOA）。
文章“Elements of Service-Oriented Analysis and Design”说明了现有的模型（例如面向对象的分析和设计（Object-Oriented Analysis and Design，OOAD）、企业体系结构框架和业务流程建模技术）对 SOA 设计的作用。本文还指出，您需要将其他方法元素用于 SOA，例如用于服务标识和聚合的方法和技术、业务跟踪能力、现有资产的集成和重用。
在另一篇 IBM developerWorks 文章“Service-oriented modeling and architecture”中描述了一种方法，回答了上述许多问题。本文主要介绍服务的建模，它是在域分解、现有系统分析和目标服务建模之类的技术支持下实现的。
引用的这两篇文章提出了许多问题，我们仍需要回答这些问题——例如，SOA 控制问题。我们要提出的另一个问题是：在 SOA 开发中应采用哪些规则和实践来确保服务模型能对将来的变化做出响应？在这里，我们可以求助于各种敏捷软件开发方法。
敏捷软件开发
敏捷软件开发是自上世纪 90 年代 Kent Beck 提出极限编程 (XP) 时开始兴起的，这种编程方法用一组价值标准、原则和实践来规划、编码、设计和测试软件。（有关对 XP 的介绍，请参见 Extreme Programming: A gentle introduction。）
所有敏捷软件开发方法都具有以下几个共同价值标准，例如
- 频繁检查和改写
- 频繁交付
- 协作和密切沟通
- 深思熟虑的改进
- 突出需求（递增）、技术和团队能力
- 授权和自我组织
- 基于事实而非假象进行处理
- 勇气和尊重
从这些价值标准可以看出，现在使用的各种敏捷方法都注重不同的实践。
2001 年 2 月定义了 Agile Manifesto，它在流程和工具的基础上评价个体和交互操作，在综合性文档的基础上使用软件，在合共协商的基础上进行客户合作，并在遵循计划的基础上对变更做出响应。它是现今使用的所有敏捷方法的基础。
为了使本文的阐述更加清楚，我们简要介绍了最常用的敏捷方法，因为在开发 SOA 时它们中的许多都是非常有用的。我们知道，SOA 不仅与软件开发有关，而且还与业务和 IT 体系结构有关。因此，如果我们了解软件开发实践，则我们必须始终评估它们是否适合 SOA。在本系列文章的第 2 部分中完成此评估。
Scrum
Scrum 似乎是很简单的，但仍有一些实践会对工作体验产生深远的影响，并获得重要的适应性和敏捷性。在这些方法中，Scrum 与众不同的特点是对自我指导团队、每日团队评估和避免说明性流程进行了极大的提升。Scrum 的一些关键实践包括：
- 自我指导和自我组织团队
- 每日就特殊问题（您做了什么、您将做什么和您遇到哪些问题）开站立会议
- 通常采用 30 天的日历循环
- 在每个循环的开始，制订客户驱动的适应计划
- 向参与者演示功能（在每个循环结束时）
对于企业级活动，了解和管理项目间的依赖项非常重要。在 Scrum 中使用“Global Backlog”就可以很好地做到这一点，Global Backlog 是对用户有价值的功能和非功能需求的企业视图。Global Backlog 在全局区分优先级。每个项目从 Global Backlog 获得项目范围内的最重要的部分。“Scrum of Scrums”还涉及项目间的同步，这是一个每两天（或每周）一次的会议，来自每个团队的代表参加这个会议，以便在团队之间同步。
XP
XP（http://www.extremeprogramming.org 和 http://www.xprogramming.com）注重协作、快速和早期软件创建以及有技巧的开发实践。它由一组主要实践（坐在一起、整个团队、信息工作空间、成对编程、每周循环、放松、10 分钟构建、持续集成、测试优先编程、增量设计等等）和一组与之对应的实践（实际客户参与、增量和每日部署、根源分析、共享代码、单独的代码库、协商的范围合同、根据使用情况计费等）组成。
Crystal
Crystal 是具有以下共同特征的一系列方法学：注重频繁交付、密切沟通和深思熟虑的改进。Crystal 的这些特征包括：
Crystal 系列通用优先级可以保证项目的最终成果，提高开发效率，并且符合常规习惯（换句话说，开发人员可以接受它们）。项目团队可以采用 7 个安全特性（前 3 个是 Crystal 的核心，而其余的可以按任何顺序添加，以增加安全性）：
- 频繁交付
- 深思熟虑的改进
- 密切沟通；个人安全（信任的第一步）
- 聚焦
- 易于访问专家用户
- 带自动测试的技术环境
- 配置管理
- 频繁集成
动态系统开发方法
动态系统开发方法 (DSDM) 提供了一个用于构建和维护系统的控件框架，该框架满足紧急时间限制的要求，而且是成功进行可重复快速应用程序开发 (RAD) 的一剂药方。该方法不仅涉及开发人员对 RAD 的看法，而且还涉及对有效系统开发感兴趣的所有其他相关各方（包括用户、项目经理和质量保证人员）对 RAD 的看法。下面列出了 DSDM 的控制原则：
- 活动用户必须参与。
- 必须授权 DSDM 团队进行决策。
- 注重频繁交付产品。
- 判断产品是否可接受的一个基本标准是要符合业务目的。
- 对准确的业务解决方案需要采用循环和增量开发。
- 开发期间的所有更改都是可逆的。
- 基本要求是高层次的并区分优先级（以在低优先级的项目上获得一定的灵活性）。
- 在整个生命周期集成测试。
- 在所有参与者之间采用协作和合作方法是一项基本要求。
精益生产
制造业已经意识到存在两种生产问题——“可预测的生产”和“新产品开发”。前者的特征是确保具有提前了解需求的能力，因而可以制订确定性计划。后者的特征是没有事先明确了解需求的能力，因而需要随项目的进展不断地调整适应和重新评估。
Craig Larman 在他所著的 Agile and Iterative Development一书中对这些问题做了比较，得出以下结论：
表 1. 可预测的生产和新产品开发的比较
| 可预测的生产 | 新产品开发 |
| 可以首先完成规范，然后再构建。 | 几乎不可能创建提前的、不变的和详细的规范。 |
| 在即将开始时，可以可靠地评估所投入的精力和成本。 | 在即将开始时这是不可能的。随着经验数据的不断出现，进行计划和评估的可能性越来越大。 |
| 可以对所有详细活动进行标识、定义、安排和排序。 | 在即将开始时这是不可能的。需要采用通过构建反馈循环驱动的适应性步骤。 |
| 适应不可预测的变更不是标准要求，而且变更速度相对较慢。 | 创造性地适应不可预测的变更是标准要求。变更速度较快。 |
例如，Toyota 在上世纪 80 年代使用“精益生产”方法对其汽车工业进行大规模改革，目的是消除浪费，精简价值链（甚至跨所有企业），按需求生产（实时生产），并注重增值人员。
LSD
Mary 和 Tom Poppendieck 已将这些原则和实践从生产环境转用到开发环境（有关详细信息，请参见他们的网站），目标是在整个持续改进期间确定和消除浪费，并减少缺陷和循环时间，而同时稳定地增加商业价值。LSD 的基础就在于诸如 Toyota、Dell 和 Wal-Mart 这些组织所采用的一组“精益生产”标准。
需要注意的重要一点是，像 XP、DSDM、SCRUM 等其他方法一样，LSD 在本质上并不是一种开发方法，而是提供许多应该应用于改进软件开发的基本原则，不考虑使用的开发方法和项目方法。本文的其余部分将快速回顾 LSD 的七个原则和一些工具（例如，下文中用斜体列出的思想）。
原则 1：消除浪费
消除浪费是最基本的精益原则。它是所有其他原则应遵循的原则。实现精益开发的第一步是了解浪费（没有提高代码质量，没有减少生产代码所需的时间和精力，或没有向顾客提供商业价值的任何东西）。第二步是公开最大的浪费源并消除它们。大量研究表明，在早期规范定义的功能中，最多有 45% 的功能在解决方案完成和交付后从未使用过。
原则 2：加强学习
在组织面对软件开发挑战时，往往在组织中安排一个用纪律强加约束的流程，这个流程有更严格的顺序关系。控制理论指出，这种做法会使情况变得更糟。当问题出现时，要做的第一件事是确保反馈循环都各司其职。要做的第二件事是在问题领域增加反馈循环的频率，因为短反馈循环将增强控制能力。
只要有几个人正在做同一件事，就需要进行“同步”。对同步的要求是任何复杂开发流程的基础。“循环”是同步的关键点（团队和客户将了解完成的任务）并强制做出决策。
原则 3：尽可能推迟做出决定
在开发开始前确定需求是防止出现严重问题的一种通常的做法。顺序开发（例如瀑布开发模式）的问题是，它强制设计人员采用深度优先而非广度优先方法。最容易犯大错误的方式是深入研究细节的速度太快。
对于并行开发（例如，所有工作都在循环——即分析、设计、编程和测试——中完成），只要高级概念设计一确定，您就开始对具有最高价值的功能进行编程，甚至此时详细需求还在调查之中。这种探索性方法允许尝试各种选择，然后即可确定限制实现较不重要功能的做法（“选择思考”）。但并行开发要求开发人员在领域内具有足够的专门知识（以预期新兴设计可能的发展方向），并与客户和分析人员（他们设计系统如何解决现有的业务问题）进行密切合作。
原则 4. 尽快交付
客户喜欢快速交付，这常常转化为业务灵活性的提高。对软件开发而言，快速交付是一种选择友好的方法。它允许您暂时不做出选择，直到您减少了不确定性，然后可以做出更明智的基于事实的决策。
所有人都必须始终明白，她或他应如何做才能对业务做出最有效的贡献。您可以告诉他们要做什么（“命令和控制”），也可以搭建一个舞台，让他们自己发挥（“自我组织”）。在快速变化的环境中，只有第二种选择行得通。为了有效地进行自组织，必须开发本地通信和委托方法（例如使用信息发射器）以拉系统 的方式协调工作。在具有适度可变性的复杂环境中，没有任何计划可以做出有效的细粒度工作分配。提早创建详细计划意味着将您的一些决定刻到石头上。进行计划和预期绝非坏事，但要避免根据推测做出不可更改的决定。
快速开发的好处通常大于您的预期。为下几年推出的某种新产品创建简单的经济模型（基本上为损益表 (P&L)），并使用该经济模型推动开发决策。根据市场情况很好地评估哪些延迟将对销售量（例如，早期的高定价损失）和市场份额（例如，市场份额的长期损失）产生影响。该模型将显示在收入和市场份额之间哪种差异将对收益产生影响。
原则 5：向团队授权
通常，改进计划其实并未改变完成工作的方式。这些计划增加了导致工作满意度下降的因素（策略、监督和管理）而没有增加导致工作满意度提高的因素（成绩、认同和责任）。精益思想利用一线工人的聪明才智，相信他们是有能力决定和继续改进其工作方式的人。要是没有遵守纪律、受到激励的人员，软件开发就不能成功，而实验和反馈往往比一次将事情做成更有效。
原则 6：构建完整性
一个产品如果它的各个组件互相匹配并协调工作得很好，则这个产品就具有概念上的完整性；体系结构将在下列各项之间获得有效的平衡：
要获得概念上的完整性，请降低控制机制的重要性，这有利于：
不是从一开始就尝试预测将来的趋势，而是采用宽度优先的方法并保证基本要素正确。然后，让细节浮现出来并对定期重构制订计划，以让体系结构保持健康状态。重构意味着在检测到“异味”时停止工作（例如停止添加新功能），然后在继续开发前，花时间查找和修复问题的根源。
重构只能在测试具有严格的安全保证时才能进行。测试应尽可能自动完成，并作为每日构建和持续构建的一部分运行。请在系统的整个生命周期维护一组综合性测试。这样，系统即可在其有用的生命周期中安全地进行修复和重构。如果没有足够的时间来进行测试，则首先要重新分配在需求文档中编写客户测试所投入的精力。
原则 7：眼观全局
系统越复杂，就越倾向于将系统分为几部分并在本地管理这些部分。本地管理倾向于创建本地性能度量。这些本地度量经常产生导致整体性能降低的系统级结果（局部优化）。虽然 Lance Armstrong 赢得 1999 到 2005 的环法自行车赛的冠军，但他只赢得几次每日登台领奖的机会。就像环法自行车赛，优化每个任务通常是一个很糟糕的策略。
通过知识工作 (knowledge work)，很难度量每件事情是否重要，特别是在每次努力都是唯一性和不确定性占优势时。如果您不能度量每件事情的重要性，则部分度量就很有可能转为本地管理。如果您不能度量优化整体业务目标所需的每件事情，则在没有采用局部优化度量的情况下，最好停止度量。
从项目经理的角度看，在管理项目时，可以调整 4 个变量：时间、成本、质量和范围。在这 4 个变量中，可以修改时间、成本和质量——但范围除外。对功能区分优先级，但不在合同中指定要交付的固定功能集合。从固定范围移到可协商范围的方法：先交付高优先级功能，这样就可以早在完全满足客户的一系列期望前交付具有商业价值的大部分产品。
敏捷体系结构
不预先进行任何宏大设计
软件开发方法采用不同的方法来开发项目的体系结构：Rational Unified Process (RUP) 解决了早期的体系结构风险问题（“如果您没有主动解决风险，则这些风险将会伤及您”），而 XP 要求“不预先进行任何宏大设计”。Scrum 只预先定义足够用的体系结构，但之后以增量的方式交付体系结构——区分优先级的方式与其余的功能相同。
从敏捷的角度看，以下这些做法是不明智的：在项目开始时了解所有需求，分析这些需求，然后为整个系统开发体系结构，就像在瀑布模型中一样。重要的是要平衡早期体系结构稳定性和更改的实现之间的需求。当然，一次又一次地修改重要的体系结构成本非常高。另一方面，如果决策很糟糕且不适合已变化的需求，则越早而非越迟改变决策就越好。
确认而非验证
不论您在开发体系结构时使用何种方法 (approach)，都需要根据用户的期望（而不根据需求）确认体系结构。这种确认只能通过开发部分解决方案（“骨架”、“衍生应用程序”和“曳光弹”）来演示体系结构是可行的。然后，逐步用细节充实体系结构骨架。
何时开展体系结构工作
传统上，在早期项目阶段，体系结构工作进展到何种程度是由开发团队来决定的。某些敏捷开发方法（例如 XP 和 Scrum）将功能需求和非功能需求放在公共 backlog 中，然后让客户优先选择需求。在客户根据商业价值和关键程度对需求进行优先选择后，开发团队评估投入的精力和成本，然后引入可能带来体系结构风险的专门知识。因此，体系结构是随着需求而逐步开发完成的。
最近，有关何时开展体系结构工作的决定已进行合理处理，该决定不仅是技术决定，而且也是商业和财务决定。增量基金方法将需求细分成最小可市场化功能（ Minimum Marketable Features，MMF），并将体系结构细分为体系结构元素（Architecture Elements，AE）。基于启发式方法，MMF 和 AE 按次序来优化各个财务目标（例如最大程度增加 ROI、最大程度减少现金投入、获得较早的回报等）。客户可以了解和评估各个体系结构选项及其财务负担。开发团队将了解提前开发所有体系结构和逐步交付体系结构的财务因素。
传统方法和早期的敏捷方法都是一种“贪婪的方法”：传统方法先“攻击”最具风险的部分，而早期的敏捷方法先“攻击”最有价值的部分。IFM 允许客户和开发团队选择最有益的方法。
服务的持续重构
在 SOA 上下文中，一个应用程序决不会作为单独的应用程序出现。就像我们在 SOA 应用程序中所讲述的那样，服务应用程序有多种用户，因而存在各种应用程序之间的依赖关系，这一点作为服务模型中的服务依赖性清楚描述过。任何服务都应被考虑是否有可能被其他应用程序重用。因此，服务应用程序必须被认为是可重用的产品。实际上，这意味着敏捷性无可置疑地变得更重要了，因为应用程序使用者的数量增加了。这些使用者不仅有最终用户，而且也有成为应用程序的使用者/客户的其他应用程序。随着客户数量的增加，更改的数量当然也会增加，因为并非所有的用户都有预见能力。
在驱动敏捷开发的 SOA 中存在一个中心因素：服务模型，即服务、服务的依赖性、组织和流程的模型。在第一个订单交付后，服务模型就随着时间及服务接口的定义而发展。公司将认识到其服务模型的当前版本具有弱点，因为没有采用正确的方法定义服务的责任。它们不得不将责任从一个服务（或服务的一个版本）移到另一个服务，并更改服务接口。服务模型的重构是无法避免的，并且在敏捷软件开发中，我们鼓励进行持续重构。
重构服务意味着通过将责任从一个服务转移到另一个服务来更改接口。这可以使用服务模型有控制地完成。服务模型成为 SOA 中进行敏捷开发的基本工具，因为没有该工具，就很难控制服务重构。因为我们采用了服务模型，我们准备将敏捷软件开发扩展到 SOA 级别！
从敏捷 SOA 前沿传来一个好消息：敏捷性还变得较容易管理了。通过更改组合服务的服务编排，您可以捕获业务流程中的更改。编排中的更改比基本服务实现中的更改更简单。
结束语
在这个由两部分组成系列文章的第 1 部分，我们介绍了 SOA 的概念、敏捷软件开发和 LSD，并尝试概述敏捷或精益原则和实践对体系结构（包括服务体系结构）的影响。
本系列的第 2 部分尝试将每种精益软件原则与 SOA 开发混合起来。这种混合与文章的第 1 部分“敏捷开发”一章一起，构成了敏捷 SOA 开发的基础。