你的估算作得對嗎？ | IDCF

做爲架構設計人員或技術開發人員，相信你必定被問到過下面的問題：

• 有個新需求，請幫忙粗略估算下完成這個需求大概須要多少工做量。
• 如今有100W預算，請幫忙估算下夠不夠完成這個需求的開發。
• Story卡已經寫完了，請幫忙作下詳細的估算，看看咱們須要多少開發資源。
• 線上這個問題緣由已經找到了，請幫忙估算下最快多久能修復。

在軟件開發的不一樣階段，咱們都會因不一樣的目的須要作估算，好比須要分配資源時、須要排開發計劃時、須要評估成本時等等；然而，有些場景下咱們也會發覺一些估算的理由很牽強，甚至是需求自己就不是很合理，感受單純是「爲了估算而估算」。那麼估算都有必要嗎？若是有必要這個估算該怎麼作呢？

1、爲何要作估算？

首先咱們來回答第一個問題，要想知道估算是否有必要，就要先弄清楚估算的意義，估算到底幫咱們解決了什麼問題，這樣才能明確目標，才能設計合理的方案，才能夠判斷是否是必定要經過估算來解決這個問題。

Martin Fowler在他的文章《PurposeOfEstimation》中詳細闡述了爲何要作估算：

Estimation is valuable when it helps you make a significant decision.估算是爲了幫助咱們更好的作重要決策

沒錯，回想起須要作估算的場景，咱們都是須要估算的結果做爲輸入來幫助作決策，文章開頭的一些問題也對應着一些典型的須要作估算的場景，好比：作資源規劃，成本估計，安排開發計劃，或者評估一個需求的投入產出比等等，在這些場景中，估算能夠幫咱們理清作一件事情所須要的人力成本和時間成本，進而幫助咱們來作出合理的決策。

明確了估算在決策當中所起到的做用，咱們就能夠判段當前這個決策是否是必定須要估算做爲輸入，說到這裏，固然也有一些軟件開發活動並不須要估算也能順利開展，感興趣的能夠閱讀《PurposeOfEstimation》找到一些不須要估算的示例。

2、如何作估算？

明確了估算的意義，那如何作估算才能算是有效的估算，才能幫助咱們作出合理的決策呢？從估算在軟件開發過程當中所處的階段，能夠簡單的分爲兩類：

• 開發團隊介入前的需求成本估算
• 開發團隊在進入開發階段前的Story估算

然而無論是哪一種估算，正常的流程應該至少包括以下的步驟：

• 理清業務需求
• 肯定技術解決方案
• 將要作的事情拆分紅任務
• 針對每一個任務作出評估

2.1 有效的估算應該關注什麼？

上面的流程很簡單，但不一樣的人遵守這個流程獲得的估算結果可能會是不一樣的，一方面不一樣的人給出的解決方案多是不同的，另外一方面不一樣的我的經驗也會致使任務拆分結果的差別，進而致使估算結果的差別；

估算結果的差別並不表明估算是有問題的，由於作估算基於的前提條件是有差異的，那麼怎樣才能保證估算的結果能夠知足幫助咱們作決策的要求呢？在整個估算過程當中，咱們要重點關注如下幾點：

1）明確估算粒度

估算粒度決定咱們的設計要作到多細緻，估算的解決方案要作到多細緻。一般開發團隊介入前的需求成本估算，目的是用來判斷完成這個需求大概須要多少成本，粒度會比較粗；而開發團隊進入開發階段前的估算，目的是爲了作詳細的開發計劃，粒度會比較細。

估算粒度的大小能夠指導整個估算過程的進行，避免你們陷入無休止的細節討論之中，當遇到問題爭論不休時，咱們能夠馬上問一個問題：這個爭論的結果會影響咱們的估算嗎？若是不影響，能夠在後面有了更多輸入的時候再進行討論；若是有影響，那就要儘快找到能夠作決定的人來進行決策。

2）需求理解一致

在流程的第一步一般是業務分析人員對業務需求進行講解，闡明需求設計的業務價值，當前的業務現狀，須要作的改動，以及交互設計的一些細節；

在這個過程當中參與估算的架構設計人員或開發團隊須要理解需求的所有內容，並結合本身對當前系統的理解評估新的設計和改動是否和既有的實現有衝突，及時給予反饋，對設計上不理解的地方及時提問，保證你們對業務需求的理解在同一個層次上，這樣才能保證後續解決方案的合理性以及估算的合理性

3）估算應該是協做的結果

爲了確保估算的相對準確性，在敏捷開發中當Story卡準備好以後，一般整個開發團隊都要參與到估算當中，估算較高或較低的同窗要給出理由，儘可能避免由於上下文不一致致使估算的誤差。

