敏捷項目管理中的軟件成本估算

介紹

軟件開發中最難做的事情之一是確定交付新軟件產品需要多長時間和多少。 應該這麼難嗎？ 答案並不簡單。

軟件成本估算本質上是困難的，人類在預測絕對結果方面非常糟糕。 沒有兩個項目是相同的； 每一個在它所要實現的目標上都是獨一無二的，在形成其存在的無數參數中也是獨一無二的。 通常，表面上看起來很簡單的問題在現實中實施起來要困難得多或在技術上具有挑戰性。 而且，毫無疑問，該項目將存在“未知數”，只有在它們出現時才能確定。

此外，沒有兩個人是相同的，無論您是客戶、開發人員還是用戶。 我們預裝了自己的一套知識、經驗、價值觀、期望、對風險的態度和適應能力。

編寫高質量的軟件是高級工程師的生計； 對於所有相關人員來說，創建出色的軟件產品可能是一項艱鉅的工作。

但是在軟件方面，了解持續時間和成本是製定戰略業務決策的關鍵，無論您是創建一家初創公司、實現新的商業機會，還是讓您的業務表現更好，這都是事實。 時機、投資回報和交付的收益可能會成就、動搖或破壞您的業務。 你會問自己：我們的錢能得到什麼？ 我們可以預測我們的成本嗎？ 創造我們想要的產品需要多少成本？ 我們什麼時候可以啟動？ 我們的投資能否獲得優質產品？ 它會隨著我們的業務增長嗎？ 它會帶來商業價值嗎？

那麼，您如何估算項目的規模、持續時間和成本呢？ 讓我們探討一下敏捷項目估算和軟件開發成本，以及我們在 Toptal 是如何做到的。

傳統合同定價和估算

傳統上，使用非敏捷實踐，軟件項目試圖修復功能或範圍，並讓時間和成本成為變量。 這會導致問題：

1. 你怎麼知道你在項目開始時修復的功能真的是最適合你的業務或客戶的功能？ 通常情況下，功能或範圍會發生變化，這就是為什麼我們會聽到“範圍蔓延”，即通過項目生命週期確定所需需求的結果並確定為必要或強制

2. 當成本成為一個變量時，我們就會失去對我們正在尋求實現的投資回報 (ROI) 的控制。 成本增加通常是未知風險或需求變化的產物，這意味著我們必須增加團隊成員才能在同一時間框架內完成更多工作或讓團隊成員保持更長時間。 兩者都不可取

3. 當時間是一個變量時，我們就會失去對市場頭寸的控制。 也許我們錯過了一個重要的行業日期，或者我們的競爭對手在我們之前推出了他們的產品，從而失去了我們項目可能擁有的任何競爭優勢。

還有許多其他時間和成本可變的結果，這些結果通常是負面的和不可取的。

當然，許多客戶和組織都試圖修復這個“魔力三角”的所有三個組成部分。 不幸的是，它幾乎不可能真正實現。 有太多因素共同破壞了這一理想，最終導致產品無法滿足需求，需要太長時間才能使客戶受益或成本太高才能實現商業價值。

軟件項目的敏捷合同

成本是時間和人員（團隊成員）的產物。 增加更多的時間，就會增加僱用人員更長時間的成本。 添加更多團隊成員，您會增加交付相同業務價值的成本。 我們真正想要避免的事情。 這就是為什麼敏捷原則相信固定時間和團隊成員並允許範圍成為可變組件的原因。

哪個聽起來更好，並增加了利益相關者的信心，固定成本還是可變成本？

當然，產品兌現其承諾和客戶需求是很重要的。 如果最終您擁有一個沒人想要或無法有效使用的產品，那麼花費確切數量的時間和確切數量的金錢是沒有好處的。

所以敏捷合約關注以下內容：

• 固定價格工作包- 整個項目被分解為有助於完整產品成果的合乎邏輯的“迷你”版本。 每個版本都是一個相應定價的工作包。 隨著工作包的完成，未來的工作包將根據我們從前一個工作包中學到的知識重新估算。 這避免了不必要的意外事件，並允許客戶定義一定程度的重新優先級和新/修訂的功能。

