【敏捷FAQ 第9期】上司要求将故事点换算为人日

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。
 第6～8期讨论了 Scrum 事件。从本期开始，我们将进入估算与预测的话题。和事件系列一样，将按照“真实疑问→反模式→误解的根源→处方”的顺序进行解读。

 我们使用故事点进行估算，但上司每次都会问：“那么，这是多少人日？”我一时答不上来，最后还是做了一张类似“1 点＝0.5 人日”的换算表。我觉得这样一来相对估算就失去了意义，也会想：既然反正要换算，那一开始直接按人日给出不就好了吗？
 究竟该怎样回答才是正确的呢？

 虽然表述各不相同，但您的这个主题（点数与人日）确实经常被问到。让我们从三个角度来思考这个问题。

• 上司真正需要的真的是“人日”吗
• 制作换算表真的是那么糟糕的事情吗
• 如果不按人日回答，那究竟应该用什么来回答

 按顺序回答。

• 上司真正需要的通常不是人日，而是“什么时候能完成？（或者，能赶上吗？）”“要花多少钱？”。人日只不过是为了推导出这些答案而被问到的手段。
• 制作换算表这件事本身并不该受到责备（毕竟是被问到了）。但在将“1 点相当于〇〇”固定下来的那一刻，几个齿轮就会——如后文所述——开始反向转动。“那还不如一开始就按人日”的想法很合理；如果在估算现场所有人都在换算成人日，那么这样做反而更坦诚。不过，造成这种状况的原因不是点数，而是换算表。
• 应该回答的并不是点数的换算值，而是发布预测与成本预期。如果能够基于实际速率和剩余待办事项，以带有范围的方式回答“预计在〇月上旬～〇月下旬完成”，通常就能满足公司内部上司的需求（不过，如果委托方的审批申请必须使用人日，则另当别论，这将在处方部分说明）。

 不要追随问题的字面，而是回答问题背后“对方真正想知道的事”——关键就在这里。讨论的主轴有两个：一是“翻译上司的问题”，二是“区分对外给出的数字和内部计划的工具”。

 我想很多人都曾在培训或工作现场被教导过：“故事点是相对值”“不能换算成人日”。当时，您是否产生过这样的疑问？

• 预算和审批都以人日为单位运转。如果不换算，岂不是无法沟通吗
• 结果，估算时所有人都会在脑中换算成人日。那还不如一开始就用人日，不是吗
• 保持相对值不变的话，上司能据此做出什么判断

 这些都是正当的疑问。先写出答案：关键在于，从“1 点＝〇人日”推导出的数值与速率，是看似相同、实则不同的数字。换算值是“这一项是 3 人日”，即描述条目成本的数字。速率则是“这个团队每个 Sprint 能完成 25 点”，即描述团队流量的数字。计划所需要的是后者；若把前者带入计划场景，就会开始逐项对账。

 如果预算和审批都按人日运转，确实有必要与人日建立连接。不过，连接的不是各个条目，而是总量。将剩余的总点数除以速率得出周期，再将周期乘以团队的月成本得出金额。采用这种方式，就不必给每个条目贴上人日标签。
 上司想要据以判断的并不是相对值本身，而是“什么时候完成”“要花多少钱”。应当交给上司的不是点数这种原材料，而是由此推导出的预期。

 不过，只说这些恐怕还不够。先列举一下换算要求通常会演变成什么样子，然后再逐一回答。

 围绕换算，存在几种反模式。如果其中有令您感到熟悉的情况，可以从那里开始阅读。

第一种：对照表型——最常见的类型。制作类似“1 点＝0.5 人日”的固定对照表，用点数相乘换算成人日后汇报。开头的问题正是这种情况。刚制作完成时一片和平，但在估算现场，所有人都会开始反推人日，“这个大约是那个的两倍”这种比较的速度也会逐渐丧失。

第二种：成绩单型——点数被挪用为“某人本月完成了多少点”的个人生产率指标，或“团队 A 每个 Sprint 30 点，团队 B 15 点。B 的生产率是否只有一半”的团队间比较指标。估算会变成自我防卫的工具，于是产生了估大一些的诱惑、选择简单条目的诱惑，数字不断膨胀，作为预测工具则会死亡。当衡量标准变成目标时，它就不再是好的衡量标准——这是以经济学家查尔斯·古德哈特之名而闻名的“古德哈特定律”所描述的现象。归根结底，点数是团队内部的相对值，团队 A 的 5 点与团队 B 的 5 点没有任何可比性。换算表掩盖了这一事实。

