如何評(píng)估軟件項(xiàng)目需要多長時(shí)間

如何評(píng)估軟件項(xiàng)目需要多長時(shí)間

軟件項(xiàng)目一般經(jīng)過需求確定、原型、UI、軟件開發(fā)、軟件測試等流程。不同軟件項(xiàng)目管理者劃分這流程可能會(huì)有所不同。但是需要進(jìn)行工作流程還是大體相似的。那么如何評(píng)估軟件項(xiàng)目需要多長時(shí)間呢?項(xiàng)目管理者評(píng)估方法：1.一般來說，不管是公司內(nèi)部的軟件產(chǎn)品開發(fā)還是外部的合同定制化軟件開發(fā)都會(huì)有一個(gè)概要的時(shí)間點(diǎn)要求，這個(gè)時(shí)間要求可能是版本上線日期，也可能是合同交付如期，不管怎樣，我們產(chǎn)品項(xiàng)目持續(xù)的時(shí)長都必須在在這個(gè)時(shí)間點(diǎn)限制下。2.如果是合同定制化的軟件開發(fā)，一般來說需求會(huì)比較明確，這個(gè)時(shí)候，項(xiàng)目經(jīng)理和甲方溝通確認(rèn)好需求后，根據(jù)合同的要求定義項(xiàng)目的里程碑，然后依照自己開發(fā)團(tuán)隊(duì)的產(chǎn)能進(jìn)行迭代開發(fā)或者瀑布開發(fā)，可能一個(gè)里程碑會(huì)走一個(gè)小瀑布，或者一個(gè)里程碑切分成若干迭代。當(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.如果需求上你不采用用戶故事方法，采用用例或者需求功能模塊等的話，可能要用到工時(shí)評(píng)估計(jì)劃時(shí)間。如果需求上你采用用戶故事和SCRUM開發(fā)，你可以用故事點(diǎn)數(shù)和團(tuán)隊(duì)的速率之間的對(duì)應(yīng)來評(píng)估計(jì)劃時(shí)間。軟件開發(fā)者時(shí)間評(píng)估方法，某軟件開發(fā)者的經(jīng)驗(yàn)之談：1、想要搞清楚一個(gè)事情需要多少時(shí)間完成，這最好的方法是找一個(gè)程序員已經(jīng)完成的、相似的項(xiàng)目。對(duì)一些簡單的網(wǎng)站和應(yīng)用來說非常有效，或者那些使用標(biāo)準(zhǔn)CRUD的項(xiàng)目也是適用。當(dāng)項(xiàng)目小且簡單時(shí)這種方法最好用。這種方法可以用在軟件1.0版本時(shí)，但以后的版本就不行了，因?yàn)檫@時(shí)你跟相參照的項(xiàng)目開始慢慢的產(chǎn)生差異，這時(shí)寫的代碼是你以前沒有寫過的。2、我的好朋友、并且是以前的同事JohnWalker(不是這個(gè)JohnWalker)喜歡用這種方法。把項(xiàng)目拆解成最小的任務(wù)。然后記錄完成每個(gè)任務(wù)你認(rèn)為可能需要多少小時(shí)、天、周、月。遵循這種原則，如果一個(gè)任務(wù)需要幾小時(shí)，就是算成一天，如果需要數(shù)天，就是算成一周，如果是數(shù)周，就算成一月。如果超過一個(gè)月，那你就無法知道需要多少時(shí)間了，或你根本不知道要做什么。3、我有自己的預(yù)估方法，但事實(shí)上跟John的把任務(wù)拆分成最小的子任務(wù)的方法非常相似。我是以最壞的情況下每個(gè)最小單元需