译者导读：

本章聚焦产品待办列表工作量估算，强调可靠估算对项目规划与客户期望管理的核心作用。文中指出绝对时间估算的局限性，提出相对估算与估算点数方法，介绍了基于斐波那契数列的规划扑克工具。同时明确估算需覆盖全部工作、全员参与等要点，阐明其在需求梳理、速度衡量、流程改进及发布计划制定中的价值，为敏捷工作量管理提供实操方案。

规划扑克⑧Cards,Mountain Goat Software.Used with permission.

…你的¶54产品待办列表上包含了¶55产品待办列表事项，你需要一种方法来估算实施这些事项所需的工作量。

可靠的估算至关重要。当产品达到甚至超越预期时，客户才会感到满意。团队需要合理规划¶46Sprint的工作量，以确保交付成果符合客户的期望：若Sprint规划的工作量过多，客户的期望便会落空，而若工作量过少，团队出现了空闲时间，这便使团队陷入并未合理完成更多规划的情况。若在长期的规划中重复发生同样的问题，即Sprint工作量规划过少或过多，最终后果就是团队完成交付的时间点会远远落后于计划的时间线，亦或者大大提早。然而，倘若你将大量精力都投入以天或小时为单位的估算，一旦团队的速度（Velocity，参见第 320 页Velocity”）发生了变化，那么这些估算的可靠性就会在顷刻间化为泡影。

判断估算是否具有可靠性的一个重要指标就是实时性:要确保团队的估算有最新的信息和知识作为支撑。而一个通过冗长，枯燥的流程，费力地从团队”榨取“的估算，是很难保证这一特性的。

¶11作为产品负责人，如果想要了解某组功能的潜在发布日期。他会很自然而然地倾向让团队先估算完成每个功能项的小时数，然后将所有目标功能所需的小时数相加；再假设团队规模固定，每周工作37至40小时，据此将总小时数换算成日历上的日期，从而推算出一个发布时间。然而，这份完工估算并未考虑到那些所谓的“工作空窗期”的工作， 比如开会，处理邮件， 行政管理，切换工作产生的时间损耗，甚至还不包括一些业务类工作，如工作排期，估算本身等。事实上，一个典型的工作周中，团队能专注投入工作的时间远少于40小时，通常情况下，团队用于专注工作的时间仅约这个时长的一半。哈里斯（Harris Poll） 民意调查的一项研究发现，人们只将大约45%的时间用于“核心工作职责”上。但实际情况是，没人能真正说清在这40小时里的工作周里，有多少时间属于事务工作， 又有多少时间是真正用于核心工作的。这就使得我们更加难以判断，要完成一个既定小时数的工作，究竟需要花费多少周。

估算并非承诺，它更像是对完成完成产品待办列表项（Product Backlog Item，简称PBI）或¶3Sprint待办清单项（简称SBI）所需工作量的一种最佳推测。如果团队采用例如天或者小时这类绝对估算单位，可能会让相关方有一种认知，团队只需要假设每位成员每周工作40个小时，就能算出某事项的预计交付时间，甚至还能“证明”团队可以提前完成该事项。但关键问题在于，“每周工作40小时”本身就是一个高度理想化的假设。相关方基于这种简单假设推倒出的估算结果，与团队结合实际情况做出的估算就会存在偏差，而这种偏差往往会破坏双方之间的信任。 而且，当团队试图解释这种偏差是“实际工时“与理想工时”的差异所致时，相关方往往也会对此心存疑虑。

另一方面，¶14开发团队也需通过流程改善来提高自身的交付能力 。 比如通过移除障碍来帮助团队的提高Sprint速度。但如果没有一个基于估算数字的速度衡量标准，我们很难或者基本不可能对流程改进的效果做出有效的评估。

开发团队和产品负责人都希望估算能够达到一定的准确度。可人们很难对绝对单位做出准确地估算（比如米，天）（参见《Scrum：事半功倍的艺术》(Scrum:The Art of Doing Twice the Work in Half the Time [SS14], 第118页及以后内容，以及·], 第125页以及以后内容）。研究表明，使用相对单位进行估算的准确性往往更高。使用绝对单位估算时，估算所用的单位本身就隐含着相应的时长概念。 比如， 人们能对“100米跑道”的长度达成共识，但要就“跑完100米需要多久”达成一致却十分困难。不过，即便我们无法就”跑完100米需要多久”或“跑200米需要多久”达成共识，却能基本认同，“跑完200米的时间大概是跑完100米所需时间的两倍”。因此，当经验能告诉我们跑100米需要的时间后，我们就应该能推算出跑完它的两倍距离（200米）需要多长时间了。

因此，应使用无单位数值来估算工作量。采用相对估算的方式， 用一些大家公认的简单的工作项作为基准估算出点数，再通过相对估算的方法来得到其他工作项的工作量。

