雞蛋估算法原理

雞蛋估算法，或者稱雞蛋計數法，在包括軟件開發的智慧工作領域，是指對所處理對象進行簡單分解后計量個數，直接作為規模。比如在敏捷軟件開發中，對于迭代工作的范圍大小，直接以用戶故事個數為規模，不再細分故事點數，不再識別子任務，也不再估算理想工時數量。

之所以用雞蛋估算法（也稱雞蛋計數法）來命名這個方法，是因為雞蛋的大小范圍在同一個數量級上，容忍在這個范圍變化，不再做更精細的估算。
其實T恤尺寸法也有相同比喻的味道，一般而言，XS，S，M到XL和XXL，價錢都是一樣的。不過T恤尺寸法已經被廣泛使用成另外一種情形，在這里提及，只是試圖說明雞蛋估算法在早些時候已經有苗頭。在有些場合，甚至直接計量需求個數，或者Feature個數作為規模，不再細數需求里面有多少個故事。
雞蛋估算法的原理，與NoEstimates的原理是大體相似的。從比喻的角度講，雞蛋估算法更加容易理解，而NoEstimates在字面表述上顯得激進，而且實質上是有估算的。

雞蛋估算法操作要點

這個方法的前提條件是如何控制“雞蛋”的大小。雞蛋和恐龍蛋如果放在一起，那么恐龍蛋就會帶來失真的計量，需要把恐龍蛋分解到雞蛋，才能讓雞蛋計數反映真實的規模。
在具體操作上，對于故事，筆者推薦，雞蛋故事的范圍對等于原來故事點5以內包括5的故事，對于少數可能為故事點8的故事，也可容忍為雞蛋故事，但不能容忍原來大概是13點的故事。對于感覺到大概大于8點的故事，為了按雞蛋估算法處理，就需要進行拆分。這樣，產品經理或者產品負責人或者BA等，就在源頭上就能了解待辦事項的規模，在拆分需求的時候就相當于度量了待辦事項的規模。
雞蛋估算法特別適合與最小可上市功能（MMF）一起使用。有些場合下，比如最小可行產品1.0已經上線了，要根據運營情況進行配套的增強升級，直接可以把MMF看成是雞蛋，統計MMF個數作為規模。

國內例子和評論

廖靖斌：打牌好像不太流行了，流行不估算，把需求拆分到差不多大，迭代盡可能短，看看每個迭代能做幾個。

王洪亮：真的流行不估算，不估算直接省掉估算的時間浪費，還要保持可預測性。

鄭知道了（鄭斌）：我們打了很多個迭代的牌，最后發現打來打去 最后算出來故事點決定的需求數是相對穩定的。既然如此，還要打牌干啥？直接數個數就好了。打牌確實能起到一個需求澄清的作用，但是多數情況下需求本身的歧義不大。

陳勇：恒生電子某個項目用的就是這個，第一個迭代做8個頁面結果沒做完，第二個起改成7個，一直做了8個迭代，不快不慢。

徐陳飛：我這邊現在有團隊已經采用了類似雞蛋估算，也有客戶逐步在向這個方向靠，但是需求結構還是守住的，confluence的一頁紙需求方法挺適用這類情況的，并且特定如運維團隊的需求很難用迭代去計劃的時候，雞蛋也的確是不錯的方法。

高云海：我現在基本數個數，的確不用估故事點，也挺準；也可以把故事都分拆成任務，然后數任務個數，做燃盡圖，也不錯。

國外情況

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的標簽，可以查到大量關于此主題的發言

致謝

感謝貢獻例子和觀點的伙伴-廖靖斌，王洪亮，鄭斌，陳勇，徐陳飛，高云海。
感謝群主徐毅組織敏捷教練小伙伴們群，讓大家暢所欲言。感謝參與討論的其他伙伴（由于人數眾多，不一一列舉）。

總結

以上是生活随笔為你收集整理的说说鸡蛋估算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。