軟件項(xiàng)目一般經(jīng)過需求確定、原型、UI、軟件開發(fā)、軟件測試等流程。不同軟件項(xiàng)目管理者劃分這流程可能會有所不同。但是需要進(jìn)行工作流程還是大體相似的。那么如何評估軟件項(xiàng)目需要多長時間呢?

項(xiàng)目管理者評估方法：

1.一般來說，不管是公司內(nèi)部的軟件產(chǎn)品開發(fā)還是外部的合同定制化軟件開發(fā)都會有一個概要的時間點(diǎn)要求，這個時間要求可能是版本上線日期，也可能是合同交付如期，不管怎樣，我們產(chǎn)品項(xiàng)目持續(xù)的時長都必須在在這個時間點(diǎn)限制下。

2.如果是合同定制化的軟件開發(fā)，一般來說需求會比較明確，這個時候，項(xiàng)目經(jīng)理和甲方溝通確認(rèn)好需求后，根據(jù)合同的要求定義項(xiàng)目的里程碑，然后依照自己開發(fā)團(tuán)隊(duì)的產(chǎn)能進(jìn)行迭代開發(fā)或者瀑布開發(fā)，可能一個里程碑會走一個小瀑布，或者一個里程碑切分成若干迭代。當(dāng)需求很明確，研發(fā)管理很完善的情況下可以考慮瀑布開發(fā);如果需求一般明確，可以考慮迭代開發(fā)，或者SCRUM。具體的要看具體情況。如果是公司內(nèi)部的軟件產(chǎn)品開發(fā)，一般來說，產(chǎn)品經(jīng)理要依照產(chǎn)品研發(fā)的特點(diǎn)，定義產(chǎn)品的愿景、目標(biāo)，產(chǎn)品路線圖，產(chǎn)品版本規(guī)劃，當(dāng)產(chǎn)品版本規(guī)劃定出來后，可以選擇SCRUM，走迭代開發(fā)。

3.如果需求上你不采用用戶故事方法，采用用例或者需求功能模塊等的話，可能要用到工時評估計(jì)劃時間。如果需求上你采用用戶故事和SCRUM開發(fā)，你可以用故事點(diǎn)數(shù)和團(tuán)隊(duì)的速率之間的對應(yīng)來評估計(jì)劃時間。

軟件開發(fā)者時間評估方法，某軟件開發(fā)者的經(jīng)驗(yàn)之談：

1、想要搞清楚一個事情需要多少時間完成，這最好的方法是找一個程序員已經(jīng)完成的、相似的項(xiàng)目。對一些簡單的網(wǎng)站和應(yīng)用來說非常有效，或者那些使用標(biāo)準(zhǔn)CRUD的項(xiàng)目也是適用。當(dāng)項(xiàng)目小且簡單時這種方法最好用。這種方法可以用在軟件1.0版本時，但以后的版本就不行了，因?yàn)檫@時你跟相參照的項(xiàng)目開始慢慢的產(chǎn)生差異，這時寫的代碼是你以前沒有寫過的。

2、我的好朋友、并且是以前的同事John Walker(不是這個John

Walker)喜歡用這種方法。把項(xiàng)目拆解成最小的任務(wù)。然后記錄完成每個任務(wù)你認(rèn)為可能需要多少小時、天、周、月。遵循這種原則，如果一個任務(wù)需要幾小時，就是算成一天，如果需要數(shù)天，就是算成一周，如果是數(shù)周，就算成一月。如果超過一個月，那你就無法知道需要多少時間了，或你根本不知道要做什么。

3、我有自己的預(yù)估方法，但事實(shí)上跟John的把任務(wù)拆分成最小的子任務(wù)的方法非常相似。我是以最壞的情況下每個最小單元需要的完成時間為標(biāo)準(zhǔn)。匯總，然后乘以4。再向上取舍到最近的素?cái)?shù)，就算是對我的這種沒譜的方法的諷刺吧。

上面是一些可供參考做法，也許你有更好方法來評估軟件項(xiàng)目需要多長時間，那請?jiān)徯【幇嚅T弄斧了。如果你有更好點(diǎn)子，不妨說出來，給大家分享一下，獲取還能引出更好點(diǎn)子哦。

本文轉(zhuǎn)載自拓源優(yōu)課：www.toyoke.com