用例設計在軟體開發專案績效考核中的應用

前言
沒有比較就沒有考核。績效考核的根本目的就是透過考核等管理手段促進績效的提高，要怎樣才能知道績效提高了呢？一定要有比較！因此，我們要使用一個指標體系來算出這個績效的資料。本文介紹的績效考核方法可以使：
1.　各個專案之間有著客觀一致的績效考核標準
2.　專案組內各成員的之間有著客觀一致的績效考核標準
3.　員工可以計算自己的績效考核結果

例項
一般軟體公司是這樣進行績效考核的：
1.　按專案開發的階段劃分專案，並制定相關的計劃
2.　在月初，雙方確認這個月要完成的計劃內容
3.　在月末，對這些計劃內容的完成情況進行評分
4.　依據評分的結果考慮是否加或扣當月工資
如：
被考核人：XXX　　考核人：XXX　　　考核月份：2006-3　　製表時間：2006-3-6
-------------------------------------------------------------------
計劃內容　　　　　　　　　　權重　　預計完成　　實際完成　　評估分數
-------------------------------------------------------------------
完成A網站的需求、開發、測試 20　　　25　　　　　30　　　　　80
完成B應用系統的需求　　　　 30　　　15　　　　　20　　　　　80
完成C　應用系統的上線　　　 50　　　20　　　　　10　　　　　100
-------------------------------------------------------------------
合計　　　　　　　　　　　　100　　　　　　　　　　　　　　 90

問題
我們看看上面這張考核表，不難發現：
1.　多個專案之間的評分標準不一致，不同專案的團隊成員易產生對考核結果不滿的情緒，有以下幾個原因：
a)　計劃內容本身的界限是不清晰的
b)　不同專案的階段所需求工作量不相同，或者很難找到它們之間的可計算
2.　單個專案中的各成員之間的評分標準不一致，團隊成員易產生對考核結果不滿的情緒
3.　評分沒有客觀依據，過於主觀，不能令人信服
4.　員工在不能預見自己的績效考核結果，找不到提高評分的辦法
5.　看不到不同時間考核結果的差異，對員工的績效提高沒有實質性的幫助

