員工工作量評估范文

1、員工工作量評估范文今天剛剛進(jìn)展了一個(gè)小軟件的工作量評估，總是覺得評估的不夠準(zhǔn) 確，而且難以明確，把心中的困擾跟實(shí)際所使用的做法簡單說說， 工作量評估中，困擾我的問題主要有以下幾個(gè)1、需求不清晰，并且會(huì)有變化2、工作量評估在需求規(guī)格說明編寫的同時(shí)就需要進(jìn)展，一般來說， 沒有立項(xiàng)，就還不會(huì)做詳細(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)隊(duì)

2、雖然也了解過各種工作量評估方法，但是實(shí)際中總感覺難以使用 （應(yīng)該是不會(huì)使用）自己的做法如下：1、確定有多少模塊，每個(gè)模塊下有多少頁面，針對每個(gè)模塊列出需 求、設(shè)計(jì)、開發(fā)、測試、部署時(shí)間，組成這一模塊的時(shí)間2、需要多少個(gè)公共的類，分別有多復(fù)雜3、加上工程管理時(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í)際的，就會(huì)

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

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

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

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

7、試內(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í)間比較準(zhǔn)確 一點(diǎn)，比較符合實(shí)際。d）預(yù)估業(yè)務(wù)測試或模塊穿插測試的復(fù)雜容易程度：很多時(shí)候，我們測試初期，對業(yè)務(wù)了解不是很多，無視了對業(yè) 務(wù)方面或穿插模塊測試的評估，等到了測試后期，大量的業(yè)務(wù)測試 沒有測試

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

9、試工作量就減少了很多。如果沒有，我們 只能重來。還有就是借鑒以前工程編寫測試用例或執(zhí)行測試的時(shí) 間，對測試工作量的準(zhǔn)確評估，也具有一定的參考價(jià)值。根據(jù)測試風(fēng)險(xiǎn)來評估工作量：a）測試人員變動(dòng)帶來的風(fēng)險(xiǎn)：在一般的軟件公司，測試人員的流動(dòng)是常有的事情，所以估計(jì) 測試工作量的時(shí)候，我們一定要把它計(jì)算在里面，留有一定的余 地，以防不測。比方說：以前安排了一個(gè)做過類似工程，對類似工 程熟悉的測試人員，也許給他安排了一天的工作量。如果他不在 了，其它的人去做這個(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ēng)險(xiǎn)：不做好版本配置管理或沒有正規(guī)的測試標(biāo)準(zhǔn)的公司，大部分情 況下很難估計(jì)工作量，他們根本上都是邊改邊開發(fā)邊測試，如果一 旦開發(fā)出現(xiàn)異常，整個(gè)測試就立馬終止，這對測試的相互制約作用 也會(huì)更大，這樣對我們估算的工作量也不