第三种：砍价型——委托方或管理部门看到换算成人日的数字后，对每个条目进行砍价，比如：“这个页面要 3 人日？以前 2 人日就能完成吧。”当点数的明细变成人日的明细时，估算就不再是预测，而成为谈判材料。这与第3期所看到的“估算明细流入保证条款”的结构完全相同。

第四种：沉默型——遵守“不要换算”的教导，只对上司的问题回答“点数是相对值，所以无法换算成人日”，然后对话就结束了。虽然说的是正确的话，但对于上司真正想知道的“何时、多少钱”，却没有做出任何回答。自以为遵守了教导，实际上却放弃了翻译。

 这四种类型有一个共同的前提：点数是工作量的别名。站在这个前提上，制作换算表理所当然，应该可以用于个人或团队的比较，应该可以对明细砍价，反过来还会自然推导出“如果不能换算，那就毫无用处”的结论。每一种类型，都是在未曾质疑这一前提的尽头出现的。

 基于以上内容，逐一回答刚才的疑问。

 首先，如果不换算，岂不是无法沟通吗。确实如此。组织的预算编制、审批申请及对外汇报，都以人日、人月运转；如果不接入这种语言，就无法沟通。这是现实，否认它也无济于事。而且，从点数换算为人日在数学上是可行的。将一个 Sprint 中实际使用的人日除以该 Sprint 中完成的点数，就可以通过简单算术得出“1 点＝〇人日”。许多现场的换算表，实际上正是这样根据实际数据制作的。其出处是正确的。
 即便如此，换算值与速率也不是同一种东西。区别在于，数字究竟表达了什么。速率是“这个团队每个 Sprint 能完成〇点”，是团队这个系统的流量。它是包含会议、插入工作及等待时间在内的事后观测值，对于该期间内开发的每个具体条目并不作任何主张。它只描述总量。换算值则是将该速率固定为一个常数，考虑团队人数与 Sprint 时长后，转变为“这一项是 3 人日”这种与条目关联的属性值。换言之，它变成了描述条目成本的数字。即便都来自同一份实际数据，一方是团队流量，另一方是条目成本。这就是分界点。
 在变成条目成本的那一刻，对每个条目砍价、责备一个 3 人日的条目却花了 5 天的人、要求按条目重新估算，都会成为“正当的使用方式”。负责估算的人会预见到这一点而抬高点数，点数也会变成绩效指标。前面所说的四种类型，全部都由此而生。如果始终保持为流量，这些事情从一开始就无法成立。
 那么，对于今后要制作的内容预期，应如何接入人日、人月这种语言？不要乘在条目上，而是从总量中相除。将剩余待办事项的总点数除以实际速率，就能得出剩余 Sprint 数。这就是“什么时候完成”。再将该 Sprint 数乘以团队的月成本，就能得出“要花多少钱”。由于速率是会变化的观测值，可以保持以范围（20～30）来处理，预测也会成为范围，偏差会作为“预测更新”回到下一次计划中。如果在估算阶段将换算值乘到条目上，计划在那一刻就会被确定下来，相同的偏差则会以“延期”的形式出现。
 只要采用将人日、人月语言与总量连接起来的形式，就能够在保持团队内部使用点数进行估算的同时，基于实际数据提供团队外部人员所期待的预期。当被问到实际成果本身时，回答会更简单：“这个团队在这 3 个月里花费了〇日元的人力成本，并交付了〇〇。”无需经过逐项换算。

 不过，坦率地说，如果每个 Sprint 都重新审视换算值，不再按条目查看、只将其用于总量，那么无论是乘到条目上还是从总量中相除，得到的数字都是相同的。差异不在计算结果，而在于数字的含义，以及它会招致的运作方式。关于这一点，将在讨论速率的那一期末尾再更仔细地说明。

 接下来，既然脑中都在换算成人日，那一开始就用人日不就好了吗。在那种状态下，确实如此。相对估算的优势在于，“这个大约是那个的两倍”这样的比较，能够比绝对值估算更快地作为团队共识得出。如果在估算现场所有人都在反推人日，这一优势其实已经失去，用时间进行估算反而更坦诚。不过，那不是因为点数没有意义，而是因为对照表将点数变成了人日的别名。停止使用对照表，比较的速度就会恢复。

 再者，保持相对值不变的话，上司能据此做出什么判断。相对值本身不能用于判断。上司用于判断的是，基于相对值与实际速率推导出的“什么时候完成”“要花多少钱”。点数不是展示给上司的数字，而是团队内部用于制作这种预期的材料。应该交给上司的不是材料，而是预期。

 “工作量的别名”这一前提来自哪里。我们中的许多人都接受过这样的教育：估算就是累积工作量。按功能估算人日，汇总后得出周期与金额。在这种文化中遇到故事点时，将它理解为“人日的新单位”是一种自然反应。这不是懒惰的问题。不过，它不是单位的替换，而是工具的替换，这一点在培训中往往难以传达。

 回过头来看，故事点究竟是什么？在说明它是工具之前，先说清它衡量的是什么。点数是将待开发内容的大小——结合了工作量、复杂度与不确定性的东西——用该团队自己的刻度表示出来的相对值。工作量是“人投入的时间”，属于投入侧的量；而大小则属于要构建对象一侧的量。不过，大小本身并不存在绝对值，因此使用“这个大约是那个的两倍”这样的比例来表示。之所以能使用比例，是因为同样两个条目所需的工作量虽然会因开发人员不同而变化（A 是 1 天和 2 天，B 是 3 天和 6 天），但“两倍”这个比例不容易改变。因此只保留比例。而且刻度是团队特有的，带到团队外部就会失去意义。

 那么，故事点原本是为了什么而存在的工具？敏捷的计划制定建立在经验主义之上。不是预先确定估算，而是让实际成果透明化，检视预测与实际之间的偏差，并使计划适应变化。故事点正是用于“从实际数据进行预测”的工具。
 估算——点数用于快速地将条目之间大小的比较作为团队共识得出。因为不是绝对值，不容易受到个人工作速度或日常插入工作的影响，达成的共识也不容易被破坏。
 实际——每个 Sprint 完成的点数总和（速率）就是团队的实际成果。这是将点数换算为周期的唯一依据。
 预测——将剩余点数除以实际速率，就能得出剩余 Sprint 数。实际数据存在波动，因此预测会表现为范围。随着实际数据不断积累，范围会变得更可靠；随着导致波动的原因减少，范围也会缩小（关于如何处理波动，将在讨论速率的那一期说明）。

 至此，对照表型的问题就很明显了。“1 点＝0.5 人日”的问题，不在于它没有依据，而在于它将原本属于团队流量的实际数据变成了条目成本，而且即使作为依据的实际数据发生变化，表格也不会改变。应当改变的是：从“将每个条目的点数换算成人日”，转变为“利用总点数与实际速率得出预期，并以该预期接入团队外部的语言”。这一替换，是本文所有处方的前提。

 从这里开始是具体措施，但它们都只不过是工具而已。专家们已经提出了各种估算与预测方法，选择任何一种都可以。不过，如果只是宣布“我们抛弃了换算表”，那和沉默型没有区别。尝试之后，请通过与上司的对话是否从“多少人日？”变成“什么时候？多少钱？”来判断是否有效。

