说说鸡蛋估算法

鸡蛋估算法原理

鸡蛋估算法，或者称鸡蛋计数法，在包括软件开发的智慧工作领域，是指对所处理对象进行简单分解后计量个数，直接作为规模。比如在敏捷软件开发中，对于迭代工作的范围大小，直接以用户故事个数为规模，不再细分故事点数，不再识别子任务，也不再估算理想工时数量。

之所以用鸡蛋估算法（也称鸡蛋计数法）来命名这个方法，是因为鸡蛋的大小范围在同一个数量级上，容忍在这个范围变化，不再做更精细的估算。

其实T恤尺寸法也有相同比喻的味道，一般而言，XS，S，M到XL和XXL，价钱都是一样的。不过T恤尺寸法已经被广泛使用成另外一种情形，在这里提及，只是试图说明鸡蛋估算法在早些时候已经有苗头。在有些场合，甚至直接计量需求个数，或者Feature个数作为规模，不再细数需求里面有多少个故事。

鸡蛋估算法的原理，与NoEstimates的原理是大体相似的。从比喻的角度讲，鸡蛋估算法更加容易理解，而NoEstimates在字面表述上显得激进，而且实质上是有估算的。

鸡蛋估算法操作要点

这个方法的前提条件是如何控制“鸡蛋”的大小。鸡蛋和恐龙蛋如果放在一起，那么恐龙蛋就会带来失真的计量，需要把恐龙蛋分解到鸡蛋，才能让鸡蛋计数反映真实的规模。

在具体操作上，对于故事，笔者推荐，鸡蛋故事的范围对等于原来故事点5以内包括5的故事，对于少数可能为故事点8的故事，也可容忍为鸡蛋故事，但不能容忍原来大概是13点的故事。对于感觉到大概大于8点的故事，为了按鸡蛋估算法处理，就需要进行拆分。这样，产品经理或者产品负责人或者BA等，就在源头上就能了解待办事项的规模，在拆分需求的时候就相当于度量了待办事项的规模。

鸡蛋估算法特别适合与最小可上市功能（MMF）一起使用。有些场合下，比如最小可行产品1.0已经上线了，要根据运营情况进行配套的增强升级，直接可以把MMF看成是鸡蛋，统计MMF个数作为规模。

国内例子和评论

1. 廖靖斌：打牌好像不太流行了，流行不估算，把需求拆分到差不多大，迭代尽可能短，看看每个迭代能做几个。
2. 王洪亮：真的流行不估算，不估算直接省掉估算的时间浪费，还要保持可预测性。
3. 郑知道了（郑斌）：我们打了很多个迭代的牌，最后发现打来打去 最后算出来故事点决定的需求数是相对稳定的。既然如此，还要打牌干啥？直接数个数就好了。打牌确实能起到一个需求澄清的作用，但是多数情况下需求本身的歧义不大。
4. 陈勇：恒生电子某个项目用的就是这个，第一个迭代做8个页面结果没做完，第二个起改成7个，一直做了8个迭代，不快不慢。
5. 徐陈飞：我这边现在有团队已经采用了类似鸡蛋估算，也有客户逐步在向这个方向靠，但是需求结构还是守住的，confluence的一页纸需求方法挺适用这类情况的，并且特定如运维团队的需求很难用迭代去计划的时候，鸡蛋也的确是不错的方法。
6. 高云海：我现在基本数个数，的确不用估故事点，也挺准；也可以把故事都分拆成任务，然后数任务个数，做燃尽图，也不错。

国外情况

https://www.infoq.cn/article/book-review-noestimates?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

https://www.stevefenton.co.uk/2018/07/estimates-noestimates-no-estimates/

https://oikosofyseries.com/no-estimates-book-order

Twitter有#NoEstimates的标签，可以查到大量关于此主题的发言

感谢贡献例子和观点的伙伴-廖靖斌，王洪亮，郑斌，陈勇，徐陈飞，高云海。

感谢群主徐毅组织敏捷教练小伙伴们群，让大家畅所欲言。感谢参与讨论的其他伙伴（由于人数众多，不一一列举）。