稳定 sprint：必要的过错，还是纯粹的浪费？

Dushy 曾经听过“稳定 Sprint”，质疑它们是否属于敏捷规范的一部分。稳定 sprint，是指在正常的开发周期临近结束时，在交付产品之前那几个附加的 sprint。如其名所示，加上它们一般是为了最后一次把产品稳定下来，去掉最后几个 bug。

Ilja Preuss 指出：“稳定 sprint 的存在，标志着你对于‘完成’的定义还不完成，或是没有遵循这个定义。”

Sarath Kummamuru 提出：他见到一些案例，其中稳定 sprint 是有价值的。

1. 处理由于急于完成一个 sprint 所积累下来的技术债务（主要包括重构现有代码、提升单元测试覆盖率等工作）。
2. 处理 QA 债务，是因为每个 sprint 缺少完全的自动化和回归测试所积累下来的。当公司在处理没有太多自动化手段的遗留代码库时，常会出现类似问题。
3. 要发布的产品，其测试和验证要在多种平台上完成（比如在不同应用服务器上验证，在不同操作系统平台上验证产品的可用性等等）。
4. 如果需要完成任何软件打包的工作（比如发布用的 CD 等等），这些一般都会在发布 / 稳定 sprint 中完成。

本文作者发现：是否有必要接受稳定 sprint，类似于是否给人一副拐杖，而且以后再也不帮助他们独立行走。要把当前已有代码的测试全部自动化可能需要好几年时间，但是没有借口让目前自动化测试不完整的现状一直持续下去。而且，任何没有自动化验收测试和单元测试的代码，其质量都是未知的。我们不知道其中是否隐藏着 bug——（从精益的角度看）这就是浪费。

Edward Arunal 提到：“一般来说，如果有任何东西处于等待阶段，就说明我们在积累债务。很多时候，你可能需要不止一个稳定 sprint，这会带来发布的不可预测性。（相当于延迟，利益干系人更不喜欢不可预测性）”

Mark Woyna 给出一个例子，指出消除稳定 sprint 在经济上并不可行。在这个例子中，测试环境由 800 台服务器构成（价值数百万美元），每秒需要完成 30 万次操作。在这些服务器上运行的测试要用 3 至 4 周，当这些服务器要进行一次升级时，团队需要模拟出这种情况下会发生什么。然而，Mark 指出这只是特例，“我同意你们的说法，在稳定 sprint 中的工作就是没有完成的工作……如果软件有问题，我们更希望发现得越早越好。”

最后， Steve Gordon 指出：

修复这种有问题的工作之根源，这才是改进之道。没错，我们需要解决眼前的问题，可如果到此为止，问题会一再出现，你将会一直与不完整的工作和“不可预知”的缺陷为伍。 接受“稳定 sprint”做为周期性的、正常的实践，这等同于仅仅解决眼前的问题、而且愿意接受同样的问题一再发生。

InfoQ 之前的相关新闻：“完成”意味着“可交付”吗？

查看英文原文： Stabilization Sprints, A Necessary Evil or Pure Waste?