而對於粒度較粗的估算每每會忽略這點，一方面粒度較粗，不須要特別細緻，準確性每每會被忽略；另外一方面在軟件開發初期可以作估算的人力資源有限；然而，這個粒度的估算對決策的影響每每更大，估算誤差較大對軟件開發項目的影響是巨大的，能夠試想一個場景：在最初的成本估計過程當中，若是低估了項目的複雜性，給出了較小的估算，一方面在開發過程當中不斷涌現的複雜性，對開發團隊來講是不可預期的，會影響開發團隊對總體開發進度的控制程度，另外一方面沒有足夠的預算，頗有可能致使項目開發到一半由於資金不足而失敗。

所以，在作較大決策相關的估算時，建議嘗試創建解決方案Review小組，估算的結果在小組內進行評估，確保不會產生較大的誤差。

4）明確估算基於的假設

從估算的基本流程能夠看出，估算是基於一個假定的解決方案，不一樣的解決方案的估算可能會有很大的差別，好比：

如今要把一個文件裏的內容導入到生產環境的數據庫中：解決方案能夠有兩種：

• 人工解析文件內容，轉化爲SQL，將數據寫入到生產環境的數據庫中
• 開發一個功能，操做人員能夠經過Web端選擇文件上傳到生產環境的數據庫中

兩個方案均可以解決問題，但不一樣的方案的優缺點也是明顯不一樣的，影響也是不一樣的，所以在估算給出的同時，要明確指出估算基於的假設，一旦假設不成立，咱們就須要進行從新估算。

2.2 估算須要考慮哪些因素？

前文提到不一樣的人對同一個需求作估算，結果多是不一樣的，由於解決方案多是不一樣的，估算的假設前提也多是不一樣的。從團隊的視角出發，無論是解決方案小組來Review估算，仍是開發團隊一塊兒來作估算，咱們能夠認爲解決方案是一致的，假設前提也是相同的，在這種狀況下怎麼能保證不一樣的人給出的估算是基本一致的，是符合團隊預期的呢？

本質上來講是要消除人的經驗對估算產生的影響，所以咱們要儘量多的找出影響估算結果的因素，在每次估算過程當中，你們都要經過各類問題來澄清這些因素是否會對估算結果產生影響，以及會產生多大的影響。

通過大量估算的分析，咱們認爲如下因素會對估算結果產生較大影響：

• 技術難度，新的技術/框架的引入
• 業務邏輯的複雜程度
• 交互設計的複雜程度
• 第三方的系統集成難易程度
• 數據量級，數據遷移的複雜度
• 是否破壞已有功能
• 跨功能性需求，好比性能、數據安全等等

以前項目上的同事爲了保證不一樣的人在估算過程當中可以儘可能給出符合團隊預期的結果，設計了不少問題幫助你們在估算時理清須要考慮的因素，我整理了一下，供你們參考：

類別	問題
前端	是否須要引入新的前端組件/框架？
	是否須要修改/複用現有組件？這些組件在哪些場景使用？
	是否包括較多的樣式細節調整？
	是否有特殊的異常處理邏輯？
	是否涉及較多的業務場景（組合狀況）？
	是否有複雜的交互邏輯和校驗邏輯？
	與後端服務的集成邏輯是否複雜？
後端	是否須要新建/修改API？
	是否會大量改動現有代碼/測試？
	是否有大量的跨服務交互？
	是否有比較複雜的業務流程控制？
	是否有新技術的引入，須要作進一步的調研？
	是否有性能風險？涉及數據量級有多大？
	是否須要寫大量的測試代碼（單元測試、契約測試）？
數據	功能驗收的數據準備是否複雜？
	是否須要新建數據表結構？
	是否須要作數據遷移？數據遷移的數據量和複雜度有多大？
	當前數據結構的修改是否會影響到其餘功能，好比報表、ETL任務等？
系統集成	是否包含系統集成？
	是否須要在集成中考慮失敗重試的場景？
	是否須要考慮集成接口的冪等性？
	系統集成邏輯和場景是否比較複雜？是否有不少異常場景須要處理？
	集成對端系統是既有功能仍是新開發的？
	是否須要在系統集成過程當中作大量的溝通工做？
	系統集成測試環境的搭建是否困難？
	系統集成的聯調工做是否容易開展？

結語

估算在整個軟件開發週期當中起着很是重要的做用，往大了說，它可能決定了整個項目的開發資源配置，它也可能決定了整個項目的開發週期和交付節奏，它甚至可能決定了一個項目還未開始就不會繼續下去。所以，在作估算以前，咱們要明確此次估算在接下來的決策中到底起到什麼做用，能夠幫咱們解決什麼問題。

然而，在整個世界都在高速發展的大環境下，惟一不變的就是變化，敏捷軟件開發也因其能應對需求的快速變化而成爲主流的開發模式。估算是基於必定的假設前提，在必定的上下文下才成立的，一旦假設發生變化，估算就失效了，咱們須要從新作決策，必要時估算也須要重頭來過。

來源：碼猿外

做者：麻廣廣

聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

IDCF DevOps黑客馬拉松👉 9月11-12日，上海站，11月20-21日，深圳站，企業組隊參賽&我的參賽都可，一年等一回，錯過等一年，趕忙上車~公衆號回覆「黑馬」加入