【敏捷FAQ 第11期】为什么总是做不完？Sprint 遗留任务的真正原因与处方

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。
 从第9期到上一期，我们一直在讨论估算与预测。本期和下期将讨论两个每次都会背叛这些预测的常客——遗留与插入工作——。

 每个 Sprint 都有 2～3 个 PBI 无法完成，遗留到下一个 Sprint。对于遗留的 PBI，是否应该重新估点？另外，将已经完成约八成的内容视为“未完成”，似乎对努力工作的成员太苛刻了。对于遗留已成常态的团队，应该从哪里开始改进呢？

 问题中包含三个疑问，因此先简要回答，再进入正题。

• 是否应重新估算遗留 PBI 的点数——不需要（原因后文说明）
• 将完成八成的内容视为未完成，是否太苛刻——看起来很苛刻，但它确实未完成。“几乎完成”由于无法发布、无法为客户带来价值这一点，和“尚未开始”是一样的
• 已成常态的团队应从哪里改起——不是责备或掩盖遗留，而是从对原因进行分类开始

 遗留并非失败，而是映照团队计划与工作实际情况的一面镜子，也是重要的数据。以下将围绕两个重点展开：持续将完成／未完成以二元方式处理，以及按类型区分遗留的原因。

 我想很多人在培训或实际工作现场都曾被这样指导过：“未能在 Sprint 内完成的 PBI 就是未完成”“不能为部分完成的内容计入点数”。那时，您是否有过这样的疑问？

• 确实已经完成了八成工作。将其当作 0，难道不是歪曲了实际情况吗？
• 如果目标是将遗留降到零，那么一开始少计划一些不就行了吗？
• 努力工作的成员，其成果无法体现在数字中。这难道不会影响士气吗？

 这三个问题都源自一线的真实感受。先说结论：如何处理未完成项，并不是“评价努力”的问题，而是“预测材料新鲜度”的问题。

• 即使已经完成八成，剩余两成的不确定性也并非为零（也就是说，甚至连我们认为已经完成的对象是否真的完成了八成，都并不确定）。
• 遗留为零不是目标，而是消除原因后自然发生的结果。
• 数字应记录的不是努力，而是是否完成。

 先来看看遗留通常会被如何对待，之后再逐一回到这些问题。

 遗留成为常态的团队中，存在几种反模式。请将其与您自己 Sprint 中的景象对照一下。

第一种：按完成量计入型——即“已经完成八成，所以计入八成点数”“遗留部分则重新估为剩余两成的点数”。从长期看，点数总和似乎并不会改变，乍看之下好像没有什么危害。然而，部分计入会人为抹平每个 Sprint 的波动，让我们上次讨论的“范围”看起来比实际更窄。隐藏在剩余两成中的风险，也会从数字中消失。而且，“只差一点了”却花了 3 天，甚至远比预期拖得更久的经历，相信每个人都有过。

第二种：默认接受型——每次都有遗留，却既不在回顾中、也不在计划中成为议题。“唉，反正一直都是这样。”遗留没有被记录，原因没有被分析，下一个 Sprint 又计划同样的量。遗留已成常态的团队中，实际上大多数都属于这一类型。延误也会成为常态，甚至遇到过一些团队已经不再认为“处于延误状态”本身是问题。

第三种：寻找责任人型——每次出现遗留时，都会追问“是谁做得慢”。从此以后，遗留要么被隐藏，要么被找借口解释，要么被设法平账，绝不会成为分析原因的材料。当能够如实报告遗留的氛围消失时，团队也就失去了了解自身真实状态的手段。

