编辑以提高清晰度

Scrum建议我们将开发分为多个冲刺。每个冲刺是固定的持续时间。在每次冲刺结束时，我们都会询问客户是否应发布软件。如果他们回答"是"，那么我们将执行" Release Sprint"，在此期间我们将连续执行所有我们想完成的任务，但这些任务过于昂贵，例如外部用户测试，性能负载测试和注销，刻录CD(如果相关)。 ，编写以用户为中心的文档等

在我当前的项目中，我们刚刚执行了第一个版本的sprint。我们发现我们失去了Scrum的许多优势，例如燃尽(因为许多事情正在修复较小的调整或者临时从站点上删除安全性，以便可以进行负载测试)，明确了要进行多少工作的目标基本上，释放任务太接近消防，无法通过常规Scrum工具轻松追踪。

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

解决方案

我们正在使用带有Scrum的看板。每个产品项均在白板上用便签纸表示。在每个人都完成各自任务的日常站立比赛中，这确实很明显，而且我们可以看到与另一端的"完成"区域相比，我们在板上的"待处理"区域排队的门票数量。

实际上，我更喜欢这个工具。它执行任务跟踪，燃尽，燃尽，对于项目注释很有用。

但是要回答这个问题，跟踪燃尽剩余的小时数仍然应该起作用。它还会告诉我们是否要及时完成所有发布-冲刺任务(错误/调整)。如果答案不是"全部"，那么是时候让产品负责人进行一些优先排序了，并把某些任务排除在冲刺之外。

目标应该是达到一个不需要发布冲刺即可部署到生产环境的地步：)话虽如此，我们在发布冲刺中在做什么？仍有任务要做，但是比开发代码更可预测。除了通常涉及通过操作将人员加入团队之外，我从未见过燃尽/计划工作方式的不同之处。那当然可以是它自己的问题。也许我们可以快速了解组织中的发布冲刺是什么样子。