• 提前終止——如果已經交付了足夠多的產品，客戶可以尋求提前終止項目，並且通過保留一個只會繼續提供邊際收益的項目團隊來實現進一步的投資回報率。 該條款通常在任何時候都可以使用，只要項目團隊和客戶保持牢固、信任和密切的工作協作關係，該條款就有效。 對客戶的好處是項目將提前完成，並交付了使產品可行所需的所有有價值的功能。 作為回報，供應商將獲得剩餘合同價值的 20%，並抵消留住員工的風險。

• 靈活的變化——變化是貫穿敏捷軟件交付脈絡的一個主題。 我們不希望從一開始就知道使產品成功所需的一切。 因此，我們根據相關數據和反饋推動變革，以確保交付正確的產品。 在迭代結束時，可以將更改替換為不再被認為必要或優先的舊功能。 只要變化的價值相等，就沒有進一步的成本。 如果更改的價值較低，則可以從剩餘的積壓中識別或提取額外的工作。 只要項目團隊和客戶在整個項目過程中保持強大、信任和密切的工作協作關係，本條款就有效。

• 額外工作——在項目的整個生命週期中，可能會發現更多在現有固定價格合同下無法實現的功能。 對於這種情況，可以將額外的新定價工作包添加到項目的末尾或恢復到時間和材料。

• 範圍估算——在敏捷項目合同中有兩種估算範圍的方法：持續時間範圍或功能範圍。 一個持續時間範圍允許估計說項目或工作包對於給定的範圍將需要 12 到 16 週。 但是，增加持續時間會增加成本，因為您可以讓項目團隊成員保留更長時間，或者這意味著他們不能被釋放以從事其他開發項目。 在 Toptal，我們更喜歡在一系列故事點中劃分功能，將範圍保持為變量，但承諾在工作包或整個項目的固定時間範圍內為客戶提供最低水平的價值。

值得記住的是，您以後總是可以添加更多範圍。 也許您已經開始賺取收入，您增加了用戶或降低了成本。 無論哪種方式，如果您已經證明了回報或改進並且正在提供商業價值，那麼要求更多的金錢和時間會容易得多。

我們的軟件成本和定價方法

在 Toptal，我們與客戶和工程師密切合作，採用能夠提高利益相關者對項目持續時間和成本的信心的技術。 我們致力於在適當和必要的情況下，從最初的高層次不斷細化和調整計劃，從而避免浪費並實現可管理的變更。

在製定估算和固定價格項目時採取以下步驟：

1. 初始高層範圍

在項目開始時，我們對其最終結果知之甚少。 想像從一開始就可以準確地知道我們的客戶和用戶需要哪些功能是愚蠢的。

因此，我們從一個項目章程和一套高水平的“史詩”特性開始，這些特性基於一個合理的願景和目標來指導項目的方向

一種。 願景和目標設定我們需要構建什麼？ 您需要實現什麼以及您的業務目標是什麼？ 了解這些問題使我們能夠設定項目的規模。 您是否需要原型來測試最初的想法、概念或技術？ 您是否已經確定了一個經過市場測試的明確主張，並且準備好構建您的第一個最小可行產品 (MVP)？ 或者，您是否正在擴展您現有的業務或產品以將其提升到一個新的水平？

灣。 高級“史詩”功能無需過多詳細說明，您需要定義產品必須滿足客戶需求的功能。 這是一個結構化的“購物清單”，描述了您產品的基本要素； 通常這些被稱為“用戶故事”或史詩

C。 MoSCoW 分析MoSCoW 分析是一種技術，簡而言之，它有助於確定使產品可行的真正必要條件以及擁有什麼是好的。 那些被確定為“必須”的內容滿足了鼓勵用戶參與和採用您的產品的內容。 那些被確定為“應該”的功能會讓您的客戶感到驚訝和高興，但可以在以後構建。 “可能”項目通常不會增加顯著的商業價值，可能不會增加回報，並且是您的最低優先級。 “不會”的特性有朝一日可能很重要，但超出了本次項目迭代的範圍。 但是，現在確定這些有助於牢記未來產品的潛在規模和規模。

