一個(gè)程序員能否精確評(píng)估開(kāi)發(fā)時(shí)間，是一件非常重要的事情。如果你掌握了這項(xiàng)技能，你在別人的眼里就會(huì)是這樣：

• 靠譜

• 經(jīng)驗(yàn)十足

• 對(duì)需求很了解

• 延期風(fēng)險(xiǎn)小

• 合格的軟件工程師

• 正規(guī)軍，不是野路子

評(píng)估開(kāi)發(fā)時(shí)間的重要性

首先，在一個(gè)項(xiàng)目中，所有的環(huán)節(jié)都是承上啟下的，上一個(gè)環(huán)節(jié)結(jié)束的時(shí)間節(jié)點(diǎn)正是下一個(gè)環(huán)節(jié)開(kāi)始的節(jié)點(diǎn)。那么在一個(gè)項(xiàng)目或者一次迭代正式啟動(dòng)前，所有的環(huán)節(jié)都應(yīng)該有個(gè)時(shí)間評(píng)估。以一次APP需求迭代為例，項(xiàng)目計(jì)劃像這樣：

1.UI設(shè)計(jì)圖 11.01 - 11.03（3工作日）

2.API接口討論與設(shè)計(jì) 11.04（1工作日）

3.移動(dòng)端開(kāi)發(fā) 11.05 - 11.15（8工作日）

4.后端具備聯(lián)調(diào)條件：11.11

5.產(chǎn)品體驗(yàn) 11.16 - 11.17（2工作日）

6.測(cè)試11.18 - 11.25（5工作日）

7.發(fā)布11.26

根據(jù)項(xiàng)目計(jì)劃，各個(gè)部門(mén)自己要分配人員和時(shí)間。如果其中一個(gè)環(huán)節(jié)延期了，那么后面的各個(gè)環(huán)節(jié)都要順延，就會(huì)造成損失。

其次，對(duì)于程序員來(lái)說(shuō)，一個(gè)清晰的開(kāi)發(fā)計(jì)劃有助于自己有條不紊地開(kāi)展工作，也能避免疏漏某個(gè)功能點(diǎn)。評(píng)估時(shí)間的過(guò)程，也是對(duì)需求詳細(xì)拆分的過(guò)程，了解要做什么，做成什么樣子。

在評(píng)估的過(guò)程中，根據(jù)專業(yè)知識(shí)和經(jīng)驗(yàn)，充分預(yù)估會(huì)遇到的風(fēng)險(xiǎn)，怎樣的解決方案，預(yù)留多少時(shí)間？都想好了的話，項(xiàng)目也就沒(méi)啥風(fēng)險(xiǎn)了。

然而，開(kāi)發(fā)時(shí)間評(píng)估，最大的好處是程序員受益。認(rèn)真地評(píng)估開(kāi)發(fā)時(shí)間，會(huì)讓你在開(kāi)始動(dòng)手寫(xiě)代碼之前搞清楚要怎么寫(xiě)，每個(gè)模塊的設(shè)計(jì)心理得有個(gè)譜。從宏觀上拆分模塊，然后詳細(xì)地分解任務(wù)，具體到一個(gè)很小的功能點(diǎn)。

這樣你就能清晰地設(shè)計(jì)代碼，而不是堆代碼。也避免了很多時(shí)候?qū)懼鴮?xiě)著發(fā)現(xiàn)不對(duì)，然后拉到重來(lái)的境地。就是要讓你動(dòng)手寫(xiě)代碼之前胸有成竹！

初學(xué)者為什么評(píng)估不準(zhǔn)？

如果你的項(xiàng)目經(jīng)常delay，那么八成是時(shí)間評(píng)估不準(zhǔn)。

剛畢業(yè)的學(xué)生被問(wèn)到什么時(shí)候可以完成的時(shí)候，腦門(mén)一拍：“三天”，實(shí)際上兩個(gè)星期過(guò)去了還沒(méi)完成。

這里有一張表，看看你是不是這樣子，對(duì)號(hào)入座：

越是老程序員越是“膽小”，評(píng)估時(shí)間越準(zhǔn)。

如何精確評(píng)估開(kāi)發(fā)時(shí)間

最近幾年，我都是以小時(shí)為單位進(jìn)行時(shí)間評(píng)估的，有沒(méi)有覺(jué)得有點(diǎn)恐怖？長(zhǎng)期以來(lái)這樣的習(xí)慣讓我收獲頗多。這得感謝我之前的領(lǐng)導(dǎo)，三年前強(qiáng)迫我們這樣做，剛開(kāi)始很抵觸，后來(lái)才體會(huì)到其中的甜頭。

1、任務(wù)拆分

拿到新需求后，對(duì)其進(jìn)行充分了解，不清楚的就去問(wèn)清楚，然后對(duì)其進(jìn)行模塊化。之后，再進(jìn)行技術(shù)上的拆分。由大到小，再到細(xì)節(jié)。細(xì)到什么程度呢？細(xì)到一個(gè)按鈕的實(shí)現(xiàn)，細(xì)到一個(gè)點(diǎn)擊動(dòng)作是要用按鈕還是要用手勢(shì)的定奪，最好能細(xì)到代碼塊的劃分。

這個(gè)能力是需要鍛煉的，做好拆分，然后在實(shí)際開(kāi)發(fā)過(guò)程中根據(jù)實(shí)際時(shí)間花銷(xiāo)，回顧時(shí)間評(píng)估的準(zhǔn)確性，以便讓下次更準(zhǔn)確。慢慢地，就會(huì)越來(lái)越精確，評(píng)估時(shí)間有依有據(jù)，不再是拍腦門(mén)給出的時(shí)間。下面看一個(gè)例子：

2、合理認(rèn)知時(shí)間

