員工工作量評估范文

1、員工工作量評估范文今天剛剛進(jìn)行了一個(gè)小軟件的工作量評估，總是覺得評估的不夠準(zhǔn)確，而且難以明確，把心中的困擾跟實(shí)際所使用的做法簡單說說，工作量評估中，困擾我的問題主要有以下幾個(gè)1 、需求不清晰，并且會有變化2 、工作量評估在需求規(guī)格說明編寫的同時(shí)就需要進(jìn)行， 一般來說，沒有立項(xiàng)， 就還不會做詳細(xì)的需求調(diào)研， 但這時(shí)候就要出工作量評估3 、系統(tǒng)架構(gòu)及設(shè)計(jì)沒有開始，此時(shí)工作量評估往往不準(zhǔn)確，比如可以采用一個(gè)既有的組件， 或者重用一些代碼， 但是沒有詳細(xì)定義設(shè)計(jì)時(shí)，難以確定準(zhǔn)確可以節(jié)約多少時(shí)間，改造成本4 、不知道自己將面對什么樣的開發(fā)團(tuán)隊(duì)，有人一天，有人要10天才能做完，但你很難有一支你熟悉了解的團(tuán)

2、隊(duì)雖然也了解過各種工作量評估方法，但是實(shí)際中總感覺難以使用（應(yīng)該是不會使用）自己的做法如下：1 、確定有多少模塊，每個(gè)模塊下有多少頁面，針對每個(gè)模塊列出需求、設(shè)計(jì)、開發(fā)、測試、部署時(shí)間，組成這一模塊的時(shí)間2 、需要多少個(gè)公共的類，分別有多復(fù)雜3 、加上項(xiàng)目管理時(shí)間，大概5 個(gè)人的團(tuán)隊(duì)，需要一個(gè)不編碼的專門管理，做類似于功能檢查，代碼 review 之類的事情4 、加上一定比例的變更時(shí)間（根據(jù)用戶的歷史情況而定，或者感覺用戶頭腦清晰度而定）5 、最后得出的數(shù)字乘以一個(gè)1.5-3 ，得出最后時(shí)間，這個(gè)1.5-3是根據(jù)評估人歷史的情況， 比如， 我以前一年里評估的工作量大概都需要乘以 2 才是最后實(shí)

3、際的， 就會在新項(xiàng)目評估時(shí) （無條件乘以 2） ，這些時(shí)間總會被用戶有辦法用掉， （說到這里，自己很可恥一下，開發(fā)過程中很多時(shí)間都不知道去哪里了， 比如用戶說按鈕上怎么沒有圖片啊，之類的，或者說放左邊好看啊，這些時(shí)間就沒了，每次都不可預(yù)知，或者服務(wù)器上裝個(gè)什么軟件，不知道又出什么問題，有幾天不開心，效率低下等等）雖然一直按以上這種方式做，但是總覺得不是很好，主要有以下幾個(gè)方面1 、準(zhǔn)確性差，從上可以看到，準(zhǔn)確率只有50%左右2 、難以解釋，說這個(gè)頁面為什么要這么久，這個(gè)功能為什么這么久，完全是憑著腦子里過一下，有幾個(gè)按鈕，大概寫多少代碼的一個(gè)感覺，經(jīng)不起推敲3 、評估工作量和實(shí)際設(shè)計(jì)完成后的很

4、難對應(yīng)上，通過設(shè)計(jì)后，可能有些部分為了通用超出想象得工作量， 有些部分公用了， 又減少了。很難理解，到底真正準(zhǔn)確率高的工作量評估是怎么做的。在我看來，設(shè)計(jì)完成后，工作量才能準(zhǔn)確評估。但是為什么工作量評估總是要在前期需求剛剛了解一部分就要出。 這是為什么呢， 怎 么做呢？特別值得一提的是，根據(jù)大概會產(chǎn)生多少代碼行進(jìn)行評估，我特別難以理解，有人能聽客戶說了一天需求，就大概估算出代碼行數(shù)，真是神人啊。歡迎告訴我您的工作量評估方法，讓我也學(xué)習(xí)一下。1. 根據(jù)測試范圍和測試方法來估計(jì)工作量：a ）制定測試計(jì)劃以前，明確測試范圍：不同的測試范圍，對測試量的評估起到至關(guān)重要的因素，比如說測試一個(gè)模塊或測試多

5、個(gè)模塊或測試整個(gè)系統(tǒng)等等， 都屬于測試范圍不一樣，明顯工作量也不同，差別也挺大的。還有測試范圍還包括功能性測試范圍或非功能性測試范圍等等， 在做測試工作量評估的時(shí)候，都必須考慮。b ）確定合理、有效的測試方法：比如說你要考慮測試某個(gè)項(xiàng)目， 你必須考慮測試方法是否合理。比如說某個(gè)模塊的功能測試，你可以采用QTP故自動(dòng)化功能測試，還是手工做功能測試， 工作量就不一樣， 做測試計(jì)劃以前必須考慮清楚。要不然，估算的工作量肯定不準(zhǔn)。2. 根據(jù)測試任務(wù)來評估工作量：a ）質(zhì)量需求和項(xiàng)目背景決定工作量：不同的項(xiàng)目背景，不同的質(zhì)量要求，決定不同的測試工作量。如果我們測試的是一個(gè)銀行系統(tǒng)， 涉及到每個(gè)人的經(jīng)濟(jì)利

