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开发的基础。

　　作者简介

　　Pl Krogdahl是一名高级IT架构师和IBM EMEA WebSphere Lab Service小组的Method Exponent。他从1998年开始就职于IBM，涉及了多个领域，例如软件开发、售前技术咨询和解决方案体系结构。他擅长的领域包括分布式计算、中间件和应用程序服务体系结构，主要从事EAI和SOA方面的研究。P？l最近撰写了一些范围广泛的文章，探讨的主题有基于SOA的EA、以及它们与IBM用于电子商务和按需操作系统环境的模式的关系。到目前为止，他已经完成了IBM International Technical Support Organization的一些高级培训，在该组织中，他同人合著了一些与WebSphere有关的红皮书，这些红皮书的重点在于Web服务和SOA方面，例如Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。他在快速应用程序开发环境(Rapid Application Development)方面具有丰富的经验。您可以通过pal。krogdahl@se。ibm。com与他联系。
 
　　Gottfried Luef是IBM的一名IT架构师兼顾问，目前在奥地利维也纳工作，为政府领域的各种项目提供Web服务、SOA和J2EE体系结构方面的经验支持。他参与了奥地利政府Web服务标准的制定。Gottfried获得了奥地利维也纳大学(University of Vienna)信息管理博士学位。您可以通过gottfried_luef@at。ibm。com与他联系。
 
　　Christoph Steindl是一名高级IT架构师和IBM的Method Exponent。他从2000年开始就职于IBM，参与了多个软件开发和系统集成项目。他擅长的领域包括应用程序开发、软件工程和方法学。他非常了解各种敏捷开发方法，并且经常就LSD、使用Scrum管理敏捷开发项目、使用Scrum支持XP、分布式敏捷开发、测试驱动的开发、实用的用例模型和敏捷开发项目评估发表演讲。他被Johnannes Kepler University（位于奥地利林茨）和University of Applied Sciences（位于奥地利哈根堡）聘为讲师，并且是认证ScrumMaster。他获得了Johnannes Kepler University（位于奥地利林茨）的计算机科学和机械电子学学位以及电子科学博士学位。您可以通过christoph_steindl@at。ibm。com与他联系。