我开始深入研究敏捷，并对某些公司如何推广其版本提出了疑问。我需要了解社区是否同意服务的每月发布周期在理论上与瀑布相同？我的理由是，如果一个团队将几个服务更改/功能捆绑在一起，并每月发布一次大规模的版本，那么这就和瀑布一样了。不是吗"敏捷方式"是在合并时发布每个更改/修复/功能？
敏捷的价值之一是响应计划中的变化。
请注意，它没有指定您需要根据特定的频率或方法进行发布。这是因为敏捷是一种方法，不是一个框架，也不是一种方法论。
一个组织可能能够每月发布一次，并且仍然能够很好地应对变化。这在很大程度上取决于产品的性质和环境。其他组织可能需要在更改/修复/功能准备就绪后立即发布。这两个组织仍然可以遵循敏捷方法。
举一个极端的例子，想象一下一种只有顾客在圣诞节才会使用的产品。频繁发布仍然有价值，因为这有助于降低技术风险，但每次完成新功能时发布可能会被认为是过度的。
关于Scrum的原书《使用Scrum的敏捷软件开发》规定了每月的sprint。然而，它和其他方法通过指定每个sprint创建一个"潜在的可交付产品"来断开sprint与发布的连接，也就是说，断开开发与交付的连接，但出于商业原因，该公司可能不会选择这样做。(顺便说一句，我亲眼目睹的一个原因是，除了安全补丁之外，客户只希望每季度发布一次。(
另一方面，尽管敏捷社区对此存在争议，但持续交付不必被冲刺日期所阻碍：您可以根据需要随时交付，随时获得认可，并使用冲刺结束仪式向利益相关者展示在冲刺期间批准和交付的一切。
作为一名敏捷教练，他保持着瀑布认证(PMP(，因为瀑布适用于某些类型的项目，我认为说敏捷是瀑布的一个子集是一种基于将交付与周期捆绑在一起的误解，这是没有必要的。