2

我还没有开始学习这两者中的任何一个，但我想知道你们中是否有人使用敏捷方法来实现 SOA？

谢谢

4

3 回答 3

6

所以问题是：SOA 和敏捷是朋友还是敌人？

总之，面向服务的架构 (SOA) 和敏捷软件开发都可以帮助公司变得更加灵活，并更好地协调业务和 IT。因此，许多人注意到 SOA 和敏捷似乎是天作之合。

SOA 引入了一个受控环境，在其中适应变化以支持敏捷过程，通过应用设计模式、标准和治理程序来提高质量、效率和生产力。仅举几例，诸如服务可重用性、可组合性和抽象性之类的设计模式被用来提供灵活和适应性强的生态系统。敏捷方法还使生命周期更具增量性和交互性，允许企业更快地从 IT 获取/提供反馈。它们都支持允许企业制定与 IT 相一致的战略所需的持续业务-IT 周期。——SOA给敏捷带来了什么？还是从敏捷到 SOA？

解释

正如您在SOA Manifesto 2009和Agile Manifesto 2001中看到的那样，有很多共同的价值观，例如敏捷性、灵活性、将变化视为机会等等。由于云计算 [2008]、Web 服务 [2004] 等，一些人将 SOA 视为敏捷的演变。这些撰写宣言的人对瀑布模型不满意，因为客户因交付的软件有限而不满意。客户无法在没有官僚主义的情况下更改要求，有时他们只是在过程中才知道自己想要什么或需要什么，此时已经签订了合同。看起来像 Fred Brooks, Jr 说的“计划扔掉一个 [实施]；无论如何，你会的！” .

所以人们开始以敏捷的方式制作东西。它给客户带来了快乐。不知何故，他们开始对软件感到满意，并且软件比以往任何时候都更加准确，有小错误并且符合要求。

随着分布式系统的 BOOM!，在我看来，从 Google 开始，一些人开始在 Internet 上开发东西，例如公共或私有 Web 服务和外部 API，SOA 的良好实践是流行语。他们写了宣言，它成为了主要的建筑设计。

笔记

  1. 瀑布没有坏也没有错！对于像 NASA 这样的人来说，它仍然很好，并且对于规格不会改变的重要软件也很有效。

  2. 还有更多的架构设计模式，比如层等等。您需要知道的是这种模式是否适合您的项目。也许 SOA 不适合。

  3. 此外，没有银弹！

于 2012-07-23T03:06:11.987 回答
2

是的，我们确实使用敏捷方法来实施 SOA 支持的项目。但是没有人反对不使用敏捷方法。我猜在某些特定项目中，例如国防部或高风险项目，由于也使用了硬控制 SOA，因此不允许使用敏捷。因为这些术语是正交的。

于 2012-07-23T09:41:49.457 回答
2

全职从事 SOA 实施工作，我对此有一些经验。

您可以使用不同的方法在组织中实施 SOA。我没有看到任何尝试进入并在一个项目中将整个企业集成设计重新制作为 SOA。相反，一旦业务需求出现或发生变化，这将逐步发生。

通常 SOA 实现中的每个子项目都相当小——通常太小而无法划分为带有生产版本的 SCRUM 冲刺。

在许多方面，瀑布方法通常在概念上是实现 SOA 的最简单方法。服务的规格会随着时间的推移而改变，但不可能将其计划为，比如 6 个月的间隔，因为它在很大程度上受到业务需求变化的驱动或受到企业信息系统升级/交换的影响。

但是，当设计阶段完成并确定规范+技术模式时，设计规范可能会有相当多的变化。在实施阶段开始后的项目中。根据我的经验，通常情况下，一旦开始翻转石头，旧的和未知的事情就会爬起来，需要改变。更迭代的方法通常比严格的瀑布方法更便宜——但不一定是敏捷方法。

决定方法的另一个重要因素是项目的融资和设置方式。敏捷方法可能会获得更好的整体结果/现金比率，但前提是您的组织能够应对敏捷方法。如果您作为内部承包商为某些业务需求启用 SOA，我已经习惯了，那么可能会设置项目计划、成本估算和与责任人一起严格的时间表。使用敏捷方法很难为每个单个项目制定时间表，特别是对于中小型 SOA 项目，很难给出明确的成本估算。

对于交付给单个所有者的大型 SOA 项目，我已经成功地使用了 SCRUM，并且非常推荐它。

于 2012-07-23T13:24:17.470 回答