首先，列出最近若干个 Sprint 的速率与剩余点数
 在修改之前，先将当前状态汇总到一张图里。请将最近 5～8 个 Sprint 的速率（最低值与最高值），以及剩余待办事项的总点数放在一张图中。即使只有 3 个 Sprint 的实际数据，也能粗略得出一个范围（要形成可靠的范围大约需要 5 个 Sprint，不过这一点留到下次再说）。仅仅有了这张图，对“多少人日？”的回答就会从“无法换算”变成“按照当前实际数据，需要〇～〇个 Sprint”。后续的处方都从这张图开始。

对于“什么时候完成”，用发布预测来回答
 基于最近若干个 Sprint 的速率范围和剩余待办事项的总点数，以范围展示完成时间。“剩余 220 点，速率为 20～30，因此需要 8～11 个 Sprint，也就是〇月～〇月。”重点是以范围而不是单一日期回答。如果上司按金额提问，就将这个范围直接转换为金额。“最佳情况与最差情况相差 3 个 Sprint，也就是说，团队月成本的 1.5 个月份额，就是当前预期的波动范围。”还有一种称为“范围燃尽图”（Ranged Burndown）的实践方法，它在燃尽图上用最佳值与最差值两条线来表示范围（PMI Disciplined Agile 中介绍的一种带范围的燃尽图表达方式）。范围本身的宽度就是对不确定性的诚实表达；随着 Sprint 不断推进，范围也会逐渐缩小。如果能够与上司共享这种“预测逐渐变得精确”的体验，对话的质量就会发生变化。
 而且，这种转变不能只靠回答的一方完成。开发人员应每次都以相同的格式展示范围及其依据；提问的上司则尝试将“多少人日？”改问为“什么时候？多少钱？”。当双方都习惯这种形式时，换算表就不再需要了。

