對於軟件開發人員來說，這是工作中最困難的部分，即使不是最困難的部分。它必須考慮一系列因素，幫助產品所有者做出影響整個團隊和業務的決策。

在軟件開發過程中，團隊經常會遇到一個問題：

如何估計工作時間更準確？

對於項目或產品的所有者來說，這是衡量項目資源和時間表的一個非常重要的信息，但實踐這會帶來許多問題。

許多開發人員總覺得PM正在使用最后期限來回推送。他們不關心功能是否可以满足質量。

“首先完成它，然後尋求更好”因此已經在軟件行業中流傳了很長時間。

許多PM總是覺得開發人員在評估他們的工作時最傾向於“誇大”。似乎他們都使用典型的工作估計方法：“估計實際需要時間的三倍作為緩衝”“

事實上，工作時間不能估計為“絕對準確”，但有一些方法可以估算“相對客觀”。由於工作時間和要求的複雜性，通常存在正相關關係。因此，本文將首先解釋響應需求復雜性的常見問題，提出一個解決方案，並解釋解決方案中許多設計的目的。

問題

開發者的地雷

• “這很簡單。製作它不應該花太長時間嗎？“
• PM今天對你說：“明天之前我必須把它交給你。“在尋求質量之前，先完成它”
• PM後天對你說：“為什麼這個程序的質量如此糟糕？”
• 當它被推遲時，其他同事說：“你怎麼需要花這麼長時間？這有一個現成的代碼供參考。這有一個很好的底層使用。你為什麼不問我？“
• 其他同事：“我只需要一天，你為什麼要花這麼多天？”
• “這是常識！需求即使没提，你應該知道該怎麼做。“

PM / PO的地雷

• “為什麼這麼簡單？花了這麼長時間？“
• “為什麼看到你正在訪問Facebook，但你沒有時間去做？”
• “為什麼這些東西質量這麼差了？”
• “為什麼他上次一天就做出來，你要做這麼多天？”
• 由於規範或要求沒有明確寫入，因此開發人員被描述為需求變更。

Result

• 角色敵意：需求單元和開發單元不再提供可以為用戶帶來好處的產品，而是為了自己的目的而相互攻擊，以避免承擔額外的責任。因此，需求單位和開發單位根本不是一個團隊的情況。
• 責任：團隊認為“我沒有錯，所以延遲不是我的責任”，而不是優先考慮用戶需求。
• 需求凍結：由於截止日期的壓力，開發人員被迫改變他們的要求，否則他們將被推遲並且責任將由開發人員承擔。因此，要麼需要加班來製作隱藏大量錯誤的東西，要麼製作某種不符合用戶需求的功能; 兩者都會降低用戶滿意度。
• 低質量：PM的地位通常高於開發人員。因此，為了滿足合同的最後期限或避免處罰等，團隊將被要求“先完成，然後再尋求更好”，但最後通常是“先，沒有時間尋去求好” “技術債務的積累正在增加，結果是現實世界的責任鏈模型，它在最後的鏈條中負有最大的責任和成本。因此團隊就像堆棧流行，開發人員無法一個接一個地維持，這是項目公司工程師經常擁有高流動率的因素之一。
• 提高代碼的重量：為了優化效率，最熟悉的人的位置總是用於估計工作時間，因此最熟悉模塊和過程的人將始終關注相關要求。最後，只有那些人可以維護自己的代碼，就像潘多拉的盒子一樣，你永遠不會知道哪些牛和鬼會在打開後什麼會突然出現。因為黑匣子經常骯髒，但公司根本不知道如何解決這個問題。你也只有希望他不會離開，否則一些代碼將無法理解。

Solution

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

請記住，這個世界沒有靈丹妙藥，其他人的最佳實踐方法並不一定適用於您的團隊，因此首先要了解您的團隊目前遇到的問題，然後找出適合您解決你自己實踐問題的方法。 ，只要它不會引起新問題或新問題的成本風險是可以接受的。

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

1.比較不會因人而異：要求的複雜性通常不會因人而異，實踐所需的時間也許會因人而異。

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

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

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

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

When

在決定誰来做之前進行評估：這樣做的好處是最大限度地減少開發人員的個人因素。因為知道由誰做，所以不需要因為您自己的任務或最后期限而故意高估去添加緩衝區。

Who

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

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

What

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

Poker and Fibonacci Sequence

估計Scrum 中用戶故事大小的最常用方法是分配故事點。故事點只是從設定大小的數字池中抽取的數字，例如，故事可以具有1,2,3,5,8,13,20,40或100個故事點。

在菲舍爾系列有一個有趣的功能，並且每個數字是前兩個數字加。另一方面，數字與下一個數字之間的間隙越大，差異越大。

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

與Fibonacci序列相關的估計特徵

