在工作中，我们经常会需要对项目进行工作量的评估，以便确保能在规定的工期内完成项目并交付，然而“我们人类实在极不擅长评估”，从“不确定性圆锥”图来看，实际工作量既可能是之前的4倍，也可能是1/4，最初评估的最大工作量和最小工作量会呈现出16倍的差距。那么怎么让评估的工作量越来越接近实际工作量，直至完全一致，是本篇想讨论的内容。
写好用户故事
用户故事在软件开发过程中被作为描述需求的一种表达形式，为了规范用户故事的表达，便于沟通，一个好的用户故事通常会包括3个要素。
角色（who）：谁要使用这个
活动（what）：要完成什么活动
价值（value）：为什么要这么做，这么做能带来什么价值
事实上，我们在编写用户故事的时候经常会忽略“价值”这个要素，而“价值”在3要素中却是很重要的一步，甚至于可以说“价值”重于一切。可能有人会说，用户故事就是用来描述需求而已，我评估也是根据需求内容来评估，至于客户为什么想要做这样的需求，跟我的评估好像没有太大关系，其实不然，客户对价值的解读往往是会影响到我们的方案设计，因为客户可能自己也没想好，但通过“价值”，我们可能可以给客户输出一个更好的解决方案也说不定。
之前做A项目的时候客户提了一个需求调整，希望能在业务管理模块添加业务时，如果搜索不到客户公司可以手动录入临时客户，在当时的我看来因为受限于底层框架体系，改起来非常麻烦，下意识就想要怎么让客户去放弃这种想法。后来同负责这个项目的PM沟通后，决定找客户聊一下这个需求，深挖他的想法，其实客户只是希望，在进行业务添加的同时也可以进行客户公司的添加，否则他每次都要先添加客户公司再添加业务，操作比较繁琐。OK，了解了客户对需求的真实解读后，我们提供了另外一种更快（开发）更好（用）的方案给到客户，客户也比较满意。所以你看，很多隐藏信息都在“价值”上提现了出来，结合我们上篇讲到的“浪费”，这无疑是给我们节省了时间。
比尔·韦克（Bill Wake）发明了INVEST标准用来衡量用户故事的完整性。
独立性（Independent）：尽可能让一个用户故事独立于其他的用户故事。通俗来讲，就是故事之间不要互相依赖，可以通过组合和分解来减少这种依赖性。
可协商性（Negotiable）：用户故事内容要是可以协商的。不要包括太多细节，留有更多的沟通空间。
有价值（Valuable）：每个用户故事必须对客户具有价值。在编写故事的时候尽量站在客户的角度去思考（结合上述讲到的“价值”），甚至于可以让客户自己来写故事（我们公司的项目管理系统就是对客户开放，让客户自己来写需求）。
可评估（Estimable）：开发团队需要衡量用户故事，以便确定优先级和工作量，安排好工作计划。（这里会结合下面的任务分解来展开）。
规模小（Small）：用户故事要尽量维持小规模。规模越大，任务分解、工作量评估等方面的风险会越大。
可测试（Testable）：用户故事要可以测试。其实就是设定一个DoD（Definition of Done，完成标准），以便确定它是可以完成的。
用户故事须细化
通过上述标准写出来的用户故事已经是比较明确的了，但这还不够，因为用户故事通常是比较宽泛的，很难具有实质上的指导意义。所以我们需要对它进行细化，通俗来讲，就是“任务分解”。
前面说到，用户故事列明了我们要做一件什么样的事情，而“任务分解”就是我们要做多少工作才能完成这件事。事实上，我们的评估都是建立在任务分解好的基础上，当然，我们分解的内容，不仅要包括做哪些工作，还要包括在什么情况下才算真正完成，也就是用户故事的可测试性（Testable），这里在任务分解上也同样适用。
任务分解完后，接下来要做的是对故事里这些任务做一个优先级排序，可能有人会说，我每个任务都很重要，都得优先做，错了，一次只做一件事，别忘了我们上篇提到的，“多任务并行”造成的浪费，所以定一个优先级是非常有必要的。但是要怎么定？《敏捷革命》里给了一个建议“哪些事项能给项目带来最大的价值？那就先完成这些事项吧！”
假设一个冲刺周期内要给客户完成一个用户故事，这个用户故事是要做文件上传预览、视频点播，那大概我们会分解出以下任务：
1. 文件上传表单页面
2. 视频点播页面
3. 对接文件上传接口
4. 对接文件预览接口
5. 对接视频点播接口
6. 页面样式调整
按照“价值最大化”来分，为了给客户呈现一些看得见摸得着的东西，页面是必须的，所以1、2两点的优先级比较高，因为视频也需要先上传再做点播，由此可以得出，1比2的优先级会更高，依此类推。而页面样式调整，相比于功能实现比较无伤大雅，所以优先级可以往后调。当然，在项目执行过程中并不是刻板地遵循着计划，如果必要是可以对计划进行调整。
从评估工作量到比大小
任务列好优先级之后，就要评估工作量，如开头所说，我们人类实在极不擅长评估，但是《敏捷革命》给我们提供了一种方法，叫“比大小”，书中所用的是“犬点”，就是用犬类的体型来作为每个任务的规模，评估的时候就用这个“犬点”来确定任务规模大小。我们部门已经开始在使用这种方法进行评估，不过我们不是用“犬点”，我们用的是“鸡”。
1、2、3、5、8，一个斐波那契数列的应用就出来了，我们在冲刺计划里对每个任务都进行了规模的评估，这样我们就可以知道我们一周会用多少个“鸡点”来完成一个冲刺版本，甚至可以推导出完成整个项目所需“鸡点”。
如果把“鸡点”形容成我们做事情的速度，那么我们是否可以做一些事情来加快这个速度，答案是肯定的。我们部门在进行任务规模评估的时候，如果发现有个任务被评为了“大鸡”，说明很大概率这个任务分解得不够细，那么我们就会坐下来一起探讨这个任务是否还有可被分解的空间，是否遇到了哪些阻碍，能否有解决办法或者有哪些细节是本没必要做的，甚至是否可以外包给其他部门去做。
当然，这种模式并不是绝对正确，我们部门也还在摸索当中。世界不存在一成不变的东西，我们可以质疑一切。
小结
1. 学会写用户故事，多思考当中的“价值”所在。
2. 任务分解排优先级依据“价值最大化”。
3. 明确自己的工作速度，并且懂得如何利用集体智慧去消除障碍，想方设法加快工作速度。
最后
以上内容是对《敏捷革命》- “第六章 务实规划，拒绝空想”的解读，书中的一些方法论笔者跟笔者所在部门也在实践中，效果如何需要时间来检验，笔者也会在后续文章继续分享实际工作中遇到的一些问题，各位看官如果对于本章内容有其他看法欢迎留言区互动，如果有更好的方法论也可以跟笔者分享。
