们真正想要的软件，而且又不能拿出资金再做一次。对于开发者呢，他们会感到他们的时间和天才被白白的浪费了，因为他们花时间建造了这个应用软件却没有人用。业务部门为软件买单，却未能得到提高生产效率的好处。
另一方面，当你使业务与 IT 结合在一起，交付可用的解决方案时，双方都获得了成功。用户得到了他们可以使用的软件，业务部门得到了投资回报（ROI），而开发人员看到软件投入生产，得到了满足。
InfoQ：Thomas，你能给我们讲一下这个项目的更多细节吗？在组织中，哪些团队参与其中了？
TS：主要的业务客户是 FHLB-OF 的 Debt Servicing Group 以及和我们一同工作的客户的 IT 部门。开发团队由 Digital Focus 和客户的开发人员共同组成。我们也与系统集成团队一起工作，将发布的软件投入运行。纵向上是 Mortgage-related Financial Services。
项目的目标是取代 FHLB-OF 的 Debt Servicing Sytem(DSS)。这个部门每天使用 DSS 进行公债和其它债务的服务。对于 12 个 FHLB 来说，Debt Service 是非常关键的业务功能，服务必须有效且及时。
InfoQ：在这个 SOA 项之目前，你们与 FHLB-OF 在做哪方面的工作？
TS：在 Digital Focus 做典型的敏捷培训工作。不过我不是教练，另一个名叫 Tony Batucan 的教练在做这个项目。
InfoQ：那么，看来 FHLB-OF 喜欢将你们的敏捷方法充分应用于软件项目中，看看有什么不同。您是如何把敏捷方法引入 SOA 的呢？是你们发明了这种方法吗？
TS：是的，我们有一个四人团队创造了这个 Agile-SOA 方法。我们在 Agile 和 SOA 两方面都有专家。例如，我们使用敏捷方法交付项目已经有 5 年历史了。Jeff Nielsen 是 Digital Focus 的首席科学家和首席敏捷教练。他和我们一起将敏捷的价值带入了 Agile-SOA。我已经交付了很多基于服务的老系统（这些系统所用的技术要比现在的 SOA 工具要老），也有一些使用当前 SOA 技术的面向服务的系统。团队有还有一个人在分布式企业架构方面很有经验。
组建团队以后，我们把自己关在客户的一间会议室里长达一个月之久。在那里揣摩 Agile-SOA 方法的细节。我们甚至用 Agile 方法写了一个 Agile-SOA 方法。由于我们用一个月的时间去开发一种方法，并与我们的客户要在一个随后的项目中实现它，我们决定以每日迭代的方式来工作。我们每天早上有一个 Standup 会议，来讨论前一天的工作和当天的工作。同时计划下一步做什么，以及当天下午的可交付物。每天下午，我们会与客户一起讨论我们的进度，以及从昨天会议以后做完的工作。讨论进度以后，我们还会讨论明天将会交付给客户的功能，并确保我们理解了它们。我们也用这个会议来回顾项目并讨论任何存在的问题。与用户的会议以后，团队内部讨论从客户那里得到的反馈和新的需求。这个最后的会议结束了这个迭代，迎接下一天的开始。
这个项目的最困难的一个方面就是时间短，而团队成员本来已经很满的时间安排使其更加困难。而敏捷实践和极短迭代的就用，使我们可以平衡团队成员的时间安排。例如，Jeff 不能每天在客户现场。但他希望把他的方法的主题直接讲给客户听。所以，我们安排了 topic reviews，以便 Jeff 可以直接从客户那里得到反馈。
在项目最初一个月的月未，我们交付了 80 页的 Aigle-SOA 迁移文档，该文档向客户介绍了 SOA 和 Agile-SOA 实践。从第二天起，我们使用 Agile-SOA 方法为客户开始实现初期的 SOA 应用。
InfoQ：你们的迭代周期是多长时间？如何确定这个时间长度？
TS：在编写 Agile-SOA 方法的时候，我们使用每日一个迭代。选择这个时间长度是因为它让我们可以在有限的时间里可以得到最多的客户反馈。而对于真正的软件开发，我们用两周进行一个迭代。选择两周这个时长是因为它是 Digital Focus 公司默认的一个迭代周期。
InfoQ：这个方法也应用在其它项目上了吗？还是需要根据每个项目的不同都在项目开始开发一套类似的过程？
TS：这个方法与具体客户还是有一些关系的，但受影响的范围不会超过整个方法的 10%。和其它方法一样，这个方法的某个方面可能还是需要根据项目的不同而重新调整一下。
也就是说，我们开发的这个方法是可以应用到其它项目中的。我们开发该方法时考虑到了通用的 Agile-SOA 开发。我们的客户想要一种在未来 10 年中均可以应用到他们项目的方法，所以这个方法中的实践都是纯粹的软件工程实践，
