是任何 IT 组织都可以使用并可以从中获益的实践。
InfoQ：在文中你提到了频繁反馈循环。那么在项目中，您是如何跟踪您这种混合方法的有效性的呢？
TS：我们使用标准的敏捷实践来跟踪我们的工作和反馈循环。这包括发布计划、迭代计划、迭代 kickoff 会议、需求收集，每个迭代末尾的 UAT（User accessence Test）以及项目回顾。我们还有项目 steering meeting，使客户可以向项目领导层反馈，而不涉及项目团队成员。
有效性使用客户对应用和服务所提供的价值的满意度进行衡量。这属于主观度量，当然还有其它一些度量，包括上市时间、设计的灵活性，业务流程或应用的变化所节省的时间，增加新业务过程和应用所节省的时间等。
InfoQ：你能举个例子说明一下在 SOA 项目中，如何使用“Keep it simple（保持简洁）”原则吗？
TS：对于 Agile-SOA 的“Keep it simple”原则，最好的例子就是直到部署到实际运行环境中才最后确定你的 WSDL（它也是那个 WSDL 的唯一一个版本）。我看到过 SOA 项目在设计阶段以后就把 WSDL 固定下来。在面对灵活多变的需求时，WSDL 就会变得毫无意义。由于 WSDL 是服务提供方和服务使用方之间的接口，所以很难在写任何代码之前一次就把它完全正确的定义下来并一直使用。只有在实际运行环境中，固定不变的服务接口才是合理的（即，真正可以工作并通过了 QA 验证的代码）。而在开发该服务的过程中，一个固定不变却没有经过验证的接口是不合理的。
一个好的“keep it simple”原则是：除非某个功能至少有两个使用者，否则就不应该把功能做成服务。使用了 SOA 以后，就有创建大量不必要的服务的趋势，一种“build it and they will come”的思想。尽管服务很好，它能够使你的应用更灵活，但它也增加了你代码基础和测试策略的复杂性。
InfoQ：这个项目花费了多长时间？您估计项目使用原有的范例会用多长时间？您那时是根据什么做出这个估算的？
TS：创造这个方法用了一个月，但我想你不是指这个。使用这个方法的初始项目还在进行中，我相信它会在一年半内完成。
“原有的范例”是个有趣的提法。您是指原来客户使用的 C/S 结构程序，还是瀑布式 SOA，或严格的敏捷方法（不包含 SOA 的因素）？
客户正打算更换他们的 C/S 应用，而且不想用原有技术来构建新项目。也就是说，我想他们会在两年内重新实现一个现在正在使用的 C/S 应用系统。得出这样的结论是基于我对 C/S 开发方式的了解，以及我与客户方原有 C/S 系统的开发人员的讨论。
根据我对 IBM 公司宣传的 SOA 方法论的理解，我估计使用类似瀑布式的 SOA 方法构建这个项目，至少要花两年的时间，可能会更长。我觉得客户能够看到项目成果并提供反馈就至少是一年以后的事情了。这就带来了一个风险，即在这个应用软件投入使用之前，业务需求可能已经发生了变化，而那时已建好的服务已经没有什么用处了。
而使用敏捷方法重建原来那个 C/S 应用的功能并改为 Web 应用，可能花费的时间应该在一年到一年半之间，其依据就是我评估其它敏捷项目所得到的经验。另外，我相信使用 Agile-SOA 方法可能会在时间上增加 25~35%，但换回来的是可用的服务。
InfoQ：你们真的可以迭代式地交付可以工作的服务吗？也就是说，这些服务在项目结束之前就可以用吗？
TS：是的，我们已经有一些服务发布并正在被使用，而这个项目还在进行中。改进还没有投入使用的服务肯定是很容易的，但是当你考虑服务的版本以及向下兼容性时，你才能不断地交付有用的服务。
InfoQ：非常感谢，Tom。祝项目未完成的内容成功！
对 Digital Focus 案例的研究中发现确保 SOA 成功的关键要素有四个，它们是：
理解客户需要实现的业务过程；
理解 SOA 架构与模式；
采纳一个 SOA 平台，使其可以随着 SOA 应用的进化而成长；
从客户和开发团队那里得到及时且频繁的反馈，以修正出现的问题。
以下是他们自己做 Agile SOA 项目中开发的六个步骤：
第一步：SOA 的介绍与培训；
第二步：将 SOA 与敏捷方法相结合；
第三步：定义长期的业务目标；
第四步：使用业务流程建模标识待定服务；
第五步：定义一个初始的软件平台；
第六步：定义并实现一个自包含的应用或子应用，作为你第一个发布计划的交付物。
你可以在 Digital Focus 的网站上看到这个案例研究：
