本文探讨了各种方法，例如Scrum、极限编程（Extreme Programming，XP）、Crystal、动态系统开发方法（Dynamic Systems Development Method，DSDM）等等，它们专注于精益软件开发（Lean Software Development，LSD）的概念。在这个由两部分组成的关于敏捷软件开发的系列中，作者详细地评估了它们对于开发面向服务的体系结构（Service-Oriented Architecture，SOA）的适宜性。

　　引言

　　正如我们在本系列的第1部分中所阐释的，面向服务的体系结构(SOA)和敏捷开发两个概念都旨在用于可适应的企业IT系统。然而，在关于SOA开发和敏捷方法的主题的CBDI说明中提到，敏捷开发和SOA，就如同油和水一样，不能溶合在一起。所以，如果头脑中已经有了这样的想法，您还真的可以像SOA那样来将敏捷开发原则扩展到多应用程序环境中吗？在本系列的这一部分中，我们提供了证据来证明答案是“肯定的”。

　　SOA和精益软件开发：Fit-Gap分析

　　通过依次介绍每个精益软件开发原则，我们研究如何使用它们来使SOA的开发从中受益。除此之外，我们还讨论了它们在使用敏捷方法的环境中的好处。下表给出了LSD原则与其在敏捷方法的环境中带给SOA开发和交付的基本好处之间的初始高级映射。

　　表1. LSD与SOA原则的初始映射

　　让我们进一步详细地讨论上面的表1中定义的映射：

　　原则1：消除浪费

　　宽度优先服务模型开发

　　为了理解什么是重要的以及什么是多余的，使用宽度优先(breadth-first)取代深度优先(depth-first)是明智的，先取得总体认识，然后再深入细节。当开发企业级SOA时，您应该避免以遗漏关键部分为代价来预先构建系统无关紧要的部分的详细分析文档目录。当然，很难预知未来和灵活性的需求；因此，快速反馈是必要的。

　　一些来自面向服务的建模和体系结构方法（Service-Oriented Modeling and Architecture Method，SOMA）的技术很好地支持“宽度优先”方法，即：自顶向下(top-down)域分解、自底向上(bottom-up)现有系统分析以及目标-服务建模（请参阅文章“Service-oriented modeling and architecture”）。在经过总体观察以后，决定在服务组合(Service Portfolio)中包含哪些服务。只有到这个时候，您才能详细地定义服务。

　　值流映射

　　映射值流是开始发现流程中的浪费的一种好方法。它把重点放在用户的产品及其价值上，而不是组织、资产、技术、流程和人员上。利用值流映射的结果，您可以将精力投入到给组织带来最多价值的流程和服务上。挑选最大的机会去增加流动和增值时间(value-added time)。您可以利用这项技术来分析业务流程（将由SOA支持）或者软件开发流程（用于开发SOA）。

　　原则2：加强学习

　　反馈

　　服务的“用户”是应用程序。预先设计一个用于所有应用程序的最佳重用的服务接口是不可能的。实际上，您是从初始的接口和演示程序开始，然后部署服务，最后从使用的应用程序获得反馈。一个小先遣队开发了一个简单跨系统的试验应用程序：

　　·采用一个业务流程
　　·分析和设计它的服务
　　·原型化用户接口
　　·与后端集成
　　·跨整个流程

　　如果可能，试验应用程序应该变成产品。当这种跨系统的应用程序在生产中得到证实时，您就知道了您有了可工作的应用程序。到了那时，多个小组就可以使用一样的方法并且每次进行多项工作。

　　与采用瀑布方式开发整个SOA相比，依赖于快速交付和频繁反馈甚至更为重要，这是因为您不可能第一次就做出正确的设计。敏捷方法推动了快速反馈和热点(Hot Spot)的出现，这里需要灵活性。工程实践（例如测试优先开发和持续集成）减少了开发人员获得反馈的时间。增量功能的频繁交付支持来自客户或用户的直接反馈。

　　同步

　　敏捷方法至少使项目间的依赖关系可见，并且还有一些处理它们的工具（请参阅本系列第1部分中的Scrum部分）。项目间频繁同步的想法在服务的实现阶段特别有用，这里可能发生服务范围内的改变，因为正是在这一阶段详细地分析服务。

　　原则3：尽可能晚地决定

　　不确定服务接口的细节

　　在像SOA这样企业级的约定中，似乎最好是在非常详细的层次上设计服务接口，让不同的项目来实现它们。这种方法的优点好像是服务应用程序可以独自工作，而不需要长期地与其他项目同步。遗憾的是，这并不能正常工作，因为您无法预先确定所有的细节。面对不确定性，这样做的结果就是导致浪费（以错误的细节的方式）。长期进行来实现错误细节的项目将难以使它们的代码解构变得简单。这会产生一个未达到最佳状态、却又固定的服务模型。

　　尽可能晚地决定意味着，在有证据可以清楚地判断服务应该是什么样子之前，不确定服务接口的细节，而不是假装无所不知。这就促使开发小组与公司的其他部门经常性地保持步调一致，而且它还产生更好的服务模型。