在估算产品待办列表项时，初始基准可以是一些团队达成共识，充分理解的产品待办事项。对于¶72Sprint待办清单，初始基准则可由开发团队自主选择，可以是某项任务，某个交付物，也可以是其他任意度量单位，但核心是团队对该基准所需的工作量已达成共识并且充分理解。
不管是以上哪种情况，团队都应当考虑的是完成该事项所需的全部相关工作，确保该事项达到成“完成”的状态（参见第82段“完成的定义”（ Definition of Done））。

团队可以用每个Sprint的估算点数作为单位，来传达自己的速度信息。（参见Notes on Velocity）

该估算需涵盖开发团队将产品待办列表项开发至“完成”状态所需的全部工作。

掌握了“速度基准”后，团队便可以得出自身的速度，并可将其用于交付成果的完工预测和流程改善的效果衡量。在Scrum框架中速度的常用方法，可参见¶67 Running Average Velocity 和¶68 Aggregate Velocity。

规划扑克（ Poker-Planning），由格伦宁（Grenning）提出，后经科恩（ Cohn）在《敏捷估算与规划》(Agile Estimating and Planning [Coh05] ) 一书中进一步阐述和推广，是一种德尔菲法（Delphi technique）的现代实现，并且已经被证明是生成估算点数的卓越方法。规划扑克对应斐波那契数列，基于非线性量表来帮助人们打破线性思维。使用斐波那契数列的核心逻辑在于，允许的估计值之间的距离会随着估计值的增加而增大，这恰恰反映了估计值越高，不确定性就越大的规律。为了削弱人们对大数值估算准确性可能存在盲目信任，该量表会将较大的斐波那契数进行向下取整（例如，21 会变成 20，因为 21 的有效数位过多，易造成估算精准误导等等）。

团队在进行规划扑克估算时，通常会设定一个基准。这个基准一般来说就是把1、2、3这样较小的数字作为工作量关联到开发团队高度熟悉且有信心的¶58小的任务事项上。在第一轮估算完成之后，借助相对估算的传递性，所有已估算的事项都会成为基准项。这就使得参考用户故事这类技巧不再必要。

有些团队会针对每个事项分别给出悲观和乐观的估计值，以此作为预测结果不确定性的附加说明。在Scrum 的实践中，更常见的做法是为每事项给出一个团队达成共识的单一的估计值，然后根据历史数据，通过实践方式单独推导出置信区间。这种做法不但能加快估算进程，还能为置信区间的合理性提供坚实依据，使其不被视为为规避责任而随意设定的范围。相关内容可参见¶49 发布范围（ Release Range）。

在Scrum实践中，一个常见的估算方法被称为“小熊软糖橡皮熊“（Gummi Bears），罗恩·杰佛里斯（Ron Jeffries） 于1999年首次提及，也有资料显示，该名称源自约瑟夫·佩尔林     （Joseph Pelrine）领导的一个极限编程项目。

由CA软件公司（CA Software）和卡内基梅隆大学（Carnegie Mellon University）软件工程研究所(SEI)联合发起的一项调查显示，在50000个Scrum团队中，90%的受访者认为，使用估算点数的效果优于仍然针对Sprint待办事项使用“小时”作为估算单位的混合估算法，而后者的效果又优于不估算模式，不估算模式则又优于全部以“小时”为单位的估算。

团队也可以使用估算点数对Sprint待办列表中的项进行估算。如果Sprint待办列表和产品待办列表采用相同的估算单位，那么对于某一产品待办列表项，团队就可以通过汇总在Sprint中为将该项推进至“完成”状态所必须的全部任务的的估算值，与该项的最初估算值对比，来核查是否团队在估算该产品待办事项时是过于乐观还是悲观。事实上，团队最初的估算往往偏向乐观，因为团队会在设计实施的过程中不断发现和识别此前未遇见的新增工作。

估算点数本质上只是一种方法。团队可以通过持续改进该方法的使用方式，来规避常见的陷阱。其中最严重的一个问题是，并没有让所有的开发人员参与估算；第二大严重问题则是允许不当影响施加到他人身上。此外，该方法还有一些更精细的改进方向，这些改进虽看似细微，却能带来显著效果；（相关内容可参见《 IEEE 软件》期刊¶30 IEEE Software 30 [Jør13]）。在此需要记住的核心点是项目进度应由实际执行人员来把控，而人们往往难以准确预估绝对时间单位的估算值。

如果开发团队成员对某个事项的理解程度足够深入，深到足以支撑对其进行估算，那么通常也能足以支撑他们完成该事项的设计开发与实现。事实上，进行估算的主要原因之一是让团队尽早思考问题以及相应的解决方案，这样一来，当真正着手实施方案时， 大家就早已成竹在胸了。相关内容可参见¶64 “细化的产品待办列表”。

译者：唐中友

  校对：吴梦竹