<progress id="uuezx"></progress>
<th id="uuezx"></th>
  • <li id="uuezx"><acronym id="uuezx"><cite id="uuezx"></cite></acronym></li>

    程序員如何精確評估開發時間?

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

     

    1、任務拆分

     

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

     

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

    圖片7.png 

     

    2、合理認知時間

     

    一天工作八小時,但你不可能專注地連續八小時在編寫代碼。一天的工作中,有開會、討論、階段性休息(刷新聞、喝咖啡、發呆)的時間開銷,真正有效時間其實不足六小時,雜事多的話可能是四五個小時。

     

    3、預留buffer(緩沖區)

     

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

     

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

     

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

     

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

     

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

     

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

     

    4、回頭看

     

    在實際開發過程中,測量實際花費時間,并與估算相比較。如果有些地方相差較大,就要看差在哪里,然后在下次預估中避免相同的差錯。
    上下文導航
    相關內容
    全國熱線

    0551-69117050

    咨詢服務熱線:8:00-23:00

    合肥一元教育咨詢有限公司版權所有 如有圖片侵權請及時聯系本站,將及時刪錯或更改

    皖ICP備13012660號-1

    在線咨詢
    電話咨詢
    Tel:0551-69117050
    微信

    掃一掃
    歡迎微信咨詢

    QQ咨詢
    返回頂部