Scrum 中的敏捷估計？故事點和計劃撲克 - IT 觀察者隨筆

角色敵意：需求單位和開發單位不再是交付可以給用戶帶來利益的產品，而是為了各自的目的互相攻擊，以避免承擔額外的責任。因此，需求單元和開發單元根本不是一個團隊的情況。
責任：團隊認為“我沒有錯，所以延遲不是我的責任”，而不是優先考慮用戶需求。
需求凍結：開發者迫於期限壓力而被迫更改需求，否則會被耽誤，責任將落在開發者身上。因此，要么需要加班加點製作隱藏大量錯誤的東西，要么製作某種不符合用戶需求的功能；兩者都會降低用戶滿意度。
低質量：PM的地位往往高於開發人員。因此，為了趕上合同期限或避免處罰等，球隊會被要求“先完成，後求更好”，但最終往往是“先完成，後求好” 。” 技術債務的積累越來越多，結果就是現實世界的責任鏈模型，在鏈的最末端承擔著最大的責任和成本。所以團隊就像stack pop，開發者一個一個都撐不住，這也是項目公司工程師經常流失率高的原因之一。
提高代碼權重：為了優化效率，總是用最熟悉的人的位置來估算工時，所以最熟悉模塊和流程的人總會關心相關的需求. 到頭來，只有那些人才能維護自己的代碼，就像潘多拉的盒子，你永遠不知道打開後會跑出哪些牛鬼蛇神。因為黑匣子經常很髒，但公司不知道如何解決這個問題。你也希望他不要離開，否則有些代碼看不懂。

解決方案

這裡提出的解決方案是在 Scrum 中估算需求復雜度的常用方法，但即使不是 Scrum 團隊，也建議讀者能夠根據原則和設計目標確定估算團隊的最佳方法.

請記住，如果沒有靈丹妙藥，其他人的最佳實踐不一定適用於您的團隊，因此首先要了解您的團隊目前遇到的問題是什麼，然後從其他人的實踐中找出適合您解決問題的方法，只要不引起新問題或新問題的成本風險是可以接受的。

這裡用來估計需求復雜性的單位是故事點（相對單位），而不是工作時間（絕對單位）。

這裡用來估計需求復雜度的單位是故事點（相對單位），而不是工作時間（絕對單位）。這樣做有幾個原因：

1、比較不會因人而異：需求的複雜程度往往因人而異，實踐所需的時間因人而異。

2.“相對”比“絕對”更容易評估：如果看工作時間，就需要估計絕對數，在估計過程中需要考慮實施細節。要使用故事點來估計複雜度，只需將大小與其他需求進行比較即可。

例如，很難說清楚“一座塔有幾米高”，但更容易指出“這座塔比那座建築高約 2 倍”。

3. 估計一個用戶故事的故事點的壓力小於估計它的工作時間：關注需求本身，不用擔心自己的資源和項目資源，簡單評估需求的複雜性。在估算過程中，團隊成員的壓力較小，可以像遊戲一樣參與軟件開發。

雖然需求的複雜度往往與工時成正相關，但由於實施條件的不同，還是有可能有一個故事點高的特徵，對工時的需求低於故事點。但是在 Scrum 中，您可以使用迭代 sprint 來評估每個 sprint 團隊可以消化多少複雜性。對於 PO/PM 來說，與其估計一個不成功的時間進程，不如估計一個更準確、更客觀的時間進程，以便他們在第一時間了解，距離項目預期的時間進程還有多遠。如果資源有限，如何確定需求的優先級或尋求其他支持。

接下來，解釋解決方案的各個方面。

什麼時候

在決定誰需要做之前進行評估：這樣做的好處是最大限度地減少開發人員的個人因素。因為你不知道誰來做，所以沒有必要因為你自己的任務或截止日期而高估添加緩衝區。

誰

只有做事的人才能一起評價：兩個關鍵點：

只有做事的人才能估計。需求單元估計的時間或複雜度是不客觀的，因為他們不是實際的工作人員，也沒有權力影響開發團隊基於工作負擔評估的估計。這也使得更容易避免從截止日期開始評估需求的複雜性。
一起做事的人估計。因為你不知道誰來做，每個人一起估計的數字很容易在討論和重新估計後達成共識。每個人都有參與，他們就會有參與感，而且因為每個人都有參與，所以估計結果是由每個人決定的，所以以後誰來做就不會抱怨了。

什麼

使用規劃撲克來估計故事點。

撲克牌和斐波那契數列

Fischer 級數有一個有趣的特點，每個數字都是前兩個數字相加。另一方面，數字與下一個數字之間的差異越大，差異越大。

如上所示，8 和 13 之間的差距是 5，而 13 和 20 之間的差距是 7。但是，這與估計需求的複雜性有什麼關係呢？我們不在數學課上。

