加固冲刺是一种坦白，而非治疗
每隔一段时间，总有团队宣布需要一个"加固冲刺"——专门留出一个 Sprint 来修复缺陷、集成组件、完成测试，总之让产品达到可发布的状态。这听上去很负责。其实它是一种坦白。一个加固 Sprint，是团队在公开地告诉你：在此前几个 Sprint 中它声称"已完成"的工作，其实并未真正完成。在一个以"每个 Sprint 结束时都产出可用、可发布的增量"为全部前提的框架里，这一点值得认真对待。
《Scrum 指南》对此毫不含糊：每个 Sprint 都应产出符合"完成的定义"的增量，而"完成的定义"是团队对产品达到可发布所需质量的共享而正式的描述。如果某个增量不符合它，就不能发布——更关键的是，它也不应被当作已完成来呈现。框架中没有任何条款允许用后续的 Sprint 来追溯性地让先前的工作变得可接受。所谓加固，不过是被推迟的"完成的定义"，重新包装成了一份计划而已。
健康的样子
在一个健康的 Scrum 团队里，"完成"不会逐条讨价还价，质量是随着工作推进而内建进去的。
团队声称已完成的每一个产品待办列表项，都已经符合同一个"完成的定义"——按 DoD 的要求经过测试、集成与记录。
测试、集成与评审都发生在 Sprint 内部，与构建并行进行，而不是堆积到以后。
在 Sprint 评审中展示的增量是真正可发布的；是否发布是一项业务决策，而不是临时的技术抢修。
技术债务在产品待办列表中可见，并被有意识地偿还，而不是被放任悄悄累积，直到需要一个专门的 Sprint 才能清理。
如果团队无法按"完成的定义"完成某一项，它就保持未完成状态并退回产品待办列表——不会被放行通过。
糟糕的样子
加固这一模式有着可辨认的形态，而且它很少单独出现。
薄弱或可选的"完成的定义"。 只要代码能编译、演示能跑通，工作项就被标记为完成，而把测试和集成当成别人日后的麻烦。DoD 写在纸上，却不存在于实践中。
粉饰太平的速率。 功能 Sprint 看起来又快又高产，恰恰是因为它跳过了收尾工作；随后一个加固 Sprint 把账单全部吸收掉。所报告的速率从来就不是真实的。
大爆炸式集成。 各组件孤立地构建，直到最后才拼接到一起，于是加固 Sprint 成了任何人第一次得知系统是否真能运转的时刻。
由发布日期来主导真相。 由于发布定在一个固定日期，质量就成了那个被牺牲的变量，而"我们之后再加固"便沦为常设的逃生出口。
请注意，这些都不是工具的失败。这是一个团队——往往承受着真实的进度压力，2022年的劳动力短缺与反复变动的返岗计划只会让压力更甚——在悄悄地把"完成"的标准向下重新定义，并在日后一次性付清代价。加固 Sprint 正是这笔被推迟的成本最终落地的地方。
治本，而非治标
解药不是把加固 Sprint 安排得更好，而是让它变得没有必要。强化"完成的定义"，直到它真正意味着可发布，然后让每一个工作项都接受它的检验。把测试和集成拉回到工作仍然新鲜的 Sprint 之内。把技术债务变成产品待办列表中可见、且经过优先级排序的工作项，而不是一笔隐藏的余额。一旦"完成"可靠地意味着完成，那个专门的稳定 Sprint 就无事可做了——而这恰恰正是目的所在。
如果您的交付团队总是发现自己还需要一个冲刺来"把收尾收完"，XNM 的项目集与项目交付咨询服务 可以帮助您收紧"完成的定义"，并把质量内建到它应在的地方。