SOA和敏捷：是敌是友？
SOA 的目标是以服务作为构建企业应用的“积木块”，使整个企业敏捷起来，而敏捷软件开发则是通过引入一些最佳实践来增加沟通与反馈，以达到同样的目的。哪个是正确的？哪个更好？我们正在拿苹果和桔子做比较吧？它们可以一起使用吗？如果可以，那怎么使用呢？很难用一篇文字来彻头彻尾地评判SOA和敏捷，所以让我们一同来关注它们吧。本文仅是关于这个讨论主题中一系列文章之一，随后将有更多的内容。
方法论和架构是互斥的吗？
有人认为，软件开发实践与架构是不重迭的。在其它环境中这么说也许是正确的，但在这个主题中却不尽然。一方面，敏捷方法（例如XP）直接关注设计，不是特别同意预先做大量设计(BDUF)的观点。另一方面，大多数SOA团队主要是围绕构建一系列服务而组成的功能性团队。SOA本质上鼓励有特性的团队结构和团队间的沟通方式，而这两点又都属于方法论的范畴。
敏捷与SOA是朋友
SOA是一种架构，强调业务必须能满足市场要求，而且通过构建各种服务，可以消除重复，并达成“重用”这一很难捉摸的目标。团队通过构建“服务”而非“应用”，来平衡企业内部和外部的工作。
敏捷是一种方法论，强调事物是变化的，软件开发团队必须拥抱变化，并对变化做出反应。通过引入技术性和非技术性实践，团队可以使业务敏捷起来。
架构和方法论是可以一同使用的，它们本质上是互补的。而且，SOA和敏捷的目标相同，它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以，我们期望在构建SOA时，能够选择敏捷方法论，反之亦然。对吗？
敏捷和SOA是敌人
你可能认为既然目标相同，这两种技术必定是一致的，没有冲突的，也就意味着实践与架构的重迭。但在这一点上，SOA社区和敏捷社区都有不同的声音。为什么会这样呢？
主要原因之一就是，它们的出发点不同，最初的方向也不相同。尽管最近几年敏捷快速发展，社区中获得很多经验并总结了“敏捷宣言”，并将其应用于大项目，但从发展史上看，敏捷还是“草根”，从小项目中走来。而SOA是新兴的，具有自顶向下的本性，使用“分而治之”的方法来进行软件开发。这种方法，尤其是其中的“分割法”,很容易会导致团队间的沟通不畅，如文档、规范等等。
SOA和敏捷在以下三方面有冲突：
SOA鼓励架构设计在前，而敏捷对这种称为“BDUF”的方法持相反观点。
SOA鼓励按功能线索来划分团队，而敏捷倾向于以交叉功能式组建团队。
SOA中，服务一旦建立起来，SOA就不再对服务的变化做出相关的反馈，而敏捷则强调及时反馈，无论是技术层面，还是人的层面。
当前现状
现在，虽然很少有文章涉及这一主题，但我还是找到了几篇文章：
Carl Ververs描述了使用一整套的敏捷实践来构建一个SOA，并与开发人员共同完成了它（见Agile: The SOA Hangover Cure）。遗憾的是，这只是一个团队构建了一套服务。在另一个InfoQ的访谈中，Geoff Henton和Tom Stiehm也讨论了使用敏捷方法构建SOA。这篇文件似乎说的是一个项目中的一套服务，它仅是一个敏捷尝试，内部团队的交流如何？当服务完成后，上百个客户在使用这些服务，此时这些服务需要改变，如何维护呢？我建议：一是SOA团队应通过测试而非文档进行沟通，二是Frank Grossman的观点，但在异构环境中究竟该如何做呢？
此外,根据我对SOA团队的个人观察，从来没有发现有在内部团队方式上做任何敏捷实践的。团队被划分开，实现各自的服务与应用，通过分散的会议、文档和WSDL进行沟通交流。SOA鼓励BDUF，并很少为服务本身可能的变化做准备。
本文比较短，坦白地说，是因为我也不知道答案。这只是该主题上的第一个讨论。我们将以开放的形式进行，总结过程中出现的重要问题并分别讨论它们。欢迎并鼓励任何评论。
查看英文原文：SOA and Agile: Friends or Foes?

