如果你需要一个「加固冲刺」，说明更早的环节就出了问题
2021年初，我合作过的一个团队刚刚全面转为远程办公，正赶着交付一个业务方承诺在季末上线的版本。他们的计划在最后安排了为期两周的「加固冲刺」：用来修复缺陷、完成测试和稳定系统。这听起来很负责任，实际上却是一盏警示灯。加固冲刺正是把之前各个冲刺中悄悄跳过的所有工作，集中在一刻一并到期的地方。
《Scrum指南》对此说得很直接。每个冲刺都必须产出一个可用的、具备潜在可发布性、并满足「完成的定义」的增量。如果你经常需要在之后另设一个阶段，才能让工作真正可发布，那说明你的增量从一开始就没有真正完成。「加固」这个标签只是把被推迟的质量伪装成一项有计划的活动。
为什么会出现这种征兆
它很少源于懒惰，而是源于过于薄弱的「完成的定义」、迫于压力报出团队其实无法真正完成的故事点，或是把测试和集成当成「以后再说」的别人的事。远程与混合办公在2021年让这种情况更严重：过去能及时发现半成品工作的走廊闲聊消失了，于是缺口一直被掩盖到最后。加固冲刺成了大杂烩，而这个大杂烩越积越多。
一份你本周就能用的现场检查清单
全队一起把「完成的定义」大声读一遍。 如果它不包含测试、集成以及「加固」通常涵盖的其他内容，那它就是不完整的。现在就把这些项加进去，让「完成」意味着「可发布」。
审查最近三个冲刺中的遗留项。 列出每一个被标记为完成、却又在稳定阶段需要返工的条目。这份清单才是你真正的缺口，而不是用来追究某个人的过错。
不要再把未完成的工作算作速率。 如果一个条目没有满足「完成的定义」，本冲刺就不计入它。诚实的速率起初会更低，但随后会可预测得多。
把测试和集成纳入冲刺之内。 将它们作为每个待办列表条目的验收标准，而不是下游的一个阶段。把重复性的检查自动化，团队才能在每个冲刺真正达到标准。
把加固冲刺改名为一次过渡，并设定结束日期。 如果你确实需要它来清偿历史欠债，就把它当作一次性的清理，并明确规划好今后不再需要第二次。
在冲刺回顾会上检视这一点。 只问一个问题：我们称之为完成的一切，是否真正满足了「完成的定义」？凡是答案为否之处，就改进流程。
重点不是要在你的代码库已经背负多年欠债时禁止设立稳定期，而是要停止制造新的欠债。一个按照严格「完成的定义」结束每个冲刺的团队，不会积累隐藏风险的积压，因此也永远不需要一个缓冲来消化它。
当你撤掉加固冲刺而一切照常运转时，你就有了工作确实已完成的证据。当确有东西出问题时，你就准确地找到了「完成的定义」需要加强的地方。无论哪种情况，你都学到了真实的东西，而发布也不再依赖于最后那满怀希望的两周。
如果你的交付节奏始终要靠最后的清理阶段来兜底，XNM的项目群与项目交付咨询 可以帮助你收紧「完成的定义」，并让每个冲刺都达到真正可发布的标准。