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