敏捷故事點 vs 時間：如何更好地估算軟件開發
已發表: 2021-10-05圍繞軟件開發過程進行思考可能很難。 當您提出一個想法並與開發人員聯繫時，您首先要問的兩件事是實施成本和構建. 估算是應用程序開發的第一步。
在本文中，我們比較了現代軟件開發中兩種最流行的估算模型：敏捷故事點 vs 小時數。
繼續閱讀以了解如何在敏捷中估算時間，了解兩種估算模型的要點，了解它們的差異，並了解為什麼開發人員可能會選擇一種而不是另一種。
小時很容易理解，並且長期以來一直是軟件開發中的主要估算模型。 小時數，也稱為工時或工時，是開發人員在項目上花費的小時數。
那麼什麼是故事點？如果我們已經有了一個簡單直接的估計模型，它們為什麼會出現？
內容：
- 究竟什麼是故事點？
- 這是在敏捷中計算故事點的方法
- 估計故事點的優點
- 估計故事點的缺點
- 以小時為單位進行估算的優勢
- 按小時估算的缺點
- 你能把故事點轉換成小時嗎？
- 故事點與小時數：軟件開發選擇什麼？
究竟什麼是故事點？
故事點是敏捷和 Scrum 原生的相對估計模型。 他們通過解決開發的三個方面來估計構建產品的工作量：
產品所需的工作量
產品功能的複雜性
可能影響發展的風險和不確定性
在項目評估的最開始，開發人員選擇產品具有的最小和最簡單的用戶故事——例如，註冊用戶故事——並將其設置為 1 點用戶故事。 這就是基本故事：將用於復雜性比較的用戶故事。 所有其他用戶故事將根據與基本故事相比開發的複雜程度分配多個故事點。
表面上看起來很簡單，但誰來決定每個故事中的故事點數？
這是在敏捷中計算故事點的方法
與時間一樣，負責產品的人員通常會估計開發的故事點。 但是，估計過程與故事點略有不同。
要將故事點分配給用戶故事，涉及多個開發人員。 應該至少有兩個，但公司可以要求所有開發人員通過玩行業所謂的Planning Poker來做出貢獻。 以下是遊戲規則：
每個開發者都會得到一套 Planning Poker 卡。
開發人員選擇一個用戶故事並討論其複雜性和所需的開發工作。
每個開發人員都會根據他們分配給故事的點數提出一張卡片。
如果故事點估計值相同，則將估計的點數分配給故事。
如果建議的故事點不同，開發人員會討論用戶故事，直到他們提出大多數人批准的一些點。
開發人員選擇下一個用戶故事。
重複步驟 3 到 5。
當我們的活動全部遠程時，此流程已被修改。 故事點不是卡片和會議，而是通過在線討論、Zoom 會議或信使來決定的。
它看起來有點像這樣：
當然，這並不意味著所有參與估算故事點的開發人員都會參與該項目。 但是故事點系統的一個關鍵優勢是它創建了一個或多或少通用的框架，不僅可以用於相關項目，還可以用於具有類似功能的未來項目。
有兩個常用選項可用於估計故事點。 您可以分配點數：
使用任何整數（1、2、3…13、14、15 等）
使用斐波那契數列中的數字（1、2、3、5、8、13…55、89、144 等）
斐波那契數列是估計發展的更方便的選擇，因為它為近似值留下了一些餘量。 數字順序模型有點過於精確，無法方便比較。
在開發期間和項目之間，如果用戶故事最終比最初估計的更複雜或更不復雜，則可能會更改分配的故事點。
估計故事點的優點
如果分配故事點的過程看起來有點複雜，不要讓它讓您失望。 使用故事點進行容量規劃有其優勢。
1. 故事點獨立於開發者
每個故事的故事點數是由幾個開發人員在談判中分配的，原因是這個數字不僅分配給一個特定的產品和一個特定的開發人員，而且是“平均”分配的。 為什麼這是一件好事？
事情發生。 有時，您項目的開發人員可能會離開您的項目並被替換。 也許他們會生病，決定休育兒假或休假，或者乾脆離開公司。 也許他們會被證明是項目資格不足或資格過高。
當它們被替換時，新的開發人員可能會有不同的工作速度，這將導致重新估計創建產品所需的工時。
故事點將這個問題最小化。 由幾個不同的開發人員分配，他們提供了一個特定用戶故事的複雜程度的一般視圖。 故事點適用於特定公司的任何和所有開發人員。 （但請記住，故事點估計對於不同的公司是不正確的。）
2. 故事點讓重新計算開發時間變得更容易
在使用故事點的敏捷時間估計中，團隊使用術語速度來指代在單個 sprint 中發布的故事點數。
團隊不斷地監控他們的速度，而且一開始它的變化很大。 一個團隊可以在一周內發布價值 5 個故事點的功能，在下一周發布價值 20 個故事點的功能。 但這只是開始。 隨著項目的進展，速度圖將變得平坦。
以小時計，如果團隊成員發生變化，他們參與的每項任務都需要重新估算以調整截止日期。 有了故事點，這是不必要的——團隊可以通過了解整體速度的變化來調整下一個衝刺後的項目截止日期。
故事點作為一個整體評估團隊績效，無需按任務重新評估。
3.故事點有利於監控團隊績效
當您的團隊在不同時間從事類似的項目和/或任務時，速度可以輕鬆地向您顯示每個團隊取得的進展。 他們有沒有改進？提高了多少？ 哪個團隊或開發人員遇到困難並可能需要額外培訓？ 學習曲線如何？ 也許不同的團隊表現更好？
Velocity 是一個很好的工具，不僅可以在現場而且可以持續評估團隊的表現。
4. 有故事點的發佈時間估計更精確
通過跟踪速度，團隊可以高精度地知道他們在一個 sprint 中可以發布多少故事點。 雖然應用程序開發團隊需要一些時間來計算其速度，但一旦計算出來，預計發布日期就很容易預測。
此外，團隊成員、需求或功能數量/複雜性的變化不會導致重新估計的許多困難。
5. 您可以在未來的項目中重複使用故事點以加快估算
一家公司精通某個（或多個）特定領域並構建具有相似功能集的多個產品的情況並不少見。 在完成一個以故事點估算的項目後，開發人員可以參考這個估算來創建新項目。 這將縮短估計時間。
但是，保持跟踪每個項目的速度很重要，因為情況可能會發生變化。
6.故事點增強團隊合作
傳統上，開發公司有多個開發團隊，每個團隊都從事不同的項目。 在以小時為單位進行估算時，由從事該項目的開發人員進行估算。 總的來說，這是一件好事，因為誰比做這件事的人更清楚某件事需要多長時間？
然而，估計故事點的複雜性為同一領域的開發人員提供了合作的機會——否則這種情況很少發生。 這種團隊合作為分享經驗和相互激勵提供了很好的機會。
估計故事點的缺點
爭論總會有另一面，那就是偉大的系統是如何誕生的。 基於復雜性的估計也有其缺點，每個團隊都必須自己決定是否超過了優勢。
1. 故事點應該由一個以上的開發者分配
故事點模型的賣點是它的客觀性和對未來估計的價值。 但要做到這一點，估計必須由多個開發人員完成。 對於只有一個團隊的小公司或某個領域只有一名專家（即只有一名設計師或 iOS 開發人員）的公司，故事點不會帶來太多優勢。 此類小公司傳統上選擇工時作為估算模型。
2. 故事點的估計需要大量積壓
為了充分發揮故事點的潛力，您的團隊需要花費大量時間。 如果您正在處理的項目具有團隊以前從未開發過的功能（或沒有全職工作），那麼前兩到三個 sprint 將很難預測性能。 誠然，您的團隊擁有的積壓項目越多，由於統計數據的豐富性，他們的估計就越準確。 但是故事點不是一個可以立即運行的系統。
3. 故事點的預算更複雜
故事點非常適合設置精確的截止日期和發布日期，這對開發人員和客戶的營銷很重要。 但是，在估算應用程序開發成本時，它們就不那麼方便了。
問題是，開發人員在項目上花費的時間不僅僅是編寫代碼（或進行設計或測試）。 一些時間用於研究、討論——在團隊內部和與客戶——進行更改等。估計故事點的時間也是項目花費的時間，但它不包括在每個故事的點數中。
在估算故事點時進行預算是可能的，但通常將資金與在項目上花費的時間等同起來會更快、更容易。
4. 速度按每隊計算
這意味著如果團隊在項目之間混合，您需要分別計算每個開發人員組合的速度。 因此，對一個團隊的估計不一定適用於另一個團隊，甚至更改單個團隊成員也可能使先前的估計無效。
另一方面，您可以使用複雜性估計來找到性能最佳的組合。 不過，這需要時間。
以小時為單位進行估算的優勢
雖然一些敏捷團隊使用故事點，但許多團隊尚未從工作時間轉換。 這有很重要的原因。 讓我們也介紹一下它們。
1.小時是一個熟悉的模型
創新是偉大的，但需要時間。 開發人員及其客戶都精通工時估算。 對於許多人來說，這個想法是“如果它沒有壞，就不要修理它”。 只要係統提供可行的估計，為什麼要切換到其他東西？
估計精度的差異可能不足以讓一些開發人員改變他們做事的方式。
2. 客戶通常按小時付費
這一點無需贅述。 對於客戶來說，基於復雜性的估計可能會令人困惑。 此外，如果對客戶而言，預算比發布日期（通常是）更重要，那麼故事點與他們無關。
3. 基於小時的估算可由一名開發人員完成
對於小團隊或自由職業者來說，故事點在很大程度上是無用的，因為它們需要多個觀點。 在沒有任何參考的情況下，估計故事點是不必要的麻煩。
另一方面，小時數為從事項目的開發人員提供了一種自己進行相當精確估計的方法。
團隊速度也是如此。 當團隊每次都發生變化時，就像自由職業者或部分外包一樣，監控速度幾乎沒有意義。 此處基於小時的估算是更好的選擇。
按小時估算的缺點
以下是團隊可能決定停止使用小時數作為估算模型的原因。
1. 單獨負責估算壓力很大
一方面，估計自己的時間需求會更容易，因為您只能依靠自己。
另一方面，如果您未能實現您的估計，那將是一個巨大的打擊。 如果等待開始他們的任務的團隊依賴於你完成你的任務，則更是如此。
此外，由於兌現自己承諾的壓力而造成的壓力可能會破壞本應順利進行的任務。
2. 開發人員的估計總是不如團隊的準確
個人估計是主觀的，並與估計者的情緒和心理情況有關。
一些開發人員傾向於高估自己並設定他們後來難以堅持的時間框架。 這不僅會擾亂開發（如果有罰款，會給團隊帶來額外的成本），還會給開發人員帶來壓力和倦怠。
其他人低估了自己的技能，延長了超出客觀需要的發展時間。 不安全感和過度思考、檢查和重新檢查工作的習慣通常會導致開發截止日期被推遲——並且任務很少在截止日期之前完成。 團隊輸入允許更客觀的估計。
3. 任務越大，越難以小時為單位進行估算
這也與非發展情況相關。 很容易說讀一本三頁的大學小冊子需要多少時間，但很難估計完成戰爭與和平需要多長時間。
開發也是如此。 對於有一定經驗的開發人員來說，小任務很容易估計。 然而，任務越大，越多的事情——發生在項目內部和外部——會影響開發。 基於小時的估算無法提供故事點所具有的利潤率，從而使估算更加粗略。
4.靈活性小
基於小時的估算是基於開發人員的。 如果負責產品的一名團隊成員在項目中期發生變化，團隊將需要重新計算仍在開發中或計劃用於未來衝刺的每個受影響的用戶故事。 這可能需要大量工作，具體取決於項目所處的階段以及原始開發人員和新開發人員之間的技能差異。 基於小時的時間估計非常嚴格。
你能把故事點轉換成小時嗎？
客戶可以要求在故事點中進行估算的團隊將敏捷故事點映射轉換為小時。 大多數不熟悉最新軟件開發趨勢的人不知道故事點是什麼。
但是，當客戶詢問一個故事點等於多少小時時，無法明確回答。 基於復雜性的估計的關鍵組成部分之一是完成故事所花費的努力。 但是努力並不能直接轉化為花費的時間。 小時以比故事點更模糊的方式解決不確定性。
任務越複雜，存在的不確定性和風險就越大。 以一種直接的方式將故事點轉換為小時，並且僅依賴於速度並不能解釋許多此類風險，因為在涉及風險和不確定性時，基於小時的估計比故事點更近似。
在某種程度上，在分配故事點時使用斐波那契數列會考慮到開發時間的不確定性，但它並不完全允許直接轉換。
這是一個例子。
一個 1 個故事點的故事（基礎故事）需要兩個小時才能完成。
在最好的情況下，一個 13 個故事點的故事可能需要 26 小時——如果沒有任何問題或阻礙。 例如，如果使用的 API 無縫匹配，端點到端點。 但如果沒有，故事可能需要 30 到 50 個小時之間的任何時間——這取決於有多少不匹配。 如果開發人員還沒有使用相關的 API，那麼沒有人能事先說清楚它會怎樣。
因此，在將故事點數轉換為小時數時，需要有一個指數增長的乘數來解決不確定性。 而且這個乘數會因一支球隊而異。
故事點與小時數：軟件開發選擇什麼？
如您所見，故事點和時間都是開發人員估算項目的有效選擇。
總而言之，我們會說更多的產品公司選擇故事點，而外包商往往傾向於小時。
使用固定價格模型的公司通常採用基於小時的估算。 喜歡 Scrum 的團隊通常會選擇故事點，因為它們確實是從 Scrum 中誕生的，並且是這種方法論的本土化。
在我們多年的經驗中，我們是這樣看待它的：
如果準確估計發布日期比匹配預算更重要，那就去尋找故事點。
如果預算比準確的發布日期更重要，請考慮小時。
或者，最重要的是，將兩者結合起來。
故事點對於從事長期項目的開發團隊來說非常方便，在這些項目中，監控速度會產生影響。
對於擔心壓縮預算的客戶來說，工作時間很重要。 此外，工時對於短期項目更有意義。
基於復雜性的系統還很年輕，就像 Scrum 本身一樣，它仍在發展中。 結合這兩種估計模型並製定一個系統以將每個故事點快速更改為小時，可以在最大限度地減少缺點的同時提供兩種模型的好處。