聊聊故事點背後的故事
Q1、敏捷項目能不能不估算故事點，直接估算工作量？
【觀點一】:在策劃撲克法中先估算故事點有其固有的優點，最無法替代的優點是故事點不是絕對的工作量，避免了團隊在迭代早期盲目的承諾，第一個迭代可以只估故事點不估工作量，是一種保護團隊的行爲，體現了敏捷以人與團隊爲本的文化，多數策劃撲克法沒用起來的團隊往往也是這種文化薄弱甚至背道而馳的。
此時策劃撲克就不是最適合的方法。在估算中如果充分進行了溝通、拆分並理解了估算對象、碰撞了觀點、分析了多方面的影響，就基本是一種好的估算方法，無論你命名爲什麼方法；反之，嚴格按照策劃撲克法的套路執行了但沒有達到上述效果，那還是需要反思原因和改進。
【觀點二】:在特定場景下跳過規模直接估計工作量是可以的，而且更簡單有效，比如：需求相比老產品有延續性，團隊的水平是已定的明確的並且大家看法相同沒有疑義。
內外因素都有很大不確認性時，跳過規模直接估算工作量就是在冒險。這裏內部因素指的對團隊不同場合下開發能力的準確認知；外部因素主要是指需求。
這有點類似於另一個問題：跳過詳細設計可不可以寫代碼？一般開發情況下，我們可採用＂藍帽＂方式思維，一板一眼，嚴謹細緻。但對開發的對象已經非常熟悉，用＂紅帽＂的跳躍思維方式也足以應付多數的情況。
【觀點三】：新研發項目或新增功能項目都可以先估規模再導出工作量（無論作什麼規模單位都可以，我個人更贊同於功能點方法）；產品更新維護類項目則可以直接估算工作量。
我遇到一個客戶，他們是產品類項目，當一個產品推出後，後續就是針對這個產品的不斷地版本更新維護，這個週期可能會延續幾年時間，而一個一個的版本發佈短則一週一個版本，長則一個月一個版本。而這種版本基本上都是對產品的維護，一個變更點可能涉及多個功能點的修改。
所以建議他們直接估算工作量。這裏所說的變更是對發佈版本缺陷修改、性能優化等。不是整塊或整功能的變更。
【觀點四】：讓你估計一個人的體重你怎麼估計？一個人站在那裏，讓你估計他的體重。你是思考了他的身高、體型，與自己或其他知道體重的人做了對比，然後才估計出來150斤還是130斤。在腦袋裏和其他人對比時，對比了身高、體型，爲什麼，因爲你認爲這兩者決定了一個人的體重。
當你估計某個需求的工作量時，你在腦袋裏想了這個功能的大小，複雜度等等，然後纔會得出工作量的估計值，你在腦袋裏估計了規模，不是沒估計規模！你在腦袋裏的運算過程要和其他人溝通一下，這纔有了故事點、功能點、複雜度等等！你想到了，你得說出來或寫出來，和其他人達成一致，這纔是本質。
有些軟件估計規模是沒用的，因爲規模沒有決定工作量，比如人工智能對弈的軟件AlphaGo，對其估計規模就沒有太大意義，複雜度纔是對這類算法軟件最重要的影響工作量的因子。故事點其實不僅僅代表了規模，還包含了複雜度在裏面。
所以，我認爲：在估計工作量之前，是要估計規模或複雜度，無論你叫故事點，還是功能點，或者其他計量單位都無所謂，需要說出來，和別人討論一下！
Q2、在估算的時候，其實無法說服自己去考慮過規模這個維度，甚至需要跟很多人解釋規模的確切定義是什麼。得出經驗判斷，往往就是一個模糊不清晰的過程，爲什麼是3而不是5，也是無法說服自己的。
【答】：考慮規模，複雜度等，就是讓你清晰的過程。估計工作量之前考慮規模，複雜度等，就是要讓你講理！估計爲3人天、10人天的理由是什麼？說出道理來！
不是敏捷要求你做規模估算，而是：你在估計工作量估算時，就做了規模估計！
Q3、感覺就是3人天，沒去細想爲什麼。這也是爲什麼快的一個原因吧。那可能不同的人，在應用經驗法估算的時候，也有不同的思考深度之分。
【答】：快，未必代表好。一大本需求，一拍腦袋，需要3人年，這種估計有啥用啊？爲什麼3人年，得講出道理來，所以需求要拆分、細分，對小需求估算，累加起來，然後得到總數。每個小需求怎麼估計？也得繼續拆分，繼續講理。拆細後，估算的總體結果更接近實際。
這篇博文裏有關於這個理論的描述：https://blog.csdn.net/dylanren/article/details/28239921。
不講理的估算無法說服自己，無法說服別人，不能起到激勵的作用，不能起到作爲管理基準的作用，也就會導致計劃與實際的大偏差，不能承諾，或承諾了也沒人信。
Q4、並非不講理，而是講不出理。也許大腦神經元的關聯並非簡單的線性關係，一些決策不一定非得通過右腦的邏輯思維來組織一個完美的答案，經驗法和模型法的偏差到底多大似乎也沒有定論。
【答】：這裏需要區分一下估計工作量的方法：
1不講理的估算方法。
2經驗法。
3模型法。
你說的講不出道理，是第一種，這在實踐中其實不存在，因爲總能有道理。
經驗法不是不講理。故事點也是講理的。寬帶DELPHI方法也是經驗法，也是講理的，需要大家討論爲什麼那麼估算。
模型法與經驗法的估算差別多大，我有2個研究結論給你參考
Capers Jones、Standish的研究結論表明：採用模型法進行估算的項目成功的概率是採用經驗法估算的項目的2倍！
Q5、如果能明確講出來規模和複雜度及其換算關係，那還叫經驗法嗎？是否屬於經驗法，區別在於這些估算過程的運算邏輯是書面的還是非書面的？預測投入和其準確性應如何平衡纔是合理的？
【答】：我們所說的模型法，是指有數學公式來計算的方法。
其他的都歸類到經驗法了。
在工作量估算時，我們也可以採用定額法：
如，先對歷史的同類的軟件進行類別與規模大小的劃分，得到如下的經驗數據表：
當拿到一個具體的項目需求後，再對新項目的需求歸類、區分規模的顆粒度，然後查表得到工作量的估算：
這個方法裏面的定額是怎麼得到的？
1沒有歷史數據時，靠回憶，靠經驗得到。
2有歷史數據時，要建立歷史數據的性能基線得到定額。
這種定額法是否也算模型法呢？我們也可以認爲是模型法，只不過這個模型是查表得到的而已。
Q6、規模*複雜度*效率=工作量。如果這個也算公式，那它應該不屬於經驗法了
【答】：是的，有公式算模型法。
Q7、數學公式也應該有設想公式和經統計學證明的公式吧。如何證明這個設想公式的有效性？
【答】：數據公式的合理性要做迴歸分析，證明有效性。
很多公司自定義了工作量估算方法，這種方法是否合理呢？需要把實際的工作量與估計的規模進行相關性分析，看看是否強相關！
如：某嵌入式軟件公司將需求細拆分之後，直接用需求的個數代表軟件的規模，沒有采用功能點、故事點、代碼行等方法度量規模，對多個項目多個周的數據採集分析後得到如下的迴歸方程：
轉存失敗某銀行軟件開發公司，也是直接計量了需求個數，然後估計工作量，歷史的79個歷史項目的數據證明了這種方法在本公司內的合理性：
而也有的公司自定義了需求點數，但是歷史數據卻證明了這種方法的失敗，也就是在這家公司內定義的需求點是不合理的：
有一個客戶提供了一個項目的故事點與工作量的散點圖：
此圖可以說明在此項目中採用故事點的方法也是合理的。
在敏捷界也有專家提倡採用雞蛋法估計規模，就像我們買雞蛋時數個數不稱重一樣，其原理同上，只要你數的是雞蛋，而不是把雞蛋與鵪鶉蛋一起數即可。雞蛋的大小要有可比性！不能兩個雞蛋的規模偏差太大！
也有公司採用了業內的公式到自己公司內來使用，比如有的公司採用了COCOMO模型，或者業內的一些度量組織公佈的模型，此時，都需要在公式內用自己的實際數據做調整，否則，這個模型的偏差可能很大！正如我們不能用美國的胖子標準來判斷中國人是否胖類似。
Q8、那經驗法與模型法的區別，是有沒有公式，還是有沒有去做這個證明？
【答】：模型法要有公式或模型。有模型沒有用歷史數據驗證，這是模型本身的問題。
我看到的很多企業是有這個公式的，但是這個公式沒有歷史數據的證明，所以通常都會給客戶提一個改進建議：估算模型或方法的合理性應基於收集的歷史數據通過相關性分析等統計手段進行驗證。
Q9、工作量估算一個作用是預測，做估算需要花時間，花了時間但預測結果不一定準確，如何取捨？經驗法偏差30%，人力資源投入3分鐘，模型法偏差5%，人力資源平均投入1小時。如何選擇？
【觀點一】：可以是一種平衡，需要考慮投入產出，這種投入產出是否可以準確度量呢？這需要思考。另外當我們理解工作量估算的作用時，僅僅是預測嗎？
我們做sprint planning就是爲了做計劃嗎？我們做策劃撲克法就是爲了做估算嗎？
溝通在前，溝通是過程，估算值、估算結果是這個過程的輸出。
做估算的目的我自己更傾向定義爲：
1溝通，達成一致的深刻理解。
2得到一個估算值，作爲計劃的基礎。
這也是爲什麼我力主把COSMIC規模度量方法作爲一種需求梳理的手段導入到項目組中，度量出的功能點是自然的輸出，也可以認爲是副產品。
正如測試驅動的開發，測試不是目的，是手段，產品代碼纔是目的，纔是最終的交付物。
【觀點二】：我認爲在估算時，大家初次對一個故事進行估計，並發現結果不收斂時的價值，遠遠大於收斂的價值，所以估算的價值在於：
1、它是一種對需求是否達成了一致理解的判斷方法。
對需求達成一致理解是需求溝通的目的，怎麼判斷這個目的是否實現了呢？判斷需求是否達成一致理解的方法我們可能羅列出來一堆，但是通過是否收斂來判斷更直觀。
它可是“量化”的。如果收斂了，那麼我們不能判斷需求理解是100%的達成了一致，但是，如果不收斂，我們可以100%的得出來結論，不收斂的原因包括：
a) 有人對需求有誤解，需求理解不一致；
b)需求有缺陷。
通過給出估算值最高和最低兩組人的對需求理解的陳述及討論，我們可以達到第9問觀點二第2條所列的價值。
2、發現需求缺陷，有助於Team的成長
需求能否挑出來錯，那倒不一定，也許能挑出來，也許不能。但是這一定是Team成長、分享的最佳時機。給需求挑錯的方法，大家首先想到的是評審。
在估算值離羣的成員陳述需求理解的環節中，可能得到的結論：
a) 估算值低的：
可能1：對需求想簡單了--證明需求描述模糊 或者對業務的掌握不全面；
可能2：開發資源瞭解更透徹，掌握的開發資源更多。
b) 估算值高的：
可能1：需求想複雜了–-證明需求模糊或者對業務的掌握不全面；
可能2：開發資源瞭解不足。
如果需求模糊，那就是給需求挑出來了缺陷。如果需求沒有問題，針對估算值離羣成員發言的討論就是更有針對性的分享和培訓！
可惜的是，在估算值離羣的成員陳述的時候，大多都說：“我理解錯了”，而不去向其他成員陳述自己到底是怎麼理解的，其他成員也不去追究他們到底是怎麼想的，片面去追求儘快的達成估算的收斂狀態。
如果抓不住怎麼交流需求這個環節，策劃撲克牌估算的價值就大打折扣了。
3、督促TEAM獨立思考自己對需求的理解
如果自己的估算值離羣了就需要解釋自己的看法，爲避免尷尬，聰明的人就要有所準備，那就是如果自己離羣了，自己怎麼表達自己的看法，這是一種壓力！評審的效果如何，部分依賴於評審專家的責任心，如果沒有個人評審效果的評價，他們是沒有壓力的。
4、避免因爲需求缺陷或對需求理解不到位而導致的返工。
Q10、這些附加值是不是隻有估算一種途徑來解決？
【答】：嗯，可以有其他的方法替代。
但是是否比這個方法更好呢？正如很多企業不做TDD，採用其他方法做質量控制，是否效果能比TDD更好呢？
Q11、是否可以根據真實反饋對估算進行修訂？
【答】：可以。
1、對於估算的結果，如何發現和實際結果偏差較大，可以根據實際調整估算結果，對未開工的任務調整估算值。
2、在估算領域中有估算錐的模型，隨着時間的推移，隨着項目的進展，估算的偏差率是逐漸縮小的。
3、如果你採用了模型法進行了估算，y=ax+b, y爲工作量，x爲局部規模。在實際中對幾個需求或幾個模塊用了幾次模型，發現在本項目組中存在一致的偏差，此時你可以調整公式中的b或a的值，來調整估算模型。
如果x是整體規模，即，項目的總規模度量值。模型的不適用性只能到項目結束時才能發現，此時已經沒必要修改估算值了。我們的客戶大地保險是x爲局部規模與總體規模都建立了模型。