哪些发行管理方面的内容有助于解释Waterfall和Agile之间的区别？

在向某人解释DevOps时，碰巧会出现一个问题，例如：

使用敏捷方法的发布管理与Waterfall有何不同？

那么，您可以使用哪种标准来向此类受众解释这些差异？

IMO DevOps是一种文化，很像敏捷（无需选择敏捷方法论。）因此，您不必“做” DevOps。

您可以“开发”一种称为“持续交付”的发行方法，作为DevOps文化的一部分。（全面披露，我认为我以前从未将CD称为发行方法，但是在我处于滞后状态时，我认为它是可行的）

如果您愿意购买，那么这是连续书信的定义，该书的作者之一是同名书的作者Jez Humble。

连续交付是一种以可持续的方式安全快速地将所有类型的变更（包括新功能，配置变更，错误修复和实验）投入生产或交付用户的功能。

我们的目标是使部署（无论是大型分布式系统，复杂的生产环境，嵌入式系统还是应用程序）可预测，可以按需执行的日常事务。

通过确保代码始终处于可部署状态，即使面对成千上万的开发人员团队每天进行更改，我们也可以实现所有这些目标。因此，我们完全消除了传统上“开发完成”之后的集成，测试和强化阶段以及代码冻结。

这样，您就可以采用敏捷方法论，拥有可以向企业展示的软件，确保您正在执行正确的自动化测试，对更改以及对所有更改所做的一切都做出很好的反应，使其比瀑布更好。很多时候，这并不意味着您实际上可以将其部署到生产中。

您最终得到这样的结果：

因此，如果您没有某种迭代方法，那么完成该软件后（可能）会更好，但是您实际上并不知道，因为实际用户从未见过。

您真正想要的是看起来更像这样的东西：

每次迭代，都会有一些东西部署到生产中。这样就部署了软件。如果您决定创建下载文件，请打开Web服务器，或者将软件交付给发布它的用户。

有没有搞错！？我问了DevOps！没有人问到持续交付！

那么DevOps与这有什么关系呢？

要真正使您的软件真正处于一种可以在任何时候部署它的状态下，这都是非常非常非常困难的（无法实现），除非该团队正在DevOps文化中工作。一种文化，其中系统管理员，DBA，SRE，安全人员，开发人员，质量保证等都属于单个团队，而不是组织中交接独立的一部分。

注意事项：

关于此答案的评论的一部分，就像这样：

关于您的“……软件处于随时可以部署的状态……”：这使我想起了“自动驾驶”软件（在飞机上）……我最喜欢的问题：“ 想象一个更新应用于此类软件...机上感觉如何...当您在机上时？ ”。

我喜欢这个问题（在以上引用中以粗体显示）！“它真的准备好了吗？”的想法 我一直都在抱怨- 博客。IMO至关重要的是，您必须对安全性，性能和其他经常进行的“次级”测试充满信心才能练习CD。功能完成后就完成了，但是黑客总是在那儿。

不知道是否没有其他人，但这是我使用的标准：

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

而且，如果您真的想以使用某些软件的方式来体验与众不同，那么可以考虑使用某些软件（例如Linux发行版），您可以在使用这两个发行版之间进行选择：

• 一个“ Rolling”版本（==>敏捷）。

• 一个“ Long Term Support”版本（==>瀑布）。