估算、生产率和计划

估算是为了做Sprint计划，因此估算和计划是连在一起的。

书中提到两种估算和计划方法：一种是用本能反应来估算，就是大家一起拍脑袋，按照故事优先级顺序看看在迭代中能完成该故事的概率，如果低至50%就停止把故事加入冲刺中；一种是用生产率计算来估算，估算每个故事的点数，Sprint计划时团队预估能完成的故事点数是估算生产率，迭代完成时的已完成故事点数是实际生产率，如下图。

感觉这里面有几个细节值得关注。

一是团队完成任务的方式，必须是按照之前确定的优先级顺序来进行。试点团队之前为了能够确保达成迭代目标，采用了比较细化的计划方法，把每个故事的测试用例完成时间、开发完成时间、测试完成时间都计划出来，并分配到每个具体的人。这样做的优点是每个人的任务都明确了，但坏处也很明显，在站会上会看到看板上的任务不是按照优先级顺序来处理的，同时计划缺少了弹性。如果临时有人生病或者请假，都会对迭代计划的完成造成影响。因为团队内部暂时还做不到团队成员之间无差别，即团队成员之间的能力备份还没做到非常好，所以也许还不能很好的应对这种突发状况。前次传湘教练参加团队计划会指导时提出了这个问题，SM当然觉得这个事情短时间还做不到，不过在最新的这个迭代已经开始了尝试，在需求梳理会上大家已经完成了故事的估算，在迭代计划会上不再细分到具体的人员，而是在站会上按照优先级大家自己认领故事。带来如下变化：计划会时间明显缩短，几分钟就开完了；第二天早上的站会时间比之前略长，因为按照优先级排序确定的下一个故事认领多花了一些时间，因为对这块最熟悉的人员在做其他故事，最后是由另外一位同事自告奋勇认领了这个故事。这是一个良好的团队协作和人员能力互相备份的开始，开始可能会牺牲一点效率，长期对促进团队协作和团队的成熟。

二是团队对于完成定义DoD和时间盒的坚守。红色的故事未启动，自然不能纳入迭代完成的故事范围；黄色的故事是Almost Done，做了一半的故事也不能算迭代中完成的故事，另外也不能出现为了把这个故事完成并纳入迭代完成的范围而把时间盒拉长，比如团队利用周末时间加班完成故事，然后迭代评审会、回顾会自然就顺延到下周一的上午召开，下一个迭代的计划会顺延到下周一下午召开。这样时间盒就完全被打破，团队的迭代节奏也没法很好的建立起来。Scrum中的时间盒是强约束，所有活动都有时间盒，必须严格遵守，这样团队才会对自己的认知越来越准确。当然这并不是说任务完不成时不需要加班赶工了，该完成的交付任务还是要完成，不过超出时间盒完成的任务，只能算到下一个迭代中了。

三是这里以故事的原始估算作为团队生产率的衡量标准，这个数值并不精确，但是仍然有意义，它让团队更好的认识自己的能力和自己所处的环境，在回顾会上可以对估算不准确的问题进行调整。同时团队的速率只能是团队自己和自己对比使用，不能用作团队间的横向比较，更不能用于考核。团队的目标应该是不断的提升对自己团队能力的认知水平，提升迭代的承诺完成率，同时提升团队能力。

理想人天和生产率（投入程度）

故事的点数估算是采用理想人天的方法，即想象团队中一位正常能力水平的成员无干扰的处理这个故事需要的天数。无干扰全情投入是一种理想，所以叫做理想人天。每个迭代完成后可以用迭代完成的故事点数除以这个迭代所有可用人天数得到生产率（投入程度），生产率（投入程度）乘以下一个迭代的可用人天数就能够得到下一个迭代能容纳的故事点数。作者将这种方法叫做“昨日天气”。

计算可用人天数之和时要考虑休假因素。

再复杂一点儿，你还可以进行简单的资源计算。假设我们在计划一个4人团队3星期的sprint（15个工作日）。Lisa会休假两天。Dave只能投入50%的时间，另外还会休假一天。把这些加到一起……

……这个sprint一共有50个可用的人-天。

假设在上个sprint里面，由Tom，Lisa和Sam组成的3人团队在3个星期内工作了45个人-天，一共完成18个故事点。现在我们要为下一个sprint估算一下生产率。新伙计Dave的加入让情况更复杂了。把假期和新成员算上，我们在下个sprint中一共有50个人-天。

这个迭代按照故事优先级顺序计划了19个点的故事。作者认为Scrum中最重要的会议是计划会议，一次坏的计划会议可能会毁掉整个迭代，所以详细做个笔记。

我是有底线的