6、益， 我們測試時(shí)必然會對性能測試或安全測試放到第一位， 設(shè)計(jì)較多的異常測試用例，這樣一做，必然增加我們的工作量。如果是一般的系統(tǒng)，我們可以只執(zhí)行一般的功能測試通過就可以了， 沒有必要去做其他的異常、安全測試。 如果系統(tǒng)的質(zhì)量需求要求高， 也許就要進(jìn)行更深層次的測試，回歸測試的力度必然要加大，工作量自然就上去了。b ）盡可能詳細(xì)的羅列出項(xiàng)目測試內(nèi)容：一般來說，測試工作量的評估工作都是交給測試經(jīng)理或項(xiàng)目組成員協(xié)助共同來完成的。 準(zhǔn)確評估項(xiàng)目測試的工作量， 必須要求測試Leader 明確詳細(xì)的測試內(nèi)容，只有知道測試什么？哪些需要測試？詳細(xì)分析需求規(guī)格說明書，明確測試任務(wù)以后，評估才會有依據(jù)，所以盡可

7、能詳細(xì)的羅列出項(xiàng)目測試內(nèi)容非常必要。c ）把測試任務(wù)細(xì)化到每個(gè)測試功能點(diǎn)：我們在估算測試時(shí)間的時(shí)候，可以把測試任務(wù)細(xì)化到每個(gè)測試的功能點(diǎn)，比如說“新增”、“修改”、“刪除”、“暫停”、“恢復(fù)”等等都記成一個(gè)功能點(diǎn)，在預(yù)算的時(shí)候，同時(shí)把編寫測試用例和執(zhí)行測試用例的時(shí)間都要計(jì)算進(jìn)去。 例如： 編寫一個(gè)測試用例或執(zhí)行一個(gè)功能測試各需要一個(gè)小時(shí)， 如果我們有100 個(gè)功能點(diǎn)， 我們就知道大約要 200 個(gè)小時(shí)。 這樣估算出來的時(shí)間比較精確一點(diǎn)， 比較符合 實(shí)際。d ）預(yù)估業(yè)務(wù)測試或模塊交叉測試的復(fù)雜容易程度：很多時(shí)候，我們測試初期，對業(yè)務(wù)了解不是很多，忽視了對業(yè)務(wù)方面或交叉模塊測試的評估， 等到了測試

8、后期， 大量的業(yè)務(wù)測試沒有測試， 測試時(shí)間特別緊， 所以在測試初期預(yù)估測試的復(fù)雜容易程度，在評估工作量方面至關(guān)重要。3. 根據(jù)開發(fā)階段來評估工作量：不同的開發(fā)階段，測試時(shí)間估算也不太相同。比如說，開發(fā)的系統(tǒng)是第一個(gè)版本， 相對以后的測試工作來說， 可能安排的時(shí)間要多一點(diǎn)。大多數(shù)情況下是這樣的，也許后面的版本增加很多新功能，測試工作量還大于第一個(gè)版本也是常有的事情。 作為測試負(fù)責(zé)人， 對于使用測試階段來評估工作量， 必須根據(jù)實(shí)際情況來定， 不能盲目給出數(shù)字，應(yīng)付了事。4. 根據(jù)測試經(jīng)驗(yàn)的積累來評估工作量：我們可以借鑒類似項(xiàng)目的測試經(jīng)驗(yàn)，比如說被測試的系統(tǒng)，我們做過類似的產(chǎn)品，就可以把相關(guān)的測試文

9、檔，修改一下，復(fù)用以前的測試用例，這時(shí)候測試工作量就減少了很多。如果沒有，我們只能重來。 還有就是借鑒以前項(xiàng)目編寫測試用例或執(zhí)行測試的時(shí)間， 對測試工作量的準(zhǔn)確評估，也具有一定的參考價(jià)值。5. 根據(jù)測試風(fēng)險(xiǎn)來評估工作量：a ）測試人員變動(dòng)帶來的風(fēng)險(xiǎn)：在一般的軟件公司，測試人員的流動(dòng)是常有的事情，所以估計(jì)測試工作量的時(shí)候，我們一定要把它計(jì)算在里面，留有一定的余地，以防不測。比如說：以前安排了一個(gè)做過類似項(xiàng)目，對類似項(xiàng)目熟悉的測試人員，也許給他安排了一天的工作量。如果他不在了，其它的人去做這個(gè)測試也許就 2 天，甚至3、5 天都不一定能夠搞定。測試人員帶了的風(fēng)險(xiǎn)還是特別高的。b ）系統(tǒng)測試環(huán)境的風(fēng)險(xiǎn)：系統(tǒng)測試環(huán)境帶來的風(fēng)險(xiǎn)，一般來說比較小，發(fā)生的可能性很小，如果一旦發(fā)生了，也相當(dāng)可怕。最可怕的就是硬件故障，在經(jīng)濟(jì)實(shí)力允許的情況下， 我們一般的方法是準(zhǔn)備兩套測試環(huán)境， 一套測試環(huán)境出現(xiàn)問題， 我們立馬切換到另外一個(gè)測試環(huán)境中去繼續(xù)測試， 避免影響正常的測試進(jìn)度。 但是大部分的公司都不愿意花血本， 來購買昂貴的硬件，而是以犧牲時(shí)間來付出代價(jià)。c ）、開發(fā)人員版本發(fā)布延遲風(fēng)險(xiǎn)：不做好版本配置管理或沒有正規(guī)的測試規(guī)范的公司，大部分情況下很難估計(jì)工作量， 他們基本上都是邊改邊開發(fā)邊測試， 如果一旦開發(fā)出現(xiàn)異常， 整個(gè)測試就立馬終止， 這對測試的相互制約作用也會更大，這樣對我們估算的工作量