2. 提案

要決定是否繼續進行項目，有必要根據充分知情的數據做出決定：成本和持續時間。 這些是您需要問自己的最低要求：創建我們想要的產品需要什麼？ 我們什麼時候可以啟動？ 這是否符合我們的業務戰略和財務狀況？

有了上面的細節，我們可以提供一個建議。 我們的工程師根據具體的項目要求精心挑選，並與項目經理一起制定至少一種技術解決方案、提供已知範圍的估計持續時間和完成項目的估計成本。

正如我們之前提到的，在項目開始時，我們對交付的內容知之甚少。 我們故意使功能和範圍模糊不清，因為否則表明我們確切地知道需要什麼。 此階段的估計將是最不准確的，但可以指導是否值得繼續該項目。

該提案是詳細說明項目持續時間和成本的第一個工具。 一旦提案被接受，我們就可以繼續提供固定價格的報價。

3. 發布計劃

下一個級別的估算細化是創建一個發布計劃，該計劃將在給定的時間範圍內提供一系列功能。 我們從功能列表、項目規模、我們的團隊開發滿足客戶期望的高質量軟件的速度以及管理不確定性風險的技術中得出這一點。

一種。 產品待辦事項產品待辦事項只是“史詩”或“用戶故事”的有序列表，代表產品所需的功能。 這個列表開始於之前討論的史詩，但是在分配的項目團隊、項目經理和客戶之間，我們現在將它們分解成更有意義的項目。 每個項目都代表客戶的商業價值的一部分。 在這個階段我們不做更多的細節，我們不需要知道驗收標準，我們不需要知道按鈕是藍色還是綠色，我們只需要知道有一個按鈕可以完成一些任務要執行。

灣。 估計現在我們已經將特徵列表描述為用戶故事，該團隊使用一種稱為“規劃撲克”的技術來估計這些離散的特徵項。 這是一種有用的技術，可確保基於專家意見和類似尺寸的快速、可靠的結果。 Planning Poker 為每個項目分配一個約定的數字，代表其大小和復雜性。 這稱為故事點。 其他敏捷估計技術和規模，例如“理想天數”，也是可用的。

這個過程的結束將決定項目的大小和特性之間的依賴關係。 大小是通過將產品積壓中的項目中的所有故事點相加來確定的。 如果這個數字等於 120，那麼我們項目的規模就是 120 個故事點。

C。 優先級既然我們有項目的積壓和規模，我們就可以與客戶一起確定優先級。 這實際上是關於確定什麼對客戶最有價值，以實現預期的結果。 列表頂部的項目被認為是最重要的，第二個項目不如第一個項目重要，依此類推。 沒有兩個項目可以像另一個一樣重要，每個項目的優先級對於其他每個項目都具有相對重要性或價值。

這種確定優先級的方法是規劃軟件項目的一個重要里程碑。 我們現在知道什麼對客戶很重要，以及以何種順序完成工作、處理依賴關係、交付滿足期望的產品。

d。 發布計劃迄今為止，我們已經確定了我們認為的產品是什麼以及它有多大。

現在，我們確定交付可發布產品需要多長時間。 客戶和團隊，包括設計師、工程師、測試人員、scrum master 和項目經理，共同確定可以實現的目標以及創建發布計劃的速度。

發布計劃還可以深入了解項目將如何與客戶的戰略計劃保持一致。

最後，該計劃確保項目團隊擁有指引方向的指路明燈，並定義了開發的邏輯終點。

在開始之前，我們確保我們理解“完成”的商定定義。 這是一組給定的標準，客戶將接受它作為完整的標準，並且還滿足所有被視為可發布的工程要求。

