程式員如何精確評估開發時間？

（給資料分析與開發加星標，提升資料技能）

來源：Eric_LG

blog.csdn.net/gang544043963/article/details/83934015

一個程式員能否精確評估開發時間，是一件非常重要的事情。如果你掌握了這項技能，你在別人的眼裡就會是這樣：

 

• 靠譜
• 經驗十足
• 對需求很瞭解
• 延期風險小
• 合格的軟體工程師
• 正規軍，不是野路子

 

評估開發時間的重要性

 

首先，在一個專案中，所有的環節都是承上啟下的，上一個環節結束的時間節點正是下一個環節開始的節點。那麼在一個專案或者一次迭代正式啟動前，所有的環節都應該有個時間評估。以一次APP需求迭代為例，專案計劃像這樣：

 

• UI設計圖 11.01 – 11.03（3工作日）
• API介面討論與設計 11.04（1工作日）
• 移動端開發 11.05 – 11.15（8工作日）
• 後端具備聯調條件：11.11
• 產品體驗 11.16 – 11.17（2工作日）
• 測試11.18 – 11.25（5工作日）
• 釋出11.26

 

根據專案計劃，各個部門自己要分配人員和時間。如果其中一個環節延期了，那麼後面的各個環節都要順延，就會造成損失。

 

其次，對於程式員來說，一個清晰的開發計劃有助於自己有條不紊地開展工作，也能避免疏漏某個功能點。評估時間的過程，也是對需求詳細拆分的過程，瞭解要做什麼，做成什麼樣子。在評估的過程中，根據專業知識和經驗，充分預估會遇到的風險，怎樣的解決方案，預留多少時間？都想好了的話，專案也就沒啥風險了。

 

然而，開發時間評估，最大的好處是程式員受益。認真地評估開發時間，會讓你在開始動手寫程式碼之前搞清楚要怎麼寫，每個模組的設計心理得有個譜。從宏觀上拆分模組，然後詳細地分解任務，具體到一個很小的功能點。這樣你就能清晰地設計程式碼，而不是堆程式碼。也避免了很多時候寫著寫著發現不對，然後拉到重來的境地。就是要讓你動手寫程式碼之前胸有成竹！

 

初學者為什麼評估不準？

 

如果你的專案經常delay，那麼八成是時間評估不準。

 

 

剛畢業的學生被問到什麼時候可以完成的時候，腦門一拍：“三天”，實際上兩個星期過去了還沒完成。

 

 

這裡有一張表，看看你是不是這樣子，對號入座：

 

 

越是老程式員越是“膽小”，評估時間越準。

 

如何精確評估開發時間

 

最近幾年，我都是以小時為單位進行時間評估的，有沒有覺得有點恐怖？長期以來這樣的習慣讓我收穫頗多。這得感謝我之前的領導，三年前強迫我們這樣做，剛開始很抵觸，後來才體會到其中的甜頭。

 

1、任務拆分

 

 

拿到新需求後，對其進行充分瞭解，不清楚的就去問清楚，然後對其進行模組化。之後，再進行技術上的拆分。由大到小，再到細節。細到什麼程度呢？細到一個按鈕的實現，細到一個點選動作是要用按鈕還是要用手勢的定奪，最好能細到程式碼塊的劃分。

 

這個能力是需要鍛煉的，做好拆分，然後在實際開發過程中根據實際時間花銷，回顧時間評估的準確性，以便讓下次更準確。慢慢地，就會越來越精確，評估時間有依有據，不再是拍腦門給出的時間。下麵看一個例子：

 

 

 

2、合理認知時間

 

 

一天工作八小時，但你不可能專註地連續八小時在編寫程式碼。一天的工作中，有開會、討論、階段性休息（掃清聞、喝咖啡、發獃）的時間開銷，真正有效時間其實不足六小時，雜事多的話可能是四五個小時。

 

3、預留buffer(緩衝區)

 

 

首先明確，預留buffer不是讓你隨便增加預估量，而是要明確知道buffer是給那些事情用的。要考慮到一下幾點：

 

首先是溝通時間，你開發的時候不可能是悶著頭一直寫程式碼。要和UI設計師溝通，要和產品經理溝通，有可能還需要和組內的人溝通技術上的事情，以及和別的技術小組對接的問題。

 

等待時間。如果牽扯多部門協作，會有很多等待時間，因為你不能保證別的部門就能準確按照計劃時間完成的。雖然等待過程中你可以安排其他任務，但你不能保證其他任務就能剛好填充等待時間，更何況任務切換也需要時間成本。

 

突髮狀況。例如，bug修改、需求微調、對接人請假。

 

不確定時間。和其他部門有交集的工作，最好多預留buffer。比如移動端和後臺聯調。後端信誓旦旦給你說11.11號可以進行聯調，這次聯調總共5個介面。如果你簡單地認為他們給你提供的介面沒問題，並且能順利請求回來資料，預計一天聯調時間足以，那你就等著delay吧。11.10號你已經準備好了所有聯調準備，如果資料能正確傳回，你的解析功能都是OK的，因為你之前用假資料已經處理的好好的。到了11號，你請求第一個介面就報錯了，然後在即時通訊軟體上問他們怎麼回事，半個小時後給你回了“不好意思，地址變了，你用這個試試”。又錯了……。終於回來資料了，然後發現缺少兩個欄位……。就這樣，第一個介面調通已經快下班了。（當然很多後端技術人員也是很靠譜的，舉這個例子只是為了讓多考慮）

 

以上是可能會出現的狀況，實際中有可能只是出現了一部分，這要根據實際情況而定。並不是讓你能多預留buffer就多留，畢竟每個專案的時間都是很緊張的。一般buffer留在15%-25%。

 

4、回頭看

 

 

在實際開發過程中，測量實際花費時間，並與估算相比較。如果有些地方相差較大，就要看差在哪裡，然後在下次預估中避免相同的差錯。

 

總結

 

程式設計經驗不等同於估算經驗。一個不被包含在估算流程中的開發者將不會擅長估算。同樣，如果實際的時間花費不被測量和用於與估算比較，那麼將沒有反饋來學習。

 

最後，每個程式員都應該具備估算的技能。為磨練這個技能，接手每個任務時，先決定你要做什麼。然後在開始之前估算任務所需時間。最後測量實際花費時間，並與估算相比較。同樣比較你實際完成的與計劃完成的。這樣你將會既提高你對一個任務包含細節的理解，同樣也提高了你的估算技能。

 

儘管進行了精確估算，也不能保證每個專案都會100%精確。偶爾會遇到一些突發情況和沒預估到的風險是不可避免的。那麼面對風險，有一些原則可以幫助你：

 

• 報風險時間置前，如果開發開始或者任何過程有可能導致專案延期或者需求無法實現的時候就報警，不要等加班能實現或者存在僥幸心理；
• 對於不確定的需求，一定要溝通到位；
• 涉及到互動細節，必須提前溝通好，充分明確細節；
• 技術可行性方案提前調查清楚。

 

 

完結~~~~~~~