10.15 估算与预测

概述与动机

每个软件团队都会被问到同一个问题：什么时候能做完？这个问题背后是软件开发工作量估算，也就是在尚未动手之前预测某件事需要多少工作量的实践。这是我们所做的最难的事情之一，也是最容易做糟的事情之一。麻烦在于，软件是一种探索性工作。你在构建一个从未存在过的东西，而你对这个问题的许多认识，只有在构建过程中才会显现出来。预测「学习」所需的工作量，与预测「重复一项已知任务」所需的工作量，本质上是不同的。

为什么要把这当作一门独立的学科，而不是项目管理（第 10.6 章）的一个角落？因为失败的模式如此一致，代价又如此高昂。团队常常在没有任何证据支撑的情况下，承诺一个单一的日期，然后在现实早已与之矛盾之后，仍然坚持捍卫这个日期。领导者把估算误当作承诺。合同把一个下午拍出来的数字冻结下来，让人们对着它负责一整年。结果就是交付延迟、信任被侵蚀，以及一种没有人敢说出真实想法的文化。把这件事做对，靠的与其说是更好的数学，不如说是诚实：分清你知道的和你希望的，并把不确定性当作不确定性来沟通。

在企业和政府场景中，这件事的风险会急剧上升。企业会围绕年度预算，为一系列相互关联的项目组合提供资金，并期望用确切的数字来分配资本（第 10.1 章）。政府在拨款规则下作出公开承诺，签署固定价格合同，一旦日期延误就要向立法者交代。在这两种场景中，产出一个自信的单一数字的压力都极大，而使这个数字不可靠的深层不确定性，并不会因为某个重要人物想要确定性而消失。本章主张一种不同的姿态：在估算有助于决策时才去估算，用证据而非乐观情绪来预测，并诚实地说出这个范围。

关键原则

估算是预测，不是承诺。 把它与目标和承诺区分开来。
不确定性是真实存在的，所以要把它表达出来。 一个带概率的范围，胜过一个虚假的单一日期。
过去比乐观情绪更能预测未来。 优先采用有据可查的历史数据，而不是凭空猜测。
拆解是为了理解，预测是为了承诺。 小切片能同时降低风险，也降低估算的必要性。
采取外部视角。 在信任自己内部的故事之前，先与过往类似的工作作比较。
持续重新预测。 一个只做一次、从不更新的预测只是装饰品。
只有在答案会改变决策时才去估算。 否则那就是浪费。

建议

把估算、目标和承诺区分开来

本章中最有用的一步，不花一分钱：把三个概念区分清楚。估算（estimate）是你对某件事需要多长时间的诚实预测，并附带其不确定性。目标（target）是你希望达成的业务目的，比如一次展会发布或一个监管截止日期。承诺（commitment）是你向他人作出的、打算兑现的承诺。这是三件不同的事情，把它们混为一谈，正是项目开始自欺欺人的方式。当一位领导听到「大约三到五个月」却写下「三个月」，而销售团队向客户承诺「十二周」时，一个估算就在无人决定承担这份风险的情况下，悄悄变成了承诺。

每次都要说清楚你给出的是哪一种。如果被问及日期，就以一个范围的形式给出估算，然后让业务方据此设定目标，并有意识地决定要承诺什么。承诺应当是一个睁大眼睛作出的选择，权衡估算的不确定性与错过目标的代价。这项纪律与你的组织如何作出并记录决策（第 1.5 章）直接相关：承诺是一项决策，它应得到决策应有的严谨，而不是走廊里的一次点头。

理解估算为何会错，以及会朝哪个方向错

软件估算的错误并非随机的。它们以可预测的、系统性的方式出错，了解这种模式，就能对其加以纠正。在任何工作的早期，你都身处不确定性锥之中：在起点，你的估算很容易向任一方向偏离多达四倍，而这个范围只有在你不断构建和学习的过程中才会收窄。在锥形张口最宽的地方，去承诺一个精确的数字，就是在承诺一个你尚无法支撑的数字。

在这种结构性不确定性之上，还叠加着一种人类的偏见。规划谬误是我们持续存在的一种倾向：低估自己计划所需的时间、成本和风险，同时想象最好的情况。我们描绘出一条顺利的路径，忘记了打断、集成中的意外和请病假的日子，产出一个假设一切顺利的数字。留出缓冲（padding）是常见的防御性反应，但凭感觉加上去的缓冲，不过是在第一次猜测之上又叠加了一次猜测，而且一旦日程收紧，这部分缓冲就会被谈判掉。解药不是更强的意志力，而是方法：把预测建立在类似工作实际花费的时间上，而不是这项工作从内部看起来的感觉上。

