敏捷開發如何估算工作量？

01-25

在軟體開發過程中，開發人員最頭疼的就是需求變更了，但這種頭疼的事情根本就無法避免。對此，敏捷開發方法大膽提出了需求驅動、擁抱變更的口號，主張通過短周期的快速迭代來摸清用戶需求，開發出用戶滿意的軟體系統，並取得很大的成功。
但很多軟體項目的在簽訂合同前，要根據工作量來制定合同中的期限，而且工作量還是合同金額的重要參考。採用敏捷開發的軟體合同該如何在合同簽訂前評估工作量呢？

說幾個要點吧

1.範圍蔓延和需求變更是兩回事，合同實際範圍還是要明確，至少要到實際的業務功能點。在一個功能點上可能也會出現變更或新增需求，在這裡屬於合同範圍要考慮的。比如一個功能點內容需要增加一個列印功能，或者一個導出功能，可能開始合同範圍做不到這麼細，但是我們需要考慮。也就是你在進行功能點工作量估算的時候要考慮到，特別是根據以往項目經驗。

2.儘早的出迭代版本，迭代版本可以交付給用戶測試，可以提前驗證需求和發現需求變更情況，及早的對需求變更進行處理。

3.在估算工作量的時候需要留實際的預留，如果用三點預測法，報給客戶的要全部用悲觀值工作量再乘以20-30%的工作量緩衝。

4.對於合同範圍盡量細化，比如剛才說的業務需求或用戶需求，盡量在合同簽訂前就進一步細化，包括到具體的實現功能點。對於根據以往歷史項目經驗有可能需要的功能，全部按需要的方式來進行功能點和工作量估算。

敏捷開發適用於做自己產品的團隊或公司，對於服務甲方的外包，採用敏捷對雙方都不負責任，最終很容易變成災難性的結局。

外包型項目在簽訂合同前評估工作量問題，前幾貼都各自提出了解決方案，具體採納需要你見仁見智了，但在項目UI設計完成後，投入編程前，建議項目的實現方案，需求等相關文檔都與開發團隊全部過一遍，提高大家對項目的了解，最後輸出整理成項目文檔提交給客戶進行最後的需求確認，事畢即可啟動開發。

前期籌備得越充分，開發的進展越順利，需求的變動也就越少，最終給甲方輸出的產品質量就越高。

與此同時，我從來都不認為頻繁的滿足甲方的需求變更是服務質量高或服務態度好的行為，相反，恰恰是不專業的一種表現。

我是這樣看的：你問的問題其實更多的是商務技巧，在這個階段我認為敏捷開發幫不了你什麼。能更多幫到你的反而是酒桌上的技巧，和商務談判的技巧。

如果你想要藉助敏捷的方法或者思想，那麼你就最好不要把精力放到如何制定一份不吃虧的合同上。敏捷宣言說的很明白：

工作的軟體勝過面面俱到的文檔。意思就是，合同算個屁，全力幫助用戶開發一個好的軟體才是王道。
客戶合作勝過合同談判。意思就是，只要你真心為用戶著想，開發卓越的軟體，合同算個屁
響應變化勝過遵循計劃。意思就是，項目初始階段規定的範圍，到項目後期一定會變得面目全非，那麼應該把心思花在響應變化，讓客戶滿意上

軟體開發中存在太多的灰色地帶，合同根本就不能起到保障作用，所以最好的方法是，讓客戶信任你，讓他覺得你是在為他著想，讓他覺得你有能力而且有強烈的意願能把軟體做好。

*************************************************

裝b完畢，回到現實世界。如何估算工作量。

1、要想估算工作量，需要有人（需求分析師也好架構師也好）對這個領域十分了解。如果沒有的話，那估算的結果和扔骰子沒什麼區別。

2、識別出關鍵的功能性需求、非功能性需求，識別出主要的工作量、風險

3、將關鍵需求分解為更小的步驟，排好依賴關係

4、根據團隊的歷史數據，對每一個小步驟進行評估，評估兩個數據：最壞時間和最好時間

5、乘以一個信心係數，一般來說是30%

當然，還有一種評估方法：基於信念的評估。你堅信你的團隊能在xx個月完成這個軟體，就夠了。

沒有人會定錢不定工的買賣。

兩個方法：

1.讓對方定一套方案，算定時間和價錢，先按照這個方案和價錢做完。剩下的改動按時間收費，外包人力給它們做修改。

2.從一開始就不定具體方案，外包項目經理，產品，開發，美工等等職位給他們，他們來養著，按時間跟你們結賬，然後你們給員工發工資。

正好剛總結了一下我們團隊是如何估算工作量的，看看這個是否對提問者有幫助。

為什麼要估算工作量？

1.為即將到來的迭代計劃會議（Iteration Planning Meeting）做準備

