使用scrum部署中间冲刺(大型正在进行的“棕色地带”公共网络项目)

时间:2009-02-06 12:53:10

标签: agile scrum

Schwaber & Beedle's 'scrum' book(以及我读过的其他scrum文献)似乎专注于在sprint结束时拥有可释放的产品。已建立站点的Web开发(至少在我们的案例中)包括开发“增强”(各种大小)和许多小“修复”。仅在sprint结束时部署(到web)会减慢我们对大型增强功能的部署(可能是件好事),但会大大减慢我们对小增强功能和修复程序的部署速度(即错误时间更长)。

中间冲刺部署是否在scrum中异端?冲刺是否适用于我们的情况?我完全误解了冲刺吗?

5 个答案:

答案 0 :(得分:6)

我真的认为部署到生产 mid-sprint听起来像个坏主意。一个真正的焦点窃取者。

也许缩短短跑长度会对你有用吗?

答案 1 :(得分:5)

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

如果您认为在sprint结束之前工作已经完成,您可以:

  1. 通过从发布积压中选择优先级最高的项目来添加更多工作
  2. 缩短未来的冲刺
  3. 鉴于您的工作环境描述,我会选择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”的方法。他根据公共网站的限制调整了敏捷原则。