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