以一個基本的場景為例，我們將我們從積壓工作中獲得的故事點總數除以我們團隊的預期速度。 （NB 速度通常表示為一個範圍，但為簡單起見，我們將在此處使用單個數字。）我們在兩週的迭代中工作，因此我們的速度將反映在我們可以在兩週週期內完成多少可用可用的團隊的能力。 如果我們的故事點總數為 120，並且我們預計每次迭代完成 20 個點，那麼總開發持續時間將是 12 週或 6 次迭代。 我們添加了一個為期 2 週的 sprint 0 和一個為期兩週的發布準備 sprint。 總的來說，我們的項目長度為 16 週。 我們可以使用一些技術來幫助在我們的計劃中建立適當的風險緩衝，我們將在稍後討論。 但簡而言之，我們使用緩衝來管理不確定性的風險，並就要交付的預期故事點達成最低限度的協議。 結果可能是交付了 90 到 150 個故事點，其中 90 個是創建可行產品可接受的最小值。

或者，如果項目必須在給定日期前完成，比如 10 週，團隊將確定在該時間內可以完成多少積壓工作。 如果我們預計每個 sprint 有 20 個故事點，加上 Sprint 0 和發布 sprint，我們的目標是在項目結束時完成 60 個點。 同樣，我們希望通過添加適當的緩衝區來管理風險，這可能會導致完成並準備發布 45 到 75 個故事點的目標。 45 個故事點將與交付可行且有價值的產品可接受的最低要求一致。 在這種情況下，您可能希望在適當的情況下添加團隊成員以提高速度。

當然，以上所有這些都得到了各方之間良好溝通和協作的支持，以得出一個可實現的、現實的和客戶可接受的發布計劃。

4. 固定價格合約

一旦就發布計劃達成一致，我們就可以為固定價格項目合同創建報價。 如前所述，建議保持項目持續時間和團隊固定以及範圍可變。

固定價格合同的報價與工作說明和商定的付款時間表一起交付。

只要有信任、溝通、協作並願意進入敏捷軟件項目的精神，上述所有步驟都使我們能夠以現實程度的信心交付報價，即項目將按時交付並在預算上。 當然，有時項目會提前或延遲交付，我們會以最大的透明度處理這些變化。

估計技術

敏捷規劃和估算得到了許多技術的支持，開發團隊可以使用這些技術來獲得對其規模、工作量、持續時間和成本的信心。 以下是我們的團隊用來估算軟件項目規模和成本的一些指標。

估計大小

項目的規模實際上是對其範圍、複雜性、維度、風險和規模的評估。 打個比方，這是關於理解我們是在建造埃菲爾鐵塔還是中國的長城。 埃菲爾鐵塔是一座高大、沉重、複雜的建築，建在緊湊的城市環境中。 中國的長城是一個相對簡單但又長又堅固的結構，跨越數英里的起伏地形。

雖然它們都是要交付的大項目，但它們的範圍、複雜性、規模、規模和規模都不同。

用估計來管理期望很重要。 它們絕不是預測、承諾或保證。 在討論總規模、總持續時間和總成本時，我們總是在範圍內工作，以降低風險、不確定性和未知數。

代表您的產品功能的故事是使用故事點或理想天數單獨調整和估計的。 這些單元的總數定義了項目的總規模。

故事點

故事點是表示用戶故事整體大小的度量單位。 一個故事的大小，在估計時，包括設計、工程、測試、代碼審查、集成等的所有方面。

每個故事的大小都與另一個故事相關。 例如，故事 A 的大小可能為一個點，故事 B 的大小為兩個點，故事 C 的大小為三個點。 在這裡，故事 C 的大小至少是故事 A 的三倍，至少是故事 B 的一半。

如果我們產品 backlog 中的以下故事具有相關的大小：

該項目的總規模為 12 個故事點。

理想的日子

這是以天為單位的大小度量。 它消除了諸如中斷、敏捷計劃活動、閱讀電子郵件和其他非項目活動等開銷的概念。 它只關注如果你要不間斷地連續工作需要多長時間，而不是從開始到結束所經過的時間。

