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

作者 Mark Levison 发布于 2009年12月27日

领域

过程 & 实践

主题

质量交付 ,

质量 ,

软件工匠 ,

企业级敏捷 ,

敏捷技术 ,

验收测试 ,

持续改进 ,

敏捷 ,

测试

分享到

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?

1. 返回顶部

   稳定Sprint其实是敏捷留着Waterfall的尾巴

   发表人 Li Darren

   如果在正常Sprint中，能够保证高质量，那么稳定Sprint是不必要的。但是，当正常Sprint无法保证足够的质量水平，有这个稳定Sprint总比没有强。敏捷团队的目标应该是尽快消除这个特殊的Sprint。换句话说，提高正常Sprint的质量，才是努力的目标。

   回复

2. 返回顶部

   当“敏捷“也开始讨论 ”某个流程是否必需？某个环节是否一定要执行？“ 时，是不是让你感觉这不再是”敏捷“了呢？

   发表人 Chan Jackei

   是否需要“稳定 sprint”？──当“敏捷“也开始讨论 ”某个流程是否必需？某个环节是否一定要执行？“ 时，是不是让你感觉这不再是”敏捷“了呢？难道要把敏捷也固化下来？让敏捷在任何一个项目中都表现的一模一样？
   
   一个项目需要几个迭代，每次迭代处理哪些事情，最后如何 close 一个项目，这在”敏捷“中不是应该由项目经理根据实际的项目情况来分析判断的吗？
   
   应该在每个迭代结束时，对遗留缺陷进行评估，确认修复计划，在后续的迭代中不断的执行、更新和维护这份计划。如果有需要，就在最后加多一个迭代用来让整个产品稳定下来。──这种思路还需要专门讨论吗？

   回复