在发布冲刺期间测量进度的哪些方法是有效的

Question

编辑提高清晰度

Scrum建议您将开发拆分为多个sprint。每个冲刺都是固定的持续时间。在每个sprint结束时，您询问客户端是否应该发布该软件。如果他们说是，那么您执行发布Sprint ，在此期间您执行您想要执行的所有任务，但过于昂贵，例如外部用户测试，性能负载测试和注销，刻录CD（如果相关），编写以用户为中心的文档等等

在我目前的项目中，我们刚刚完成了我们的第一个版本冲刺。我们发现我们失去了scrum的许多优点，例如burndown（因为很多事情正在修复一些小的调整或临时删除网站的安全性，因此负载测试可能会发生），这是一个明确的目标，即工作量是多少接下来要完成。基本上，相关任务太靠近消防，可以通过普通的scrum工具轻松跟踪。

在发布冲刺期间，其他人使用了哪些方法，以及您应该避免哪些陷阱？

Answer 1

实际上，我更喜欢this tool。它可以执行任务跟踪，刻录，刻录，和对项目备注非常有用。

但要回答这个问题，跟踪燃尽的剩余时间应该仍然有效。它仍会告诉您是否要及时完成所有发布冲刺任务（错误/调整）以便启动。如果答案是“不是全部”，那么是时候让产品所有者进行一些优先排序，并将一些任务从冲刺中解脱出来。

Answer 2

我们正在使用带有Scrum的kanban板。每个产品项目都由白板上的便利贴表示。在每日站立时，每个人都参与其中的每项任务都非常明显，我们可以看到我们在董事会的“待定”区域排队的票数与另一端的“完成”区域相比。

Answer 3

你的目标应该是达到一个你不需要发布sprint来部署到生产的地步:)但话说回来，你在发布冲刺中做了什么？仍有任务要完成，但它们比开发代码更具可预测性。除了通常涉及从操作员向团队添加人员之外，我从未看到过燃尽/计划的工作方式有何不同。那当然可以是它自己的问题。也许您可以快速了解组织中的发布sprint是什么样的。