第四种：测试后推型——这是业务系统现场经常见到的一种变体。实现已经完成，但只有测试每次都赶不上。大部分测试仍然依赖手工操作，无法以在 Sprint 内完成（包含测试）的速度推进。如果接受这种情况“也没办法”，开始将测试排除到 Sprint 之外，那么系统测试和集成测试就会在临近发布时堆积起来，最终形成一种披着 Sprint 外衣的“测试后推式集中开发”。
 真正可怕的是之后的情况。最终依然无法为测试投入足够的时间，而作为最后依靠的文档也（与瀑布式开发相比）较少。其结果是，缺陷尚未被发现，便被迅速交付给用户。

 这四种类型都建立在同一个基础上。即：**“遗留是没能遵守计划的失败。”**站在这个前提上，就会自然得出以下判断：失败应该被尽量淡化（按完成量计入）、最好不要触及（默认接受）、理应存在责任人（寻找责任人），来不及完成的工序就应该移到外部去（测试后推）。
 现在，让我们在这里解答刚才暂缓的三个疑问。

 首先，**将八成当作 0，难道不是歪曲了实际情况吗？**恰恰相反。将八成当作八成，才是歪曲了实际情况。Scrum 执着于“完成的定义”，并非精神论。一个完成八成的 PBI，其剩余两成中包含了尚未通过测试的代码、尚未评审的设计、尚未集成的模块。在软件开发中，风险恰恰集中在这剩余的两成。以完成／未完成的二元方式处理，是一种将这种“只差一点”的不确定性排除在计划之外的纪律。之所以不计入部分点数，也不在遗留时重新估点，理由同样如此：不完整的计入会让速度看起来比实际更加平滑。遗留的 PBI 保持原始点数继续推进，只有在完成的 Sprint 中才首次计入。虽然朴素，但这是最不掺假的记录。顺带一提，如果对外确实需要基于完成量的进度报告，可以另外提供。但不要将其混入速度中。

 接下来，**一开始少计划一些不就行了吗？**这有一半是对的。上一期我写过，对于一定要纳入的部分，应按悲观值进行规划。即便如此仍然出现遗留，问题就不在于数量，而在于 PBI 的大小、对容量的判断，或者开始工作的方式。仅仅减少数量，只会让表面看起来像是解决了问题，本质原因却依旧存在（而且之后还会反复陷入同样的状况）。遗留为零不是目标，而是消除原因后自然发生的结果。

 还有，**努力无法体现在数字中，难道不会影响士气吗？**如果会产生影响，那是因为“完成”没有作为团队成果得到认可。速度不是记录个人努力的数字，而是记录团队交付内容的数字。如果想认可个人完成的八成工作，应当用语言而不是数字来认可。只将完成的内容记录在数字中，这种纪律从长远来看更能保护成员。与其每次都怀抱“明明只差一点”的遗憾，不如切得更小、每次都完成，这才是舒心得多的工作方式。

 那么，“没能遵守计划就是失败”这一前提来自哪里？它根植于 Scrum 出现之前就存在的规范：计划是必须遵守的，未达成就是失败。拉出甘特图、紧盯延误、未达成时提交原因说明书——许多成员在进入 Scrum 团队之前，就已经习得了这种文化。没有人应当因此受到责备。只是这种旧规范被原封不动地应用在了 Sprint 计划上。

 另一方面，遗留本来是什么？Scrum 将这一规范反转。计划是假设，而未达成则是告诉我们假设与现实之间差异的观测结果。
 观测——如实记录什么内容、多少内容、为什么没有完成。不责备、不隐藏、不粉饰。
 检查——按类型区分遗留原因，找出反复出现的内容。不要问“是谁慢了”，而要问“这次遗留属于哪一种类型”。
 适应——针对不同类型，改变下一个 Sprint 的计划或工作方式。包括拆分、重新审视容量、调整开始工作的方式。

 以此来看，就能看出默认接受型和寻找责任人型所缺失的东西。前者放弃了观测，后者扭曲了观测。两者都无法进入检查阶段。要从“把失败淡化”转向“分类原因并反映到下一个计划中”。这一转变，是下文处方的基础。

 接下来开始进行处理。关于拆分技巧和容量设计，专家的建议很多，选择哪一种都可以……这句话我每次都在说。不过有一点：如果只是说“我们已经拆分了”就结束，那和不看原因、只减少数量没有区别。尝试之后，请根据遗留数量是否减少来判断；如果没有减少，则要看还残留的是哪一种类型。