SOA和敏捷：是敌是友？
SOA 的目标是以服务作为构建企业应用的“积木块”，使整个企业敏捷起来，而敏捷软件开发则是通过引入一些最佳实践来增加沟通与反馈，以达到同样的目的。哪个是正确的？哪个更好？我们正在拿苹果和桔子做比较吧？它们可以一起使用吗？如果可以，那怎么使用呢？很难用一篇文字来彻头彻尾地评判SOA和敏捷，所以让我们一同来关注它们吧。本文仅是关于这个讨论主题中一系列文章之一，随后将有更多的内容。
方法论和架构是互斥的吗？
有人认为，软件开发实践与架构是不重迭的。在其它环境中这么说也许是正确的，但在这个主题中却不尽然。一方面，敏捷方法（例如XP）直接关注设计，不是特别同意预先做大量设计(BDUF)的观点。另一方面，大多数SOA团队主要是围绕构建一系列服务而组成的功能性团队。SOA本质上鼓励有特性的团队结构和团队间的沟通方式，而这两点又都属于方法论的范畴。
敏捷与SOA是朋友
SOA是一种架构，强调业务必须能满足市场要求，而且通过构建各种服务，可以消除重复，并达成“重用”这一很难捉摸的目标。团队通过构建“服务”而非“应用”，来平衡企业内部和外部的工作。
敏捷是一种方法论，强调事物是变化的，软件开发团队必须拥抱变化，并对变化做出反应。通过引入技术性和非技术性实践，团队可以使业务敏捷起来。
架构和方法论是可以一同使用的，它们本质上是互补的。而且，SOA和敏捷的目标相同，它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以，我们期望在构建SOA时，能够选择敏捷方法论，反之亦然。对吗？
敏捷和SOA是敌人
你可能认为既然目标相同，这两种技术必定是一致的，没有冲突的，也就意味着实践与架构的重迭。但在这一点上，SOA社区和敏捷社区都有不同的声音。为什么会这样呢？
主要原因之一就是，它们的出发点不同，最初的方向也不相同。尽管最近几年敏捷快速发展，社区中获得很多经验并总结了“敏捷宣言”，并将其应用于大项目，但从发展史上看，敏捷还是“草根”，从小项目中走来。而SOA是新兴的，具有自顶向下的本性，使用“分而治之”的方法来进行软件开发。这种方法，尤其是其中的“分割法”,很容易会导致团队间的沟通不畅，如文档、规范等等。
SOA和敏捷在以下三方面有冲突：
SOA鼓励架构设计在前，而敏捷对这种称为“BDUF”的方法持相反观点。
SOA鼓励按功能线索来划分团队，而敏捷倾向于以交叉功能式组建团队。
SOA中，服务一旦建立起来，SOA就不再对服务的变化做出相关的反馈，而敏捷则强调及时反馈，无论是技术层面，还是人的层面。
当前现状
现在，虽然很少有文章涉及这一主题，但我还是找到了几篇文章：
Carl Ververs描述了使用一整套的敏捷实践来构建一个SOA，并与开发人员共同完成了它（见Agile: The SOA Hangover Cure）。遗憾的是，这只是一个团队构建了一套服务。在另一个InfoQ的访谈中，Geoff Henton和Tom Stiehm也讨论了使用敏捷方法构建SOA。这篇文件似乎说的是一个项目中的一套服务，它仅是一个敏捷尝试，内部团队的交流如何？当服务完成后，上百个客户在使用这些服务，此时这些服务需要改变，如何维护呢？我建议：一是SOA团队应通过测试而非文档进行沟通，二是Frank Grossman的观点，但在异构环境中究竟该如何做呢？
此外,根据我对SOA团队的个人观察，从来没有发现有在内部团队方式上做任何敏捷实践的。团队被划分开，实现各自的服务与应用，通过分散的会议、文档和WSDL进行沟通交流。SOA鼓励BDUF，并很少为服务本身可能的变化做准备。
本文比较短，坦白地说，是因为我也不知道答案。这只是该主题上的第一个讨论。我们将以开放的形式进行，总结过程中出现的重要问题并分别讨论它们。欢迎并鼓励任何评论。
查看英文原文：SOA and Agile: Friends or Foes?