與斐波那契數列相關的估計特徵

估計也有一個特點，就是越大越準確，把需求或任務切得越細粒度越大，往往估計得越準確。就像杯子裡裝了一塊不規則的大石頭，中間會出現更多的縫隙，就是不對齊或者浪費的部分。如果安裝尺寸更細、不規則度相同的石材，縫隙會比較小，而且容易調整，可以更方便地填補縫隙。

即使前面的數字相差比較小，也無所謂，因為數字小，說明動作靈活，風險低。如果由於某些因素導致時間估計不准確，那麼前面小數的任務就是加班20分鐘左右。而不是加班2、5天。

因為大的數字差距很大（費米級數前後兩個值的差異比接近1.618），可以避免“這個複雜度是20還是21”的估計。“如果你想要 13，你想要 20，你想要 40。

這樣的差距可以突出對相同要求的估計差異，因為幾乎所有這些要求都差 1.5 倍以上。這個比率很容易讓人類判斷相對大小，因此可以減少許多細微差別和不必要的重新估算過程成本。

撲克牌中的特殊號碼

另外，上圖可以看到幾個特殊的數字，分別是0、無窮大和問號。

0可能表示這個需求根本不需要做，或者已經完成了。
無窮大意味著需求是明確的，但是超過最大數量的則表明需求需要細分為多個更小的需求。
問號表示需求不明確，需要PO/PM解釋或澄清。

如何

1.首先定義復雜度單位1，比如單表綜合查詢的功能。因為我們的估算過程是基於相對規模的，所以我們首先定義了比較基準的單位，團隊估算後就有了比較的依據。

2. 主持人大聲說出要求（例如用戶故事卡），以確保每個人都理解要求，並且每個人都提出自己估計的複雜性。使用計劃撲克的原因是因為您評估的數字可以同時呈現，而不是輪換您評估的數字。很容易把數字翻出來，導致後面的人的結果受到前面的數字的影響。

3.如果團隊中有不同的估計，這兩個估計是最小的和最大的，他們會評估為什麼它們是複雜的或簡單的。在上面的例子中，在估計過程中，如果一個人估計故事點是13，大多數人估計20，另一個人估計40。13和40幾乎差了3倍，所以基本上肯定有一些重要的信息有沒有被同步。

比如估計13的人認為這個需求和過去的一個需求幾乎是一樣的，而且這個需求並沒有想像的那麼複雜。估計 40 的人可能會覺得比較複雜，因為他對這個要求或過程不夠熟悉。

4. 完成評估理由的最小和最大數字，並進行進一步的投票。如果仍然有不同的票數，並且絕大多數人有共識，並且沒有一致認為估計的複雜度與共識複雜度只有一個級別，你可以詢問估計不同的成員是否他們可以接受您評估過的數字。

5. 如果數字在一個水平以上仍有差距，或者無法達成共識，重複步驟 3 到 5，直到達成共識。

同樣，只有真正執行任務或完成要求的人才可以參與投票過程，PO/PM 不能干預。

為什麼

這種估算方式有幾個優點：

一起工作的人決定一個合理客觀的估算結果，有參與感，沒有抱怨。
決策的結果是 PO 和 Team 之間的共識，這將減少未來以牙還牙的情況發生。
每個人都可以理解需求。未來，每個人都可以充當滿足要求的人。當需要支持時，人們也可以互相幫助或支持。
在你這樣做之前，你可以澄清需求中不清楚的部分和有疑問的部分。
在你做這件事之前，你可以找到在團隊中工作的最佳和最有效的方式。
除非整個團隊都是一個不靠譜的人，否則這個數字反映了估算是團隊共享的，PO可以理解需求和評價之間的差距。
通過比較需求之間複雜度的相對大小，未來的PO就能承諾一個迭代能完成多少工作，就有了比較的依據。

結論

通過上述估算過程，這樣的決定是公開、透明、客觀和自願的。對於兩個角色：

採購訂單/下午：

不要擔心某些成員會高估緩衝區的任務。
了解在評估過程中實施要求或任務的潛在困難。
了解需求中是否有需要明確說明或誤解的部分。

對於團隊：

對於不再做事的人，按照期限給予不合理的時間限制。
開發人員在開始處理任務之前進行知識交流。不管預估數量是增加還是減少，需求更清晰，預估也更客觀。
因為你仍然不知道誰在認領這個任務，所以可以客觀地完成估算過程，並在團隊共識的情況下，通過這個過程你知道誰熟悉這個任務。當你真正做到這一點時，你可以結對編程或知道向誰尋求幫助。

本文提出的解決方案是一種常見的解決方案。重點不在於形式，而在於敏捷估算過程中各個環節的設計目的，以解決什麼樣的問題。

問題

PM/PO 的礦

結果