實際過程
瞭解RUP(rational　unified　process)　的朋友，知道軟體開發過程並不是我們想象的如此簡單。它告訴我們在同一個時間內所有的開發階段是有可能共存的。也是說整個開發過程可以是多個迭代同時進行。
讓我們回顧一下日常的開發過程：
1.　得知有一個專案需要開發。有可能是老闆告訴你的，也可能是業務部門告訴你的，總之我們要為它而工作了，同時確信老闆同意開始這個專案
2.　對這個專案涉及的人員及其需求進行調查。這裡的需求包括了所有專案的需求，比如老闆對這個專案的要求及期望，使用者對這個專案的期望，開發人員對這個專案的期望。這時，我們很快會發現，調查所有人是不可能的，調查所有需求也是不可能的。因此，
1)　我們會先找幾個關鍵人物，瞭解他們的期望，確定系統的邊界（或叫輪廓，XP(Extreme　Programming)中把它叫系統隱喻）；
2)　再把系統劃分為幾個部分，確定先做哪個部分後做哪個部分；
3)　再一個一個部分對需求進行調查
當我們在調查的時候，常常會發現新的部分之間的關聯，這使我們不得不對這兩個部分的內容進行檢查，加的加，改的改，刪的刪。
3.　基於調查的結果進行設計。這個時間，我們經過對這些需求的分析、歸類，設計一個開發的模型以支援這些需求。設計時也免不了會發現需求不對的地方，對需求進行加的加，改的改，刪的刪。
4.　基於設計的結果進行編碼、整合。也免不了會發現設計、需求不對的地方，對需求進行加的加，改的改，刪的刪。
5.　基於編碼的結果進行測試，以驗證軟體是否達到了需求。我們常常發現這時的需求與設計之前的需求已有了很大的變化。
6.　釋出（部署）產品，進行專案收尾。
如果某一時間，客戶要知道專案進行到哪了，我們告訴他設計已完成，正進行編碼工作。當有需求變更時，相關的需求、設計又要來過。客戶能不懷疑我們的回答麼？
做過軟體開發的人就會知道，上面的過程描述中有很大的問題。我們的做過程並沒有錯，一個一個需求，一個一個功能的實現，有變更時就一個一個變更的實現，大家都這樣做，也只有這樣做。對於一個應用軟體專案來講，而不太可能真正的按軟體書上寫的過程一個一個過程的做下去，集中10天做完所有的需求，集中20天內做完所有設計。
做的過程沒有錯，把過程描述出來，為什麼就錯了？原因很簡單：我們在描述時，總喜歡套用一些"模式"，一些書寫的"方法"，而不是按實際的過程描述。如果我們不套用任何模式，將會如何呢？我們再來描述一遍上面的過程：
1.　瞭解軟體專案的故事（story）。開始一個軟體應用專案，瞭解關鍵人物都有哪些？他們要求是一個什麼樣的系統？把這些要求描述成一個一個的故事，如果稍稍規範一點。就會象這樣：
1)　這個系統的目標是為了誰解決什麼問題
2)　第一步做什麼，系統反饋什麼
3)　第二步做什麼，系統反饋什麼
4)　…
5)　問題解決了，結束本故事
我們會仔細的看這些故事，發現有些地方看不懂，於是我們就去問清楚，有些事情是那個描述故事的A也不清楚的，但A告訴我們B會懂，於是我就問B；有些事情A也不知道有誰會知道，我們就把它放在一邊，等知道的時候再問，繼續看其他的故事。
2.　瞭解系統隱喻，構造軟體框架。永遠也問不清楚所有的事情，所以當我們知道整個系統的是為了解決什麼問題，將用什麼辦法來解決它（暫時叫做系統隱喻），關鍵人物也認可時，我們就不再問下去了。我們依據這個系統隱喻去構造一個最上面的故事。然後，只關心與這個故事有關的故事。同時構造一個程式框架以支援專案的開發
3.　實現故事。在軟體框架上，實現一個故事，再實現一個故事，…
4.　實現變更。有時發現事情並沒有想象的簡單，於是就變更它，這就要求我們實現這些次變更。它象實現故事一樣：實現一次變更，再實現一次變更，…
5.　部署軟體。感覺軟體已達到了可被接受的預想或合適的要求了，就釋出這個軟體。
上面所說的故事就是我們常說的用例（use　case）。我們可以使用用例的形式來描述整個系統的計劃內容，並計算它的工作量，為工作之間、專案之間的績效提供一個統一的衡量標準。
這時，我們發現：
1.　由故事（有些專案可以用故事所包含的步驟）的數量可計算出開發的工作量
2.　我們實際開發工作過程的時間、成本、進度是可以被不瞭解專案實現技術的人所感知的
如果我們仔細檢視專案的所有工作，會發現有些工作不是基於某個用例的，也與某些用例沒有直接關係，如何拿用例來計算它的工作量呢？在專案的開發中確定存在這些工作，如專案開始時的"瞭解軟體專案的故事"。但透過分析知道，在一個軟體專案中頂層用例的數量是不難預測的，也是說在這個時期要向關鍵人瞭解的用例數是可以預測的。我們不難發現，要了解的用例數越多，需求瞭解的工作量就越大。在相同型別的應用軟體開發中，需求瞭解的工作量與用例數量的比例是基本一致的。同理，瞭解系統隱喻，構造軟體框架、部署軟體的工作量與用例的量也是成比例的。
在沒有不熟習技術的前提下，根據本人的經驗，同類軟體專案的工期與底層用例數（更多資訊請參考"）或步驟數有著可計算的關係，如WEB應用軟體中，一個底層故事的開發時間大約為1.5個人日。這個是經驗資料，在不同的公司可能有所不同。網上也有文章證明不同規模的應用軟體，故事與程式程式碼的行數有一定的計算關係。這樣我們的不同專案，或同一專案的不同故事之間，在時間、成本、進度上就具有了可比性。
同時，我們發現專案的進度、成本的估算可以透過簡易的公式進行一次性計算得到

解決方法
可以使用用例（use　case）來計算專案的進度、成本，如果使用這個計算結果作為考核的依據的評分標準，將可以很好的完成績效考核。它的作法是：
1.　對要做的專案進度評估，確定其可能擁有的用例數，並用這個用例數計算進度、成本的要求，從而確定計劃內容
2.　在月初，雙方確認這個月要完成的計劃內容
3.　在月末，對這些計劃內容的完成情況進行評分
4.　依據評分的結果考慮是否加或扣當月工資
如：
被考核人：XXX　　考核人：XXX　　　考核月份：2006-3　　製表時間：2006-3-6
-------------------------------------------------------------------
計劃內容　　　　　　　　　　　　權重　　預計完成　　實際完成　　評估分數
-------------------------------------------------------------------
完成A網站的使用者模組、首頁面模組 30　　　10　　　　　10　　　　　100
完成B應用系統的使用者模組　　　　 20　　　20　　　　　20　　　　　100
完成C　應用系統的轉帳模組　　　 50　　　30　　　　　25　　　　　200
-------------------------------------------------------------------
合計　　　　　　　　　　　　　　100　　　　　　　　　　　　　　 150

　　由於這種方法使用了與具體專案的特性、過程無關的評分標準，所以可以保證本績效考核方法可以達到以下幾個目標：
1.　使各個專案之間有著客觀一致的績效考核標準
2.　使專案組內各成員的之間有著客觀一致的績效考核標準
3.　使員工可以計算自己的績效考核結果[@more@]

用例設計在軟體開發專案績效考核中的應用（轉）

相關文章