使用scrum部署mid-sprint (大型的正在进行的'brownfield‘公共web项目)

Question

Schwaber & Beedle's 'scrum' book (以及我读过的其他scrum文献)似乎关注的是在sprint结束时发布一个可发布的产品。一个已建立的网站的Web开发(至少在我们的例子中)包括开发“增强”(各种大小)和许多小的“修复”。仅在sprint结束时部署(到web)将减慢我们部署大型增强功能的速度(可能是一件好事)，但会极大地减慢我们部署小型增强功能和修复程序的速度(即bug存在的时间更长)。

scrum中的sprint部署是异端吗？sprints甚至适用于我们的情况吗？我完全误解了sprints吗？

Answer 1

在评审会议期间，产品所有者必须对Sprint结束时完成的工作进行评审。如果中途发布，情况可能并非如此。

如果你觉得在冲刺结束之前工作已经完成，你可以：

通过从release backlog

• Shorten

中选择最高优先级的项目，未来sprints增加了更多工作

根据你对工作环境的描述，我会选择2。

您可能还想考虑另一种更适合您的环境的敏捷方法。

我不会发布中期冲刺。

Answer 2

我真的认为在sprint中期部署到生产环境听起来不是个好主意。一个真正的焦点抢夺者。

也许缩短sprint的长度对你来说是一件好事？

Answer 3

在冲刺结束时拥有可发布的内容并不排除冲刺中期的发布。事实上，当您的团队有生产支持职责时，它是必需的。

不过，我想问几个关于这些sprint中期发布的问题：

1)早期版本的增量价值是否超过了部署成本? 2)您是否评估过每个迷你部署的风险，以确保它们不会适得其反，并创造更多工作? 3)您能否获得客户对这些迷你版本的反馈，以确保您正在发布他们想要的内容? 4)您是否考虑过缩短冲刺时间？

“严格的scrum驱动的开发”(上面提到的)对我来说是一个矛盾的修饰法。咒语是检查和适应。我对scrum被用作反对改善对利益相关者的响应的教条的建议感到愤怒。