通常，在我們對項目了解最少的情況下進行高水平估計時，我們會在理想情況下進行估計，因為與故事點等抽像數字相比，這是一個更容易與過去歷史和經驗相關聯的概念。 尤其是當高層次的故事本質上是史詩般的故事時，細節很少，並且在以後分解時可能包含其他元素。

當在更細粒度的級別進行估算時，比如在已建立的產品待辦列表中的一個故事，可以使用任何一種方法，並由工程團隊決定。 這兩種方法都有好處，每個團隊都有自己的偏好。

估算技術

共享估算估算不是孤立進行的。 它們由整個工程團隊協同執行，包括設計、數據庫、服務器、前端 UI、QA 和其他跨職能專家。 這避免了沒有考慮完成功能所涉及工作的所有方面的問題，並確保沒有人有高估或低估功能大小的負擔或不幸。 合併後的團隊都會有一個可以討論和達成一致的觀點。

類比估計這是我們考慮兩個離散特徵並決定一個相對小於或大於另一個的地方。 我們可以查看給定的故事並同意它的大小很小，如果使用故事點，我們可能會給它的大小為 2。 與第一個故事相比，下一個故事可能會被認為是大的，我們會給它一個大小為 5。 這表明大特徵的大小至少是小特徵的兩倍。

我們將用所有的故事繼續這個練習。 完成後，我們可以並排放置所有小型、中型、大型和超大型樓層，並交叉檢查我們的尺寸，以確保我們的估算具有一定程度的一致性。

規劃撲克關於規劃撲克的文章很多。 我在之前的博客中也提到過。 了解它的最佳資源之一就在這裡。

本質上，它將專家意見、類比和團隊協作結合到一個簡單、快速和可靠的過程中。

它匯集了多位專家，他們最適合根據技術和領域經驗、生動的對話和合理的理由進行評估。

速度

速度是衡量團隊在給定迭代（或衝刺）中完成工作的能力。

它表示為一個範圍，例如，每個 sprint 23 到 32 個故事點，尤其是在項目生命的早期。 一般來說，這是因為除非同一個團隊以前曾處理過同一個問題，否則很難準確描述團隊的速度。 請注意，我們指的是團隊的速度，而不是個人的速度！

我們使用速度來計劃我們的發布，並隨著項目的進展調整我們的計劃和工作包，從而使我們能夠通過執行定期準確地調整我們的完成預測。

當我們開始時，我們被迫用很少的數據定義一個速度範圍。 如果團隊和問題空間相同，我們可以使用歷史值，這通常是最不可能的。 我們可以運行一次迭代，從實際從事項目的團隊那裡了解速度，但這很昂貴，而且如果仍然要就同意啟動一個項目做出決定，那麼這是行不通的。 或者，我們可以做出預測。

預測速度涉及獲取一個 sprint 的故事，並將它們拆分為完成故事所執行的任務。 我們將估計每項任務將花費的小時數，包括設計、開發、測試等，並評估團隊在給定衝刺中的能力。 對於一個不受阻礙的團隊來說，70% 的容量是一個很好的基線。 因此，在一個簡單的情況下，如果團隊可用的總小時數是：

• 4 名團隊成員 * 兩週 * 每週 40 小時 = 320 小時
• 乘以我們 70% 的容量 = 224 小時
• 將所有特徵任務加起來，在 224 處停止計數
• 獲取所有已完成的功能，將它們的故事點相加，您就可以得到速度，比如 36
• 在任一側應用 20% 以獲得最低和最高範圍，以達到 29 到 43 個故事點的估計速度。

速度通常在前兩到四次迭代中變化，然後在小範圍的點內穩定。 因此，我們在 sprint 1 之前的初始範圍是 29 到 43，到 sprint 4，它可能會從 34 到 38 穩定下來。這讓我們對預測最終完成日期更有信心。

風險和不確定性的緩衝計劃