使用拆解和专家判断，同时了解它们的局限

这些常用技术值得了解，也值得划定边界。拆解（decomposition）把一个大型交付物拆分成你可以推理的更小部分，再把这些部分汇总起来。它之所以有效，是因为人们对小型、熟悉的事物估算得远比对大型、模糊的事物准确，也因为把许多独立的条目相加，能让一些高估和一些低估相互抵消。它的局限在于，拆解会遗漏那些「盒子之间」的工作：集成、协调，以及你没有想到要列出来的任务。专家判断和类比法估算（“这就像我们去年做的报表模块，那花了两个月”）速度快，往往也出奇地准，但它们会继承估算者本人的乐观情绪和盲点。

对任何必须给出数字的事项，优先采用三点估算法，它要求给出一个乐观值、一个最可能值和一个悲观值，然后将三者合并，常用的方式是 PERT 加权平均（乐观值加上四倍最可能值再加悲观值，除以六）。这里的价值不在于那个精确的公式，而在于三点估算法强迫你把不确定性大声说出来，并产出一个范围而不是一个虚假的点值。故事点（story points）和T 恤尺码（t-shirt sizes）（小、中、大、特大）等相对规模估算方法，通过把条目相互比较，绕开了预测精确工时的陷阱。它们在排序和粗略产能估计方面表现不错，但应把它们当作预测的输入，而不是可以直接流通的「货币」。点数不是工时，用速度（velocity）乘以点数来产出日期，会把相对规模估算本想避免的每一个问题重新引入进来。

基于你自己的流动数据进行概率预测

这里有一个能改变一切的转变：不要再让人去猜测工作要花多长时间，而要开始测量你的团队实际完成工作的速度。你的交付流水线（第 11.2 章）已经产出了你所需要的数据。如果你追踪吞吐量（）你的团队每周完成的条目数（）你就可以从过去而不是从希望中预测未来。一个在过去三个月里每周完成六到十一个条目的团队，极有可能在大约四到七周内完成剩下的四十个条目。这个预测立足于证据，并且随着每周新数据的到来自动更新。

更严谨的做法是运行一次蒙特卡罗方法模拟：从你的历史每周吞吐量中抽样数千次，构建出可能完成日期的分布，然后以概率的形式读出答案。「我们有 85% 的概率在 3 月 14 日前完成，有 50% 的概率在 2 月 28 日前完成」，这比「它将在 3 月 1 日完成」要有用得多，也诚实得多。这种方法与排队理论（第 11.3 章）直接相关：前置时间等于在制品数量除以吞吐量，因此支配工作如何流动的同一批流动指标，也同样支配着工作何时会到达。概率预测需要历史数据和相对稳定的流程，这正是它会奖励那些把工作切小、让流动保持平稳的团队的原因。它同时也悄悄地去除了大部分估算仪式，因为你不再需要给每个条目定大小，也能知道整批工作何时落地。

对大型项目采取外部视角

对于庞大、周期长、代价高昂的项目，个体估算乃至流动预测都可能产生误导，因为一个全新的项目还没有吞吐量历史，而它的内部故事恰恰是规划谬误最容易发作的地方。解药是参照类别预测：找到一个由类似的已完成工作组成的参照类别，看看它们实际花费了多长时间、多少成本，在信任你自己自下而上制定的计划之前，先把你的项目放进这个分布中。如果贵公司同类平台替换项目的实际耗时，平均比最初的估算超出 60%，那么这个数字，比你团队刚刚拼凑出来的那份整洁计划，更能说明你的项目会如何。外部视角让人感到泄气，而这恰恰是它的价值所在：它对抗的正是每一份全新计划都会携带的乐观情绪。把它用于组合投资和大型项目的预算编制（第 10.1 章），在那里，一次系统性超支的代价是以百万计的资金和信誉来衡量的。

通过切得更小来减少估算，并按延迟成本排序

有时候，正确的估算量几乎为零。#NoEstimates（不估算）论点，在其合理的内核中指出：如果你把工作切成足够小的碎片，每片只需一两天，那么单个碎片的估算就不再重要了。你只需数一数吞吐量，然后据此预测。当切片均匀且很小时，精细的规模估算就是浪费：它消耗精力去产出预测根本不需要的精度。这并不是反对提前思考，而是主张通过把单个碎片切小，让单次预测本身变得廉价。