对于“要花多少钱”，用团队运营成本来回答
 敏捷团队的成本并不是由任务累积决定的，而是由“让这个团队运行多少个月”决定的。对于像系统更新项目这样需要按交付成果整体编制预算的场景，其“容器”可以通过第4、5期的方法来构建（用用例数量×规模叠加深度的初始设定得出工作量，再根据实测值换算为周期与金额）。另一方面，持续运作团队的费用计算方式很简单：团队月成本（人力成本＋经费）×周期。这个计算不需要人日换算。相反，这正是说明敏捷资金模型——“固定团队在周期内最大化价值”——的好机会。

如果仍然需要换算，则限定其用途
 在审批或合同中，无论如何都必须使用人日的场景确实存在。这种情况下，请划清界限：仅为团队外部用途准备基于过往实际数据（该团队在一个季度中花费了〇日元人力成本，并交付了〇〇）计算得出的概算值，不要将其带入团队内部的估算与计划中。只要换算值本身是从实际数据得出，并且仅限于此用途、每当实际数据更新时就重新计算，就没有问题。这是“面向外部的货币”与“内部计划工具”的分离。第3期中讨论过将“预算容器”与“保证范围”分离，这也是同样的结构。原则只有一个：对外给出的换算值来自实际数据，团队内部的计划来自预测。两者都从同一份记录中推导，并将计算依据保留在文档中。这样一来，就不会产生“对外数字和内部数字的来源是否不同”的疑问。能否就这条界限与上司达成共识是关键所在；如果事先说明换算表的副作用（通胀、指标定额化、团队间比较），通常更容易获得认可。

进阶：也可以选择放弃点数
 如果能够将 PBI 拆分得足够小且均匀，就可以不再分配点数，而采用按“数量”进行预测的方法（基于吞吐量的预测）。估算讨论的时间将几乎降为零，对“多少人日？”的回答则会变成“平均每个 Sprint 完成〇个”。请将其作为成熟团队的一种选择，留在心中。

 故事点诞生时是“团队内部的计划工具”，但组织的会计、审批和合同至今仍在使用人日、人月的语言。负责站在这两种语言的边界上进行翻译的人——本应是 PO 或经理的职责——并没有被明确任命，因此边界上的摩擦每次都会落到进行估算的开发人员本人身上。开发人员出于善意制作换算表，几年后又为同样的副作用所困扰。这样的循环不断重复。
 背后还有持续的成本削减压力。对管理层来说，敏捷越是在“更快、更便宜”的语境下被寄予期待，就越会想用人日确认“那么，究竟便宜了多少”。换算要求也是这种期待的另一面。正因如此，才有必要通过“带范围的完成预测”和“团队运营成本”这种不同的回答方式，重构期待本身的内容。

 当有人要求换算表时，这正是翻译者缺席的信号。在制作表格之前，请讨论由谁承担翻译的工作。需要确认的是，与上司的对话是否已从“多少人日？”转变为“什么时候？多少钱？”。这正是衡量该团队的估算是否作为预测工具发挥作用的仪表。

下期：“速率不稳定。可以用于计划吗？”