稳定 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?

敏捷文化 & 方法