仍然需要作出决策的是顺序。当你无法同时做完所有事情时，就按延迟成本（cost of delay）来排序：即某项工作每延迟一个单位时间，你所损失的价值。一个能在下个季度解锁大额合同的功能，延迟成本很高，即使有一个更容易实现、但可有可无的功能存在，也应当优先于它。将延迟成本与工作量相权衡（精益思想中的「加权最短作业优先」启发式方法），能比凭直觉排序的待办事项列表更可靠地告诉你接下来该做什么。请注意，这重新构建了整个对话：不再是「一切什么时候能做完」这种邀人给出虚假精确性的问题，而是「接下来完成什么最有价值」（）这是一个你能够真正回答的问题。

权衡：优点与缺点

方法	优点	缺点
单一日期估算	简单；正是利益相关者想要的答案	精确地错；掩盖风险；无意中变成承诺
三点估算 / PERT 估算	迫使不确定性公开化；成本低	仍是猜测；公式暗示了虚假的严谨性
故事点 / T 恤尺码	速度快；有利于排序和粗略产能估计	不是工时；速度换算会把单一日期偷偷带回来
概率化流动预测	基于证据；自我更新；诚实的范围	需要历史数据和稳定的流动；看起来不那么「确定」
参照类别预测	纠正大型项目上的乐观情绪	需要可比的历史工作；听起来令人泄气
#NoEstimates（小切片）	消除浪费；靠计数来预测	需要有纪律的切分；对想要数字的资助方而言令人不安

核心张力在于人们想要的确定性，与工作本身所要求的诚实之间。资助方、高管、合同和立法者要求一个确切的单一日期，因为单一日期便于预算、承诺和辩护。而软件很少能支撑这一点。化解这种张力的方式，不是编造确定性，也不是拒绝回答，而是用概率这种「货币」来回答：一个带置信水平的范围，并随证据而持续重新预测。再配合小切片，让早期、真实的交付，取代遥远、想象中的交付，成为人们信任的东西。一个已演示的增量，胜过任何估算。

与团队讨论的问题