首先，将遗留分为 3 类
 在采取措施之前，先从分类开始。无论做什么，掌握事实都是改善的第一步。观察每次都有遗留的团队的 Sprint 后，可以发现原因大致可分为 3 类。

1. 过大：PBI 相对于一个 Sprint 来说过大，或者验收条件模糊，导致“做到什么程度才算完成”在开始工作后不断膨胀
2. 被削减：由于插入工作或人员缺席，计划时预想的容量实际上并不存在
3. 过于分散：所有人分别开始不同的 PBI，结果每一项都停在八成。开始的事项太多，无法产出完成项

 在出现遗留的 Sprint 回顾中，请逐一询问并记录“它属于 1～3 中的哪一种”。积累 3 个 Sprint 的数据后，就能了解该团队的遗留偏向哪一类，从而选择相应的处方。寻找责任人会扭曲分类。能够如实报告遗留的氛围，本身就是团队的资产。

对于原因 1（过大），使用拆分技术
 对于“是否能装进一个 Sprint 还很微妙”的 PBI，应在计划阶段就进行拆分。拆分有很多切入角度。例如按工作流步骤拆分（只做申请→审批留到下次）、按验收条件拆分（正常流程→异常流程）、按目标数据拆分（仅限国内→支持海外）、按质量等级拆分（以手工运行为前提→自动化）。用第 4 期的说法，这些都是在用例流程——基本流程与替代流程——的分岔点进行切分。寻找拆分的切入点，就是寻找流程的分岔点。在掌握“将功能纵向切薄”（从界面贯穿到数据库，按每一条细窄的流程路径来切分）的感觉之前，值得在细化上多投入一些时间。根据经验，当一个 PBI 的大小能够控制在 Sprint 中 2～3 天的工作量时，遗留会明显减少。

对于原因 2（被削减），采用基于实际数据的容量设计
 如果插入工作是持续存在的，那么它就不是意外，而是应当纳入预期的常量。具体应对将在第 12 期（下期）详细讨论，但要点是：测量插入工作的实际情况，并在计划中以可见的形式预留插入工作的空间。

对于原因 3（过于分散），采用蜂拥协作
 请将“在开始新事项之前，先完成快要结束的事项”作为团队口号。第 6 期提到的“从看板最右端开始走”的每日站会——从最接近完成的 PBI 开始，思考“为了今天完成它，需要做什么？”——可以直接成为蜂拥协作的入口。多人聚集在一个 PBI 上共同完成工作的方式（蜂拥协作），虽然看起来会降低个人的利用率，但会增加 Sprint 的完成数量。优化的不是利用率，而是完成——这是敏捷中最违反直觉、却也最有效的转变之一。如果 Sprint Goal 写的不是“完成所有计划项”，而是“让这项业务能够以这样的方式运转”，那么该聚集到哪个 PBI 上也会自然明确。

对于测试后推型，应投资测试自动化
 这一变体的根本应对方式不是拆分或蜂拥协作，而是投资测试自动化。以人海战术吸收测试为前提的组织，这项投资往往越容易被长期推后；但只要放任无法在 Sprint 内“完成”的结构，遗留就不会消失。关于自动化投资，计划在今后的文章中讨论。

 “遗留＝坏事”这种感觉，并不会在一次培训后消失。每当加入一位习得了甘特图与原因说明书文化的新成员，这种观念就会再次被带入团队。因此，每当团队成员更替，这个问题都会以不同形式再次出现。

 惩罚遗留的团队会反复出现同样的遗留，而从遗留中学习的团队则会不断提高计划的精度。分界点不在于能力，而在于如何处理未达成的文化。本次遗留是否按类型被记录，并反映到下一个计划中——仅凭这一点，就可以判断这个团队是否真正将遗留作为数据来使用（以防万一说明一下：这里讨论的是内部的计划观，并不是说可以轻视对外承诺的交期）。

下期：“如何将插入工作纳入计划？”