所有軟件項目都帶有一定程度的不確定性。 隨著我們在項目中的進展，這種不確定性變得越來越少，並且對我們的技術、環境、性能以及客戶和用戶的需求的了解越來越多。

我們在進度表中設置緩衝來減輕這種不確定性或風險，這說明了我們估計的誤差範圍以及我們在開發開始之前無法確定的未知數。

通常，有兩種緩衝區類型：Feature 和 Schedule。 由於我們經常為固定交貨日期定義固定價格，因此最好使用功能緩衝區。

這種方法為我們提供了可靠的風險緩解策略，並讓客戶對項目完成後他們應該期望看到的結果充滿信心。

特徵緩衝區

使用特徵緩衝區，我們預測我們將提供一組給定的特徵，但理想情況下會完成另一組特徵。 這應至少反映客戶認為推出可行產品所需的最低功能集，但如果所有各種內部和外部影響都允許，則可以在時間框架內交付更多功能集。

因此，客戶可能會認為產品待辦列表中優先級最高的功能（總計 100 個故事點）是最重要的。 然後，他們可能會考慮額外增加 30 個故事點的功能。 因此，團隊將根據交付 130 個故事點進行計劃，在給定的固定價格合同的預定完成日期結束前，至少完成 100 個故事點。

一些結束的想法

敏捷可能是一個很難完全掌握和採用的概念。 在管理價格、範圍和持續時間等敏感主題時，情況同樣如此。 不幸的是，我直接知道要求苛刻的客戶希望所有事情都預先解決，並且當一切開始瓦解時急於責備供應商。 同樣，我知道一些供應商深陷其中，反應遲鈍，無法響應客戶需求。 走敏捷之路從根本上建立在信任、良好的關係和一流的溝通之上。 這些必須是雙方都持有的價值觀，以便維護一個健康的項目，讓所有相關人員獲得平等的利益、滿意和成功。 對合作和談判保持開放的心態和建設性的態度是避免關係惡化的最佳方式。

我曾與那些發現很難接受敏捷的適應性並放棄命令和控制態度的客戶一起工作。 很難放手將所有的信念和信任放在一個你不認識的團隊中。 通常，客戶可能希望預先創建所有需求，作為交付內容的規範。 這讓他們有一種信心，認為項目的範圍是明確定義的。 但最終，這未能成為一種成功的方法。 如果我們局限於合同中的範圍和不切實際的要求，問題就會很快出現。

我們知道，當在傳統方法中採用這種方法時，範圍會發生變化，未知數會被發現，或者我們認為客戶想要的不再是真實的或偏離標準的。 對定價、計劃和範圍採取適應性方法使客戶能夠真正確定他們的產品正是他們的市場需求。 它也使供應商能夠響應迅速、富有想像力和高效。 在合同談判中利用客戶和供應商之間的協作是關鍵。

供應商需要誠實，客戶需要從一開始就對可以實現的目標持現實態度。 承諾不切實際的目標然後增加成本的供應商可能會贏得最初的合同，但很快就會失去心懷不滿的客戶的青睞。 很多時候，由於各方之間缺乏信任或信心，關係破裂。 信任必須從一開始就建立並在整個項目過程中保持。 供應商必須靈活並配合不斷變化的需求。 客戶總是想要更多； 這是做生意的自然結果。 雙方之間必須進行平等和有益的價值交換。 對於客戶來說，他們希望為他們的業務創造價值。 對於供應商而言，他們應該尋求通過與客戶建立長期關係來創造價值。 遵守敏捷宣言的價值觀和指導原則是建立牢固、平衡和長期關係的良好基礎。

概括

我希望這能讓您對敏捷軟件項目的規劃、估計和定義價格有所了解。 上述所有方法和技術旨在建立對團隊的信任，並建立客戶對構建軟件產品需要多長時間和多少成本的信心。 最終，要建立對繼續進行的決定的信心。

遵循這些指導方針，您一定會找到一條令人滿意的途徑，讓您的軟件產品栩栩如生。