当有人向你要日期时，你给出的是估算、目标还是承诺，房间里的每个人都清楚这一点吗？ 这是一个能以最小代价预防最大损失的问题。在大多数组织中，这三者一旦脱口而出，就会坍缩成同一个数字，而没有人决定要承担「预测变成承诺」这份风险。带一个真实的例子来：追溯你上一个已承诺的截止日期，回到它第一次被说出口的那次对话，问一问它在当时是否只是一句穿着西装的乐观猜测。这个答案应当永久改变你的语言方式，使估算以范围的形式发出，目标被明确标注为业务愿望，而承诺则是在权衡了不确定性、并作为一项决策被记录下来之后，才被有意识地作出的（第 1.5 章）。如果你的团队无法指出某项承诺是在什么时候被有意识地接受的，那你们就是在无意中许下承诺。
你能否用实测的吞吐量而不是全新的估算来预测你的下一次发布，是什么阻碍了你？ 大多数团队其实已经拥有回答「什么时候能做完」这个问题所需的数据，只是闲置在他们用来追踪工作的工具里，没人用。如果你知道你的团队在过去一个季度里每周完成了多少条目，你就可以模拟出完成日期的分布，并给出一个概率，而不是一个愿望。带上你实际的吞吐量历史和剩余条目数，把基于流动的预测与团队凭感觉估算出的日期作比较；这中间的差距通常很有启发性。如果阻碍在于你的条目大小差异悬殊、或者你的流动很不稳定，那本身就是一个值得关注的发现，因为不稳定的流动无论如何都是一个值得修复的交付问题（第 11.2、11.3 章）。从估算转向测量，往往更多是一个决定信任自己历史数据而非乐观情绪的决策，而不是一次工具变更。
对于你目前最大的项目，你是采取了外部视角，还是只搭建了一个内部计划？ 大型项目正是乐观情绪复合累积成昂贵超支的地方，也是一份自信的自下而上计划最诱人、也最不可靠的地方。应有的纪律是：指出一个由组织内部或外部类似的已完成工作组成的参照类别，找出它们实际花费了多少、耗时多久，并在为自己的数字辩护之前，诚实地把你的项目放进这个分布之中。带上数据：这里的同类项目在过去是如何超出最初估算的，你当前的计划是否暗自假设你会击败其中每一个？如果是这样，你就是在赌自己是例外，而基准比率可靠地表明，这个赌注通常会输。外部视角会让你的预测不那么好看，但对将会记住你给出的数字的资助方和审计者而言，也会更站得住脚（第 10.1 章）。
当资助方、合同或立法者要求一个固定日期时，你如何在不撒谎、也不拒绝回答的情况下作答？ 这是压力最大的地方，也是诚实的团队最容易屈服的地方，因为「9 月前有 70% 的可能」听起来，比竞争对手自信的「9 月」要含糊得多。对大型组织而言，风险成倍放大：一个固定日期会渗透进预算、依赖项目和公开承诺之中，因此一个为了图省事而选定的数字，一旦延误，就会变成一个系统性的负债。带上你实际打算使用的表达方式、一个带置信水平的范围的具体案例，以及一个你可以坚定承诺的早期小增量，同时把后续范围留作一个已获资助的区间。需要权衡的现实考量是，有些截止日期（一次监管切换、一场展会发布）确实是固定的，而正确的做法是固定日期、放开范围，而不是假装工作量是确定的。在企业和政府场景中，把这一点与合同的构成方式联系起来：一份模块化、按增量拨款的协议，能让你诚实地承诺一个有价值的核心部分；而一份锚定在遥远里程碑上的单一固定价格、固定范围合同，则恰恰会逼出那种造成超支和头条新闻的虚假确定性。
你的团队如何决定接下来构建什么，明确按延迟成本排序会改变这个顺序吗？ 大多数待办事项列表是按直觉、谁的声音最大以及粗略的工作量的混合方式来排序的，这在无意中优化了「容易的胜利」，而不是「有价值的胜利」。延迟成本，即一项工作每延迟一个单位时间所损失的价值，把问题从「一切什么时候能做完」重新构建为「接下来完成什么最有价值」（）这是一个你能够用证据来回答的问题。带上三四个真实的待办事项，诚实估算每一项能解锁的价值以及这份价值何时会失效，然后按「每周损失的价值」相对于工作量来排序，并把这个顺序与你当前的计划作比较；重新排序的结果通常令人意外，也很难反驳。需要权衡的现实考量是，延迟成本本身也是一种估算，可能被想让自己的条目优先的人操纵，因此要明确谁拥有这些数字，以及它们如何被质疑。对企业组合或政府项目而言，这项纪律正是让你能够向那些各自都认为自己的项目应当排第一的利益相关者，为排序决策辩护的关键，因为排序建立在既定价值之上，而不是政治博弈之上。
谁来负责重新预测，多久一次，当预测发生变化时，谁对采取行动负责？ 一个在启动时作出、此后再未被重新审视的预测只是装饰品，而代价最高的延误，正是那些如果有一个实时预测本可以提前数月显示出来、却没有被显示出来的延误。对大型团队而言，问题很少是缺乏数据，几乎总是缺乏一个固定的节奏和一个明确负责的人：吞吐量在漂移，完成日期的分布在右移，而理应注意到这一点的人却没有在看。带上你实际的重新预测节奏（或者承认根本没有）、上一次预测改变了某项决策的时刻，以及自当前承诺设定以来你观察到的漂移。需要权衡的现实考量是「预测疲劳」，因为过于频繁地重新预测会招致混乱、侵蚀信任，因此要商定一个合理的间隔和一个触发升级的阈值，而不是对每一次波动都作出反应。在企业和政府场景中，把这一点与监督机制联系起来：按固定日程向治理机构通报更新后的概率范围，这样一次延误就会以一次受管理的重新预测的形式呈现给领导者，供其采取行动，而不是在里程碑处才被作为意外揭露出来。

行业视角

初创企业。 几乎完全跳过估算仪式。把工作切成一到两天的碎片，数一数每周完成了多少，向创始人和投资人给出一个不断收窄的范围，而不是一个英雄式的单一日期。你的历史数据很短，流程也不稳定，因此把不确定性锥当作诚实的解释，而不是借口，并且每周五都重新预测一次，让图景变得更清晰。

小型企业。 你没有专门的估算专家，也没有兴趣开规模估算会议，所以让你已经在用的工具替你干活：大多数任务跟踪工具都免费提供吞吐量数据，从这些数据得出的轻量级预测，胜过一个凭猜测得出的截止日期。抵制住购买你根本没人手维护的重型规划软件的冲动；每周简单地统计已完成条目数，给出一个朴素的范围，就足以很好地回答你对客户实际作出的承诺所需的「什么时候能做完」这个问题。

