我还没有开始学习这两者中的任何一个，但我想知道你们是否有人使用敏捷方法来实现SOA？
谢谢
答案 0 :(得分：6)
总之，面向服务的体系结构（SOA）和敏捷软件开发都可以帮助公司变得更加灵活，更好地协调业务和IT。因此，许多人都注意到SOA和敏捷看起来很自然。
SOA引入了一个受控环境，在该环境中，通过设计模式，标准和治理程序的应用，可以在支持敏捷流程的过程中实现变更，从而提高质量，效率和生产力。服务可重用性，可组合性和抽象等设计模式（仅举几例）可用于提供灵活且适应性强的生态系统。敏捷方法还使生命周期更加增量和交互，使业务部门能够从/向IT提供更快的反馈。它们都支持持续的业务IT周期，使企业能够制定与IT一致的战略。 - What does SOA brings to Agile? Or Agile to SOA? 的
正如您在SOA Manifesto 2009和Agile Manifesto 2001中所看到的，有很多共同的价值观，例如敏捷性，灵活性，将变化视为机会等等。由于云计算[2008]，Web服务[2004]等，有些人将SOA视为敏捷的演变。这些撰写宣言的人对Waterfall Model不满意，因为客户因软件交付有限而不满意。客户无法在没有专职的情况下改变要求，有时候他们只知道他们在流程中间想要什么或需要什么，这时合同已经签署了。看起来像弗雷德布鲁克斯，Jr说“打算扔掉一个[实施];无论如何你都会！”。
所以人们开始用敏捷方式做事。它给客户带来了快乐。不知何故，他们开始对软件感到满意，软件比以往任何时候都更准确，并且根据要求有小错误。
对于分布式系统的BOOM !,在我开始使用谷歌时，有些人开始在互联网上开发东西，比如公共或私人网络服务和外部API，而SOA的良好实践是热门话题。他们写了宣言，并成为一个主要的建筑设计。
瀑布不错或错！对于像NASA这样的人来说，它仍然很好，并且适用于规格不会改变的重要软件。
还有更多的建筑设计模式，例如图层等。您需要知道的是，这种模式是否适合您的项目。也许SOA不合适。
此外，没有银弹！
答案 1 :(得分：2)
是的，我们确实使用敏捷方法来实现SOA驱动的项目。但是不反对不使用敏捷方法。我想在一些特定的项目，例如国防部或高风险项目由于硬控制而不允许敏捷使用SOA。因为这个术语是正交的。
答案 2 :(得分：2)
全职参与SOA实施，我对此有一些经验。
您可以使用不同的方法将SOA实施到组织中。我已经看到没有尝试进入并在一个项目中将整个企业集成设计重新制作为SOA。相反，一旦业务需求出现或发生变化，这将逐步发生。
SOA实施中的每个子项目通常都很小 - 通常太小而无法用生产版本划分为SCRUM sprint。
在许多方面，Waterfall方法通常在概念上是实现SOA的最简单方法。随着时间的推移，服务的规格将会发生变化，但是这种情况无法计划，例如6个月的间隔，因为它很大程度上受业务需求变化或企业信息系统升级/交换的影响。
但是，当完成设计阶段并确定规格+技术模式时，设计规范可能会有相当多的变化。在实施阶段开始后的项目中。根据我的经验，通常情况是，一旦开始翻转石头，旧的和未知的标志就会爬上那些需要改变的东西。更iterative方法通常比严格瀑布更便宜 - 但不一定是敏捷方法。
决定方法的另一个重要因素是项目融资和设置的方式。敏捷方法可能会获得更好的整体结果/现金比率，但这只有在您的组织能够应对敏捷方法时才能实现。如果您作为内部承包商为某些业务需求启用SOA（我已经习惯了），则可以设置项目计划，成本估算和具有责任的严格时间表。使用敏捷方法很难保持每个项目的时间表，具体而言，很难为中小型SOA项目提供明确的成本估算。
对于交付给单个所有者的大型SOA项目，我已经成功使用了SCRUM并且真的推荐它。