估計也有一個特徵，即越大越不精確，需求或任務被削減到更精細的粒度，通常估計更準確。就像在杯子中安裝一塊大的不規則石塊一樣，中間會有更多的間隙，這是不對齊或浪費的部分。如果你安裝一個更細和相同的不規則的石頭，間隙將相對較小，並且它易於調整，它可以更方便地填補空隙。

即使先前數字的差異相對較小，也無關緊要，因為數量很小，這意味著搬家靈活且風險低。如果由於某些因素導致時間估計不准確，則前面的小數字的任務是大約20分鐘的加班時間。而不是加班2或5天。

因為大的數字間隙很大（費米系列的兩個前後值的差值接近1.618），所以可以避免估計“這種複雜性是20還是21”。“要麼要想13，要麼20，要麼40。

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

撲克牌中的特殊號碼

另外，上面的圖片可以看到一些特殊的數字，分別是0，無窮大和問號。

• 0可能意味著根本不需要完成此要求，或者它已經完成。
• 無限意味著需求是明確的，但超過最大數量的需求，表明需求需要細分為多個較小規模的需求。
• 問號表明需求不明確，需要PO / PM來解釋或澄清。

How

1.首先定義復雜度單位1，例如單表綜合查詢的功能。由於我們的估算過程是基於相對規模，我們首先定義比較基準的單位，並在團隊估算後有比較的基礎。

2.主持人大聲說出要求（例如用戶故事卡），以確保每個人都了解要求，每個人都有自己的估計複雜性。使用計劃撲克的原因是因為您評估的數字可以同時顯示，而不是旋轉您評估的數字。很容易將數字輸出並導致其背後的人的結果受到之前數字的影響。

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

例如，估計13的人認為這種需求幾乎與過去的某個要求相同，而且這個要求並不像想像的那麼複雜。估計40的人可能會感到相對複雜，因為他對這個要求或過程不夠熟悉。

4.最低和最高數字完成評估的原因並進行進一步投票。如果仍然有不同的投票數，並且絕大多數人都達成了共識，並且沒有達成共識，估計的複雜性只是遠離共識複雜性的一個級別，您可以詢問估計不同數字的成員是否他們可以接受您評估的數字。

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

同樣，只有那些實際執行任務或完成要求的人才能參與投票過程，而PO / PM不能干涉。

Why

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

1. 合作的人決定合理客觀的估計結果，有參與感，沒有抱怨。
2. 決定的結果是PO和團隊之間的共識，這將減少未來針鋒相對的情況的發生。
3. 每個人都能理解這個要求。將來，每個人都可以充當滿足要求的人。當需要支持時，人們也可以互相幫助或互相支持。
4. 在您這樣做之前，您可以澄清不明確的要求部分和有疑問的部分。
5. 在您做之前，您可以找到最佳和最有效的團隊合作方式。
6. 除非整個團隊都是一個不可靠的人，否則這個數字反映了團隊共享估算的事實，而PO可以理解需求與評估之間的差距。
7. 通過比較需求之間複雜性的相對大小，未來的PO將能夠承諾在迭代中可以完成多少工作，並且將有一個比較的基礎。

結論

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

對於PO / PM：

• 不需要擔心某些成員過度估計任務作為緩衝區。
• 了解在評估過程中實施需求或任務的潛在困難。
• 了解需求的任何部分是否需要明確說明去除誤解部分。

對於團隊：

• 開發人員在開始處理任務之前進行知識交換。無論估計數量是增加還是減少，需求都更加明確，估計更客觀。
• 因為您仍然不知道誰負責這項任務，所以估算過程可以客觀地實現，並且在團隊一致的情況下，您知道誰在這個過程中熟悉這個任務。實際操作時，您可以基於這些資訊配對編程或知道向誰尋求幫助。

本文提出的解決方案是一種常見的解決方案。重點不在於形式，而是在敏捷估計過程中每個環節的設計目的，以解決什麼樣的問題。最後，敏捷估計只是：估計。不是滴血為誓。

Scrum技術中的文章

• 什麼是Scrum活動？
• 什麼是Scrum儀式？
• 什麼是產品Backlog修飾？
• 每日Scrum中的3個重要問題是什麼？
• Scrum Sprint循環8個步驟
• 什麼是Scrum中的Sprint？
• Scrum的心跳 - 每日站立
• 每日Scrum會議 - 快速指南
• 為什麼固定長度Sprint在Scrum中？
• 什麼是Scrum發布計劃？
• 什麼是Sprint計劃？
• 什麼是Sprint評論？
• 什麼是Scrum的Sprint回顧會議？
• 什麼是產品Backlog改進？
• 什麼是Scrum中的持續集成/交付/部署？
• 什麼是Scrum中的時間盒事件？
• 什麼是Scrum中的Spike？
• 什麼是敏捷計劃撲克？