程序員如何預估本身的項目開發時間?

項目時間的估算對項目的成敗相當重要。項目時間管理包括了項目按時完成所需的各個過程。可是,在實際項目中,常常出現項目延期,估算嚴重不許確的現象。程序員

預估時間自己就很難。每一個程序員的估計都會跟真正須要的時間有些差距。估計時間短了說明有些事情被忽略了(編譯,測試,提交代碼)。估計時間超了說明任務太大,難以理解。面試

對於資歷較淺的程序員,這種估計偏差是混亂的,他們常常會輕視一些任務,同時又對一些稍微有難度的任務過度高估。我認爲,對一個有經驗的程序員,一個任務的時間應該在半小時到24小時之間,超出24小時的任務都須要拆分。程序員在腦中想想可能會認爲要60小時,但實際上即便是頗有經驗的程序員也須要將任務分紅可控的模塊再來分析作決定。編程

還有一個很重要的須要認識到的一點是,編程上的經驗並不等同於時間估計上的經驗。一個從沒有作過工期估計的程序員不會擅長估計時間。若是不去拿真正須要的時間和估計出的時間進行比較,你不可能從其它反饋信息之獲得正確估計時間的經驗。測試

每一個程序員都會用到評估技巧。爲了提升你的這項技能,你能夠在你從事的每一個任務上進行鍛鍊。在任務開始時先預估開發所需時間,拿它跟你最終真正用掉的時間進行對比。這樣,你不只在對任務細節的理解上有提升,同時也提升了你對時間預估的技能。優化

霍夫斯塔特定律:實際時間老是比預期要長,即使你考慮到了霍夫斯塔特定律。動畫

常常會有 PM 抱怨說,爲何公司的開發永遠不能估計本身的項目時間?!然而機智的程序員早就對此司空見慣了。我甚至見過一個預計 2 天完成的項目最後花了 4 個月的時間,即便按照「時間翻倍」的經驗法則來看也是挺誇張的。從高級層面來看,問題在於 —— 工程師和 PM 或者其餘人員對時間估算的方法和思惟方式不一樣。網站

大多數工程師的第一反應是,若是一切按照計劃正常進行的話,寫出一個原型所須要的最短期。而 PM 或者其餘下游人員的想知道的是,項目何時能夠準備完畢,今後時到發佈的這段時間是多長?所以這徹底是兩個不一樣的故事了。編碼

因此對於工程師來講,掌握時間估算是一項必備技能,這意味着你是專業、穩定而高效的開發者。spa

爲何須要進行時間估算?設計

外部依賴

任何有效的事情都不會憑空發生。項目一般存在外部依賴性,好比跟職能團隊的溝通(財務、PR、客戶支持)以及客戶的交流等。而跟這些外部依賴協調的每每是 PM 或者CEO的工做,這意味着最有資格作時間估算的人(工程師)並非最須要作這些測算的人。這種不對稱致使了根本性的緊張。

優先級

時間測算對肯定優先級也很關鍵。工程領域中性價比是一項重要指標,哪怕你在作的功能是全世界最厲害的,通過時間測算髮現須要很長時間才能實現的話,那這個功能的優先級也不會過高。

比方說你正在作一個項目,作成以後可讓網站快 50%,但用一樣的時間你原本能夠完成 2 個項目,並且每一個項目均可以讓網站快 40%。若是你不花點時間進行初步測算的話,你永遠都不知道還能夠作一個更快的網站!

初級時間估算

假設咱們達成了時間估算很是重要這個共識,那麼咱們繼續看一下如何估算。一般狀況下,咱們低估所需時間是由於咱們想的是「寫出一個原型須要多長時間?」。

可是,交付的東西每每要比原型大多了,你還須要考慮測試、調試、優化所花費的時間。還有開會、訪談、代碼評審,甚至發郵件都是須要花費時間的。

低估所需時間的另外一個緣由是意外的問題,這些問題每每不能被充分考慮到,好比 IDE 更新而讓你多花了一天去配置環境等等。

基於此,咱們最好不要太相信所謂的經驗和直覺。

Step 1:制定技術方案

在開始任何一個重要項目以前,你都應該有一份技術計劃或者設計文檔。這個文檔的目的在於讓別人知道你在作的事情,並能得到反饋。當你注意到其中的技術細節時,你就會更清晰知道具體所耗費的時間,好比把某個庫更新到新版本,可能會多花一天的時間。你甚至還得本身寫一個庫。

顆粒度在這裏是很重要的。若是有哪一部分讓人以爲不清楚,要麼是你應該瞭解更多相關知識,要麼得把它分解爲更細緻的步驟。與此同時,若是一個步驟太細的話,又可能會太脆弱致使整個計劃無效,因此要把握好這個度。

想要知道你的文檔裏應該考慮哪些東西,能夠看看AliciaChen 的 這篇文章。關鍵在於跟 PM 溝通清楚,消除有歧義的地方,這樣纔不會致使最後要推翻重來。

Step 2:爲每一步添加時間估算

文檔裏的每一步實現須要多少時間,這每每牽涉到對細節的研究(這個是否是已經有庫了?)。所以視項目性質而言,先作一個簡單的原型能夠幫助揭示許多潛在的痛點。

Step 3:追加容錯時間

如今你已經有了初步的時間估算,不過還有許多其餘須要考慮的因素。

隨時調試:Bug 難以免,這取決於開發者對特定代碼庫的經驗以及代碼庫的成熟度。會議和假期:開會或者放假時通常來講是不會敲代碼的,因此真正敲代碼有多長時間?所以時間估算時要好好看看日程表。最終測試:一般應該一邊編碼一邊測試,但不少團隊在發佈前還須要作集成測試,所以在你的估算中留出這部分的時間。代碼評審:在這個代碼庫中你通常須要進行幾輪?每輪須要多少時間?要通過多少評審人?留意評審人的日程安排確保代碼評審的時間。

當你把交付時間的開銷也考慮進去,你就能看到本身的時間估算和項目的實際發佈時間要匹配得多。儘管實際狀況可能還會更長,你也可能會因壓力而須要縮短工期。但當你們明白你的估算更準確時,也會更信任你。

Step 4:發佈後評審上期時間估算

覆盤還挺痛苦的,可是回顧能讓你在下一次作得更好。每個實際與預期時間不匹配的項目都發生了什麼,找到緣由並改進它。

總而言之一切在於溝通。提早溝通、常常溝通,瞭解彼此的日程和需求變動。

跟 PM 等相關參與者的溝通也能讓對方提供可能會影響你估算的重要信息。一位設計師可能會說這個動畫須要一週工期,乾脆砍掉不要了。另外一位 PM 也可能補充說這個原型只是對用戶進行研究的而已,此次迭代不用處理太多 bug。

對於工程師來講,不要作不切實際的更短工期的妥協,開誠佈公更顯專業。對於 PM 和其餘人來講,尊重這一估算可能須要一個過程,但要知道光靠嘮叨是不可能縮短工期的。

項目時間估算不容易,惟有善於溝通、有同理心以及肯定功能優先級才能夠。

閱讀更多

到外企?爲何別的程序員那麼容易

一招教你打造一個滑動置頂的視覺特效

NDK項目實戰—高仿360手機助手之卸載監聽

(Android)面試題級答案(精選版)

相信本身,沒有作不到的,只有想不到的

相關文章
相關標籤/搜索