Schwaber & Beedle 的“scrum”书（以及我读过的其他 scrum 文献）似乎专注于在 sprint 结束时拥有可发布的产品。已建立站点的 Web 开发（至少在我们的例子中）包括开发“增强”（各种大小）和许多小的“修复”。仅在 sprint 结束时部署（到 Web）会减慢我们对大型增强功能的部署（可能是一件好事），但会大大减慢我们对小型增强功能和修复的部署（即错误停留时间更长）。
Scrum 中的中期 sprint 部署是异端吗？冲刺甚至适用于我们的案例吗？我是否完全误解了 sprint？
我真的认为在冲刺中期部署到生产环境听起来是个坏主意。一个真正的焦点窃取者。
也许缩短冲刺长度对你来说是件好事？
在 Sprint 结束时完成的工作必须由产品负责人在评审会议期间进行评审。如果您在中途释放，情况可能并非如此。
如果你觉得在 sprint 结束之前工作已经完成，你可以：
鉴于您的工作环境描述，我会选择 2。
您可能还想考虑另一种可能更适合您的环境的敏捷方法。
我不会在冲刺中期发布。
在 sprint 结束时拥有可发布的内容并不排除在 sprint 中期发布。事实上，当您的团队承担生产支持职责时，这是必需的。
不过，我会问一些关于这些冲刺中期版本的问题：
1）早期版本的增量价值是否超过部署成本？2) 您是否评估了每个小型部署的风险，以确保它们不会适得其反并创造更多工作？3) 你能否获得客户对这些迷你版本的反馈，以确保你发布他们想要的东西？4）您是否考虑过缩短冲刺时间？
“严格的 scrum 驱动开发”（上面提到的）对我来说是矛盾的。口头禅是检查和适应。有人认为 Scrum 被用作反对提高对利益相关者的响应能力的学说，我对此感到恼火。
如果您想执行严格的 Scrum 驱动开发 - 那么中期 sprint 部署是异端。在我看来，这是一种严格的 scrum 方法，而不是用于场景的最佳工具。我会使用一种更经典的方法，您可以在其中定义部署包和指定给它们的任务。您在单个主干上开发，如果给定部署包的所有任务都已完成 - 您部署它。但请注意代码和项目中的约束。
你可以看看 Alistair Cockburn Crystal “Orange Web” 方法。他将敏捷原则与公共网站的限制相结合。