企业。 问题在于，为一个围绕年度资本周期融资的项目组合（第 10.1 章），在众多团队之间保持一致性。用带置信水平的范围取代单一日期作为标准，要求大型项目进行参照类别比较，并建立流动指标，让猜测在一个季度内让位于基于吞吐量的预测。把估算作为一项共享实践来治理，明确界定估算、目标和承诺，使得一个部门产出的数字到达董事会时，含义不会变。

政府。 采购规则和公共问责塑造了一切。一个错过的公开日期会变成头条新闻和审计发现，因此优先采用模块化、按增量拨款的合同，而不是锚定在遥远里程碑上的单一固定价格、固定范围承诺。用通俗易懂的语言向监督机构通报概率预测和参照类别证据，诚实地公布置信水平，让已演示的可运行增量成为公众和审计者信任的证据，而不是承包商在一份乐观计划上的签名。

示例

初创企业。 一家为 A 轮融资演示做准备的九人初创企业，需要知道一项关键集成能否按时就绪。团队负责人没有让创始人向投资人承诺一个日期，而是以范围的形式给出估算，并解释其背后的不确定性锥。团队一直保持每周完成五到九个待办事项的速度，因此他们对剩余工作快速运行了一次蒙特卡罗预测，报告「在本季度第三周前完成的概率为 80%，提前一周完成的概率约为一半」。他们把集成工作切成两天一片的碎片，让单个估算无关紧要，按延迟成本排序，优先构建投资人可见的路径，并每周五重新预测。投资人得到的是一个诚实、不断收窄的预测，而不是一个原本会延误的自信数字。

企业。 一家零售商正在替换其订单管理平台，必须通过要求给出数字的年度资本周期为该项目融资。项目管理办公室没有屈从于为那份整洁的自下而上计划辩护的冲动，而是从三个可比的平台替换项目（两个内部、一个已公开记录）中构建出一个参照类别，这些项目的实际耗时比最初估算超出 50% 到 80%。他们按照外部视角得出的数字来融资，将进度表达为一个概率范围，而不是一个固定的上线日期，并从第一个交付团队开始建立流动指标，使得在一个季度内，猜测被每月更新的、基于吞吐量的预测所取代。当某条工作流出现过热迹象时，重新预测会提前显示出来，管理层得以重新平衡，而不是在截止日期才发现延误。

政府。 一家正在对福利系统进行现代化改造的机构，在拨款制度和公众监督下运作，在那里，一个错过的公开日期就是头条新闻。它没有采用锚定在一个遥远里程碑上的单一固定价格、固定范围合同，而是采购模块化的增量，并公开承诺尽早交付一个有价值的核心部分，后续范围则以一个已获资助的区间、而非承诺的形式表达。项目负责人使用概率预测和参照类别比较向监督机构通报情况，用通俗易懂的语言解释置信水平，使得「9 月前有 70% 的可能」被准确地理解为它本来的含义。已演示的可运行增量成为公众信任的证据，这比任何承包商能签署的估算都更站得住脚。

商业案例：动机、投资回报率与总拥有成本

诚实的估算与预测的回报，主要体现在避免灾难上。大型软件项目超支或失败的概率，远高于按最初的固定计划完成的概率，而损失会不断累积：沉没成本、因交付延迟而丧失的价值、为挽回局面而进行的紧急支出，以及公开承诺被打破后随之而来的信任侵蚀。本章中的这些实践（把估算与承诺分开、基于真实吞吐量进行预测、对大型项目采取外部视角），正是能把一个项目从这条失败曲线上拉下来的那些实践。你买到的不是一个更精准的水晶球，而是关于你当前处境更早、更真实的信息，这让你能够在纠正成本仍然低廉时就作出纠正。

在总拥有成本方面，从估算仪式转向实测预测，通常会降低成本，而不是提高成本。精细的前期估算生产成本高昂，且一旦工作开始就会迅速失效，而基于吞吐量的预测，一旦你的交付流水线产出了数据，几乎是免费的。两个极端都会花钱：过度估算（无休止的规模估算会议，产出无人使用的精度）和预测不足（盲目承诺，之后再为超支买单）。要向领导层说明这一点，把你上一次重大超支的全部成本，与追踪吞吐量、给出范围这件事近乎为零的成本放在一起对比，并展示一个外部视角的预测，本可以从一开始就设定一个可获资助的合理预期。

反模式与陷阱