經過多次迭代後，一個團隊會有一個相對穩定的工作容量，我們用Velocity來衡量，通俗來講就是在這一個迭代中，一個團隊完成了多少個「點」的工作。在迭代計劃會議中，由於故事卡片經過估算，那麼整個迭代的工作量就會很容易調整安排。

2. 確保團隊成員對故事卡片的理解達成一致

在敏捷團隊中，我們提倡所有人都可以做任何工作，不存在某項任務只能由一個人來完成。那麼在估算中，可能會出現如下情況：

a）資深人員認為不費吹灰之力，而初級人員認為難如登天

b）儘管BA做過闡述，但還是有人有悲觀主義，認為該任務需要由一系列的前置條件；也可能有人過於樂觀，不就是改兩行代碼的事兒嘛。

所以，一個一致性的估算，能有效保證團隊對故事卡片的理解不偏離。

如何實施估算？

1.估算單位：點（Point）

我們用斐波那契數列來估算每張卡片的「點」，即1，2，3，5，8……1個點並不是代表天數，而是說這項工作的effort並不是很大，我們團隊傾向於兩天內就能完成的簡單工作用1來估算。

2.參與人員：全團隊

如我所提到，敏捷里提倡任何人可以做任何工作，既能減少團隊對個人的依賴，又能迅速地培養「全棧工程師」，所以我們團隊是全員參加。如果有的團隊過於龐大，可能只適合找一部分人員（不知道是否有這樣「龐大」的「敏捷」團隊）。

3.估算流程：發散，收斂

發散：在成員明白故事卡片的工作內容和驗收條件後，每個人給出估算。由於我們的團隊在不同的地方，所以我們每個人都在Skype里輸入自己的觀點。

收斂：我不會算平均數，也不會武斷地取眾數。對於每一個估點過高或者過低的成員，我都會讓他闡述自己的觀點。有時候可能是成員自己有理解偏差，有時候可能是其他成員有所疏漏，所以表達，讓團隊將估算收斂。

經常會遇到的問題

問：最大點和最小點各是多少？

答：取決於團隊。我之前的團隊最大的點數是8，超過8，會將故事卡片進行進一步的拆分；最小的點是3，小於3的卡片會添加其他的內容。現在我們的團隊最小的卡片是1，最大的是5，更細小的粒度更適合他們。

問：每一張卡都要估嗎？

答：不是。對於技術實現上的探索卡片（Spike），我們一般用時間盒（Time Box）的方式，如2天。對於一些決策卡、依賴卡等需要溝通協調來解決的，我們也不會預估。因為上述卡片不直接產生產品交付價值，我們把點數寫為零。

問：估算要精準無誤嗎？實際開發中發現了估算失誤要不要修改點數？

答：不必。估算是為了輔助我們的工作安排，而不是用來管理員工的績效表現。為了達到精準的估算而耗費了過多的時間盒精力，這是本末倒置。有的故事卡片會比預計的先完成，有的會耗時更長一些，這些經驗的積累都會為團隊的下一次估算奠定更好的基礎。

所以，單純地修改點數是沒有意義的。畢竟快速迭代就是方便我們試錯、改善。但如果做著做著發現故事卡中有深坑，建議再開一張卡片來填坑，這是比較常見的做法。

理解題主的意思是如何解決合同金額固定與實際開發過程中可能出現的需求變更，導致項目成本不可控的矛盾。

在實際操作中，更多是需要項目實施與商務的配合來解決。

1，合同金額的大小與客戶的商務流程、預算等因素有有關係，而非僅僅依靠開發商對項目工作量的預估。

2，合同金額確定在前，實施控制在後。

3，合同的需求範圍往往很難非常細緻，需求範圍的確定更多是在實施的需求評審階段。

4，根據合同總額，預留一定的工作量作為需求變，更有利於項目的開展。

5，一定要讓客戶明白，項目的成本是甲乙雙方共同面對的問題，只能利用有限的資源開發出最有價值的功能，實現雙方的雙贏。

1、識別項目干係人、識別客戶、和干係人協作定需求，創建用戶故事

2、分解需求

3、當細化需求時，就可以估算用戶故事，估算工作量

Scrum主管幫助協調估算工作，並且產品負責人提供特性的相關信息，而開發團隊可以通過估算撲克方法估算用戶故事所需要的工作量級別

了解估算撲克玩法及更多敏捷開發估算方法：敏捷落地分享會

工作量主要取決於建設範圍，而不是開發模型，目前的開發模型，無論是瀑布、迭代、敏捷對工作量來說都沒有質的影響。

所以找一個最熟悉的評估方法即可。簽訂合同時，推薦快速功能點法

前提是你有個成熟的團隊，按他們shirt size 之後得到的結果+50%就差不多了