做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律。
—— 侯世达，哥德尔、埃舍尔、巴赫
周三的下午，我像平常一样，写着代码听着歌，突然从天而降一份莫名其妙的故事列表，说让我给个人天，用来投标用。作为一个技术异常牛逼的高端程序员，这对我来说岂不是 A Piece Of Shit…哦不，Cake。拿着列表，打眼一看就知道是做什么 — 又是个审批流系统。注册、登录、忘记密码…这些也需要时间？！哦，还要做个SSO，可能要做点数据集成，给个15人天吧！又是一堆CRUD… CRUD 各给2人天一共8个。看起来有4个 Model，乘个4，32个人天差不多。前端还有些工作量，找前端估一下…还有些跟遗留系统集成的部分，这块应该比较麻烦，给个30人天差不多…还要用微服务架构，估计需要一些基础环境，每个组件给3个人天，一共8个组件，算24吧….总共算起来130个开发人天，差不多，再加点buffer，算150吧！差不多了吧…
这一幕是不是有点眼熟？不过，这样的做法可能会带来下面的几个问题：
问题的答案显而易见。那么有同学会说，此时团队的人员还没完成配置，没办法让真实团队进行功能的估计。确实是这个样子，所以我们只能力所能及的去模拟真实团队进行估计。一般，交付项目的团队肯定不会全上非常有经验的同学，人员配比一定会有 leverage，也就是 Senior 人员和 Junior 人员的比例。所以，在估计的过程中，至少要引入 Junior 的同事，能够从不同经验的角度来看待同样的问题，来使估计不会过分“乐观”。
2. 是否有故事卡片之外的工作时间没有考虑到呢？
上文中的估计看起来是采用的经典的“理想人天”估计法，如果使用这样的估计方法，势必要考虑一些虽然没有在故事卡工作量中，但也一定会花费时间的事务，包括但不限于：
回复电子邮件（沟通成本）
面试（内部耗损）
参加会议（包括内部会议，比如站会、Retro、Code Diff、技术研讨会议、客户沟通会议等）
为当前发布提供支持（上线支持）
培训？（内部的 Session）
任务之间切换/被人打断（程序员出栈入栈的消耗…）
修复bug（一定会有 Bug，一定会花时间修…）
写各种文档（对于对文档比较看重的客户，这一部分会占用不少的时间）
这些事务会伴随整个交付过程中发生，基本上都是正常交付必不可少的工作内容，而且根据笔者的经验，这些事情占据的时间并不比完成故事卡的编码工作要少。
3. 故事卡的需求是否清晰呢？
在项目启动前拿到的故事列表，往往只有 Epic 级别的，也就是很粗粒度的故事卡。故事卡中的 AC（Acceptance Criteria，验收条件）往往只考虑了最简单的 Happy Path，然而大部分项目中（尤其是 ToB项目），Exception 才是相对复杂的，这些异常情况往往需要花费更多的时间完成。在这种情况下进行估计，可想而知，一些隐藏的需求点往往难以发现。
问题可能的答案
那么想要解决上面的问题，或者说更好一点的缓解上述问题的方案是什么呢？《敏捷估计与规划》中介绍了一些基本的方法。
首先，要进行集体估计
集体估计可以缓解因为个人能力不同所引发的单点偏差，不同的开发成员对于某个需求在不同角度的阐述，也容易让大家对需求有更全面的理解，也易于发现潜藏在需求中的风险。阐述的过程中，出现复杂问题时，可以及时联系相应的专家资源。对于一些规模较大的卡片，也可以综合大家的意见，进行更合理的拆解。同时，需要由要做次工作的人来进行估计，这样会产生更多的责任感，可以在一定程度上缓解乐观估计的问题（Lederer and Prasad 1992）。
其次，是方法
《敏捷估计与规划》介绍了2种基本的方法：理想人天法和故事点法。
（1）理想人天法
理想人天法就是直接把故事卡估计成理想人天。所谓理想人天，就是“在需求非常明确的情况下，进行编码、测试工作所花费的时间”。就好像篮球比赛一样，每节12分钟，4节总共48分钟，这是比赛的理想时间。但是谁都知道，一般NBA每场比赛都要2个半小时左右，比赛激烈的话三个小时都有可能，比赛真正持续的时间与理想时间是有较大差距的。相比于篮球比赛，软件项目“场外”的工作就更多了，除了上面问题2列出的那些实务之外，像是方案变更引发的大量沟通、集成联调、测试过程中的需求讲解、项目的交接等等，这些工作也需要算到项目时间之内。同时，对于同一个项目，不同的人根据其能力、经验的不同，会有不同的理想人天。
所以在估计完理想人天之后，如何进行实际人天的换算，在实际应用中，仍然是个大问题，所以…最好就不要用了。
（2）故事点法
故事点法就是按照故事卡的规模和难度，给予每张故事卡一个点数。注意，这里的点数代表的不是所需的人天，而更多的是难度系数。
开发人员因为自己技能、经验、能力的不同，解决同样的问题，所花的时间差别是很大的，但对规模的估计却是一样的。就好比从北京到上海，坐飞机1个多小时，高铁5个小时，步行要…一个月左右吧，距离是一样的，根据不同的速度，会花费不同的时间。
同时，人们一般很难对一个规模进行准确的估计，比如从北京到上海的绝对距离是多少，估计没几个人知道。但是，人们能够比较容易的比较两件事物的差距或者说倍数关系，比如：北京到上海的距离跟从上海到香港的距离是差不多的，这个距离是北京到郑州距离的两倍。所以我们在做估计的时候，可以按照难度系数分成几波，然后在内部在进行一些比较和排序，然后按照比较的差距分配一个规模点数，比如1、2、3、5、8、13。
大家可以看到，这个规模点数并不是连续的数字，而是采用了菲波那切这一个神奇的数列。这样的数列有2个好处，一个是不会出现连续的倍数关系，比如4点的故事卡片是2点故事卡片的2倍；其次是表明出规模越大的卡片，其不确定性也承递增趋势，所以会给更高的点数。
有了故事点数，我们仍然无法判定项目什么时间能够交付，因为缺少一个“速度”，也就是团队的开发速度。如果面对的是一个成熟的团队，并且使用类似的技术栈，且与客户的合作模式基本相同的话，那么可以参考前一个项目的速度，来进行交付时间的计算。但如果面对的是全新的客户、不同的技术栈，以及完全重新配置的团队，那么速度基本是不可估的。这时候，有时候会根据 Tech Lead 和 PM 的（Pai）经（Nao）验（Dai），进行硬估：把每个点数转化成N个人天。比如1个点数需要2个人天，那么100个点数的项目就是200个人天。当然，这种方法…说多了会掉泪。
最后，给项目加些缓冲（Buffer）
一般来说，面对这种情况，本着对客户和我们自己负责的态度，需要给项目加一些缓冲区（Buffer）。Buffer 分两种，一种是功能Buffer，一种是进度 Buffer。
（1）功能缓冲
增加功能 Buffer，简单来说，就是把全部的故事列表进行估计，假设得到总点数是100点；然后按照优先级进行排序，挑出其中的MVP，要少于总量的 70%，作为必须要做（Must Have）的部分。剩下的 30% 作为做了更好、不做也不影响主要功能（Nice To Have）的部分，通过这种方式来缓冲项目里程碑的风险。
（2）进度缓冲
进度 Buffer，是用来缓冲估计之外的异常情况引发的项目时间的拉长。进度 Buffer 根据项目的不确定性的差异，计算的方法和结果会有较大差异，有兴趣可以参考《敏捷规划与估计》，这里就不赘述了。不过根据 Leach(2000)准则提出的建议，至少要保持整个项目的20%以上，否则也许不能为整个项目提供足够的保护。
不是总结的总结
上面的这些方法能一定程度的规避风险，给开发团队带来一定的空间，但过分的强调估计和交付计划的准确性，会带来更深层级的问题：
output over outcome。客户更关注功能列表的完成，而不是产生的业务价值。
开发团队会倾向于裁剪用户故事的功能，3个点的故事卡，尽量控制在规定时间内完成，即使可以花更多时间把事情做的更好。
控制需求变更。可以进行需求变更，但这个过程更像是一个异常的情况，而不是喜闻乐见的。
当我们发现了更好的业务点、idea时候，会倾向于隐瞒，以免额外的业务功能会增加工作量。需求变更往往会涉及客户谈判的事情，尤其是当客户观念是传统的供应商管理策略：我来控制需求的全景，能多做点就多做点。
在客户合作和谈判的天平上，客户关系会向谈判的方向倾斜。
估计和计划会使团队和客户更多的聚焦在工作量，而不是工作的价值上。如果能够引导客户从 output 导向的思维转变到 outcome 导向上，那么团队就不用再疲于奔命的完成那些并不会用到的feature上，而是可以有更多的时间去提升产品质量，进一步提升业务价值。