单一日期承诺： 一个范围坍缩成一个数字，然后在证据面前仍被死守捍卫。
估算洗白： 一个乐观的猜测沿着链条一路上报，最终硬化成一份合同承诺。
把速度当作日程引擎： 用故事点乘以速度，制造出一个虚假的精确日期。
凭感觉留缓冲： 在第一次猜测之上又叠加了一次猜测，一旦压力来临就会被谈判掉。
只有内部视角： 信任一份全新的自下而上计划，却忽视类似项目实际花费了什么。
对一切都进行估算： 为已经足够小、足够均匀、可以直接靠计数来预测的切片再做一次规模估算，而这个估算不会改变任何决策。
冻结的预测： 一个在启动时作出、随着现实推进却从未更新的预测。
精度表演： 在不确定性锥张口最宽的地方，把工时精确到小数点后两位。

成熟度模型

第 1 级，启动： 估算是凭直觉得出的单一日期，并被当作承诺；估算、目标和承诺之间没有区分；预测是被动的、临时性的；超支让所有人都感到意外，并被归咎于团队。
第 2 级，发展： 存在一些结构化的估算方法（拆解、故事点、三点估算数字），但各团队的实践参差不齐；估算大多仍是单一数字；速度被用来推算日期；预测只在启动时作一次，很少被重新审视。
第 3 级，标准化： 一套成文的标准在整个组织内被强制执行：估算以带明确不确定性的范围形式表达；估算、目标和承诺按定义被明确区分；团队追踪吞吐量并按固定节奏重新预测；大型项目被要求使用参照类别比较。
第 4 级，管理： 该实践被数据度量和控制。预测准确度会与实际结果进行对照追踪，并核查其校准情况，因此你能够说清你「80% 会在……之前完成」的预测，是否真的十次中有八次兑现；吞吐量和周期时间基线得到维护；延迟成本被量化；预测漂移相对阈值被监控，并触发升级；承诺基于证据而非乐观情绪作出。
第 5 级，协同： 基于流动数据的概率预测是持续进行且被信任的，因为校准历史已经证明了它的诚实；承诺是权衡置信度与代价之后作出的深思熟虑的决策；工作被切得足够小，使得估算量降到最低，延迟成本驱动着排序；估算与组合投资和风险规划相集成，组织会随着预测的变化，常态化地重新界定范围和重新平衡，让计划顺应证据，而不是死守最初的数字。

供讨论的思路

如果每一次估算离开团队时都必须以带置信水平的范围形式出现，单一日期被禁止使用，你的组织会发生什么变化？
你在哪些地方，把精力花在估算那些本已足够小、足够均匀、可以靠计数来预测的工作上？
如果把过去两个季度的吞吐量数据输入蒙特卡罗模拟，得出的预测会与你实际承诺过的日期一致吗？
对你最大的项目而言，诚实的参照类别是什么，基准比率与你当前的计划相矛盾的程度有多严重？
你的团队今天如何决定顺序，明确按延迟成本排序会改变你接下来要构建的内容吗？
当你的组织接受一项承诺时，不确定性是作为决策的一部分被记录下来，还是在日期被写下的那一刻就消失了？

关键要点

把估算、目标和承诺区分开来；把它们混为一谈，正是项目开始自欺欺人的方式。
估算会以已知的方向系统性地出错：不确定性锥使早期工作的范围变宽，规划谬误使乐观成为默认设置。
优先采用基于实测吞吐量的概率预测，而不是全新的猜测；给出范围和置信水平，并持续重新预测。
对大型项目采取外部视角，运用参照类别预测，这正是乐观情绪代价最高昂的地方（第 10.1 章）。
把切片切小，使单个估算不再重要，按延迟成本排序，而不是凭直觉。
只有在估算会改变决策时才去估算，否则那就是浪费。参见第 10.6 章（项目管理）、第 11.2 章（交付）、第 11.3 章（排队理论）和第 1.5 章（决策制定与治理）。

参考资料与延伸阅读

Steve McConnell, Software Estimation: Demystifying the Black Art.
Daniel Vacanti, Actionable Agile Metrics for Predictability 与 When Will It Be Done?（基于流动数据的概率预测）。
Troy Magennis, Forecasting and Simulating Software Development Projects（蒙特卡罗方法）。
Bent Flyvbjerg 与 Dan Gardner, How Big Things Get Done（参照类别预测与大型项目）。
Daniel Kahneman, Thinking, Fast and Slow（规划谬误与外部视角）。
Donald Reinertsen, The Principles of Product Development Flow（延迟成本与队列经济学）。
Vasco Duarte, NoEstimates: How to Measure Project Progress Without Estimating.
Frederick Brooks, The Mythical Man-Month（软件日程为何会出错）。
Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty”（IEEE Software，2006 年）。