编辑以提高清晰度
Scrum 建议您将开发拆分为多个 sprint。每个冲刺都是固定的持续时间。在每个 sprint 结束时，您都会询问客户是否应该发布该软件。如果他们说是，您将执行发布冲刺，在此期间您会连续执行所有您想做但成本太高的任务，例如外部用户测试、性能负载测试和签核、刻录 CD（如果相关） ，编写以用户为中心的文档等
在我当前的项目中，我们刚刚完成了我们的第一个发布冲刺。我们发现我们失去了 scrum 的很多优势，例如烧毁（因为很多事情都是在修复微小的调整或暂时从站点中删除安全性以便进行负载测试），一个明确的目标是要完成多少工作接下来完成等等。基本上，发布任务太接近消防，无法通过普通的 scrum 工具轻松跟踪。
在发布冲刺期间，其他人使用了哪些方法，您发现应该避免哪些陷阱？
其实，我更喜欢这个工具。它进行任务跟踪、燃尽图、燃尽图，对项目笔记很有用。
但要回答这个问题，跟踪燃尽的剩余时间应该仍然有效。它仍然会告诉您是否要及时完成所有发布冲刺任务（错误/调整）以进行发布。如果答案是“不是全部”，那么是时候让产品负责人来做一些优先级排序，并将一些任务排除在 sprint 之外。
我们正在使用带有 scrum的看板。每个产品项目都由白板上的便利贴表示。在每个人都在完成每项任务的每日站会中，这一点非常明显，我们可以看到我们在黑板上的“待处理”区域与另一端的“完成”区域相比排队了多少张票。
您的目标应该是达到不需要发布冲刺即可部署到生产环境的程度：) 但是话虽如此，您在发布冲刺中正在做什么？还有一些任务要完成，但它们比开发代码更容易预测。除了通常涉及从操作人员向团队添加人员之外，我从未见过燃尽/计划的工作方式有什么不同。这当然可能是它自己的问题。也许您可以快速了解一下您的组织中的发布冲刺是什么样的。