Schwaber&Beedle的"scrum"书(以及我读过的其他scrum文章)似乎专注于在sprint结束时拥有可释放的产品.已建立站点的Web开发(至少在我们的案例中)包括开发"增强"(各种大小)和许多小"修复".仅在sprint结束时部署(到web)会减慢我们对大型增强功能的部署(可能是一件好事),但会大大减慢我们对小增强功能和修复程序的部署速度(即错误时间更长).
scrint的中间冲刺部署是异端吗？冲刺是否适用于我们的情况？我完全误解了冲刺吗？
我真的认为部署到生产中期冲刺听起来像个坏主意.一个真正的焦点窃取者.
也许缩短冲刺长度会对你有用吗？
在审核会议期间,产品所有者必须审核Sprint结束时完成的工作.如果你在中途发布,情况可能并非如此.
如果您认为在sprint结束之前工作已经完成,您可以:
通过从发布积压中选择最高优先级项来添加更多工作
缩短未来的冲刺
鉴于您的工作环境描述,我会选择2.
您可能还想考虑另一种可能更适合您的环境的敏捷方法.
我不会发布mid-sprint.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