一天工作八小時(shí)，但你不可能專注地連續(xù)八小時(shí)在編寫(xiě)代碼。一天的工作中，有開(kāi)會(huì)、討論、階段性休息（刷新聞、喝咖啡、發(fā)呆）的時(shí)間開(kāi)銷(xiāo)，真正有效時(shí)間其實(shí)不足六小時(shí)，雜事多的話可能是四五個(gè)小時(shí)。

3、預(yù)留buffer(緩沖區(qū))

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

首先是溝通時(shí)間，你開(kāi)發(fā)的時(shí)候不可能是悶著頭一直寫(xiě)代碼。要和UI設(shè)計(jì)師溝通，要和產(chǎn)品經(jīng)理溝通，有可能還需要和組內(nèi)的人溝通技術(shù)上的事情，以及和別的技術(shù)小組對(duì)接的問(wèn)題。

等待時(shí)間。如果牽扯多部門(mén)協(xié)作，會(huì)有很多等待時(shí)間，因?yàn)槟悴荒鼙ＷC別的部門(mén)就能準(zhǔn)確按照計(jì)劃時(shí)間完成的。雖然等待過(guò)程中你可以安排其他任務(wù)，但你不能保證其他任務(wù)就能剛好填充等待時(shí)間，更何況任務(wù)切換也需要時(shí)間成本。

突發(fā)狀況。例如，bug修改、需求微調(diào)、對(duì)接人請(qǐng)假。

不確定時(shí)間。和其他部門(mén)有交集的工作，最好多預(yù)留buffer。比如移動(dòng)端和后臺(tái)聯(lián)調(diào)。后端信誓旦旦給你說(shuō)11.11號(hào)可以進(jìn)行聯(lián)調(diào)，這次聯(lián)調(diào)總共5個(gè)接口。如果你簡(jiǎn)單地認(rèn)為他們給你提供的接口沒(méi)問(wèn)題，并且能順利請(qǐng)求回來(lái)數(shù)據(jù)，預(yù)計(jì)一天聯(lián)調(diào)時(shí)間足以，那你就等著delay吧。11.10號(hào)你已經(jīng)準(zhǔn)備好了所有聯(lián)調(diào)準(zhǔn)備，如果數(shù)據(jù)能正確返回，你的解析功能都是OK的，因?yàn)槟阒坝眉贁?shù)據(jù)已經(jīng)處理的好好的。到了11號(hào)，你請(qǐng)求第一個(gè)接口就報(bào)錯(cuò)了，然后在即時(shí)通訊軟件上問(wèn)他們?cè)趺椿厥?#xff0c;半個(gè)小時(shí)后給你回了“不好意思，地址變了，你用這個(gè)試試”。又錯(cuò)了……。終于回來(lái)數(shù)據(jù)了，然后發(fā)現(xiàn)缺少兩個(gè)字段……。就這樣，第一個(gè)接口調(diào)通已經(jīng)快下班了。（當(dāng)然很多后端技術(shù)人員也是很靠譜的，舉這個(gè)例子只是為了讓多考慮）

以上是可能會(huì)出現(xiàn)的狀況，實(shí)際中有可能只是出現(xiàn)了一部分，這要根據(jù)實(shí)際情況而定。并不是讓你能多預(yù)留buffer就多留，畢竟每個(gè)項(xiàng)目的時(shí)間都是很緊張的。一般buffer留在15%-25%。

4、回頭看

在實(shí)際開(kāi)發(fā)過(guò)程中，測(cè)量實(shí)際花費(fèi)時(shí)間，并與估算相比較。如果有些地方相差較大，就要看差在哪里，然后在下次預(yù)估中避免相同的差錯(cuò)。

總結(jié)

編程經(jīng)驗(yàn)不等同于估算經(jīng)驗(yàn)。一個(gè)不被包含在估算流程中的開(kāi)發(fā)者將不會(huì)擅長(zhǎng)估算。同樣，如果實(shí)際的時(shí)間花費(fèi)不被測(cè)量和用于與估算比較，那么將沒(méi)有反饋來(lái)學(xué)習(xí)。

最后，每個(gè)程序員都應(yīng)該具備估算的技能。為磨練這個(gè)技能，接手每個(gè)任務(wù)時(shí)，先決定你要做什么。然后在開(kāi)始之前估算任務(wù)所需時(shí)間。最后測(cè)量實(shí)際花費(fèi)時(shí)間，并與估算相比較。同樣比較你實(shí)際完成的與計(jì)劃完成的。這樣你將會(huì)既提高你對(duì)一個(gè)任務(wù)包含細(xì)節(jié)的理解，同樣也提高了你的估算技能。

盡管進(jìn)行了精確估算，也不能保證每個(gè)項(xiàng)目都會(huì)100%精確。偶爾會(huì)遇到一些突發(fā)情況和沒(méi)預(yù)估到的風(fēng)險(xiǎn)是不可避免的。那么面對(duì)風(fēng)險(xiǎn)，有一些原則可以幫助你：

• 報(bào)風(fēng)險(xiǎn)時(shí)間置前，如果開(kāi)發(fā)開(kāi)始或者任何過(guò)程有可能導(dǎo)致項(xiàng)目延期或者需求無(wú)法實(shí)現(xiàn)的時(shí)候就報(bào)警，不要等加班能實(shí)現(xiàn)或者存在僥幸心理；

• 對(duì)于不確定的需求，一定要溝通到位；

• 涉及到交互細(xì)節(jié)，必須提前溝通好，充分明確細(xì)節(jié)；

• 技術(shù)可行性方案提前調(diào)查清楚。

總結(jié)

以上是生活随笔為你收集整理的如何精确评估开发时间的 4 个小套路？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。