軟體專案量化管理方法

kitesky發表於2009-12-21
摘要:本文在對企業量化管理應用常見問題分析的基礎上,以解決可操作性、可比性等問題為著眼點,識別出了量化管理中必須明確的四要素,表述了企業在量化四要素上採用的常見做法。
本文采用80/20原則,說明了企業在識別
時應避免的問題;採用持續改進的理論,說明了企業在量化管理應遵循的客觀規律。在結合平衡記分卡與目標驅動組合式的量化管理方法理論基礎上,提出了軟體企業的量化管理的具體應用步驟。
關鍵詞:量化管理 四要素 80/20原則 持續改進 GQ(I)M
[@more@]1. 引言

如今,很多國內軟體企業選擇採用能力成熟度系列 模型(Capability Maturity Model,
)或其它模型來建立本企業的規範,欲透過提升軟體過程的能力達到提高產品、降低風險、減少開發成本、保證產品按時交付等目的。將軟體過程規範的一個目的就是使軟體過程視覺化,這個視覺化則要求了對軟體過程的量化;而產品質量是否提高、開發風險是否降低、開發成本是否減少、專案延期是否縮短,對這些問題的回答則要求了對軟體專案的量化;與量化管理息息相關。

不少企業在將識別出的量化管理方法應用於
過程時,發現不少問題。最為常見的是:
量化工作的可操作性不強,如:部分量化資料難以收集、難以統計投入的成本沒有得到預期的產出。如:量化工作投入了成本,但形成的量化結果參考價值不高提供給管理層用於決策的支援資料也不夠,資料缺乏可比性量化結果不是管理層所關心的,達不到管理層預期的過程視覺化程度
針對此
問題,本文識別出了在量化管理中必須要考慮的四個方面,即:量化四要素,並從量化四要素對量化管理方法進行了分析,建議了軟體企業採用的量化管理方法。

2. 量化四要素

“只有透過對產品、過程的度量,才能描述、評價、提高產品與過程”。
筆者認為,要度量,就要明確度量的物件;要度量物件,就要明確標識度量物件的計量單位;要產生度量結果,就要明確度量方法,包括度量技術和資料收集的方法;要評價度量物件,就要明確用於比對的基準指標,即表徵度量物件目前情況的標尺,透過該標尺與度量結果的比對,得出對度量物件的評價。而度量物件(
)、計量單位(Unit)、度量方法(Method)、基準指標(Benchmark),這就是筆者所說的量化四要素。

我們先看看目前軟體企業在量化四要素上的常見做法:
(1) 度量物件
往往軟體企業在識別度量物件時,是根據所採用的模型或標準中提出的相關要示去做的,比如:
綜合
(Capability Maturity Model Integration, )等級2中建議的量化目標[2]:
估計產品規模和實際規模
預算成本和實際成本
進度情況
率、與驗收覆蓋率和同行評審覆蓋率
質量要求和質量度量
有些軟體企業量化了識別出的各軟體過程,建立了各過程的改進度量物件。可能有的企業識別出的度量物件更多。
(2) 計量單位
針對同一個目標,不同軟體企業採用的計量單位也不盡相同。簡單來講,分為面向規模、面向功能的度量。
以軟體規模的計量單位為例,常見的面向規模的有:程式碼行(lines of code,LOC)、人/月;面向功能的有:功能點、特徵點(feature point)、物件點(object point)、3-D功能點(3-D function points)、標準
法(standard )等。
有的企業並非單純地採取一種
的計量單位,在某些目標上他們可能採用的是面向規模的計量單位,在另外的目標採用的又是面向功能的計量單位。
此外,對於軟體質量的計量單位,有的企業可能就是用缺陷率來表徵軟體質量;有的企業可能將軟體質量拆分成若干個子量化目標,對這些子目標再明確其計量單位。
(3) 度量技術
目前軟體企業常用的度量技術,如掙值法、控制圖、直方圖、散佈圖等。專案中用於的技術有典型的估算方法,如
法和類比法。
l 直方圖
它是表示資料變化情況的一種主要工具,用於整理度量值的觀測資料,分析其分佈狀態的統計方法,用於對總體的分佈特徵進行推斷。
掙值法
掙值法是一種分析比較出目標實施與目標期望之間差異的方法,用於專案過程中的進度與費用分析。
它透過測量和已完成的工作的預算費用與已完成工作的實際費用和計劃工作的預算費用得到有關計劃實施的進度和費用偏差,而達到判斷專案預算和進度計劃執行情況的目的[3]。
控制圖(

它是一種控制界限的圖,用來區分引起質量波動的原因是偶然的還是系統的,可以提供系統原因存在的資訊,從而判斷生成過程是否處於受控狀態。
按其用途可發為兩類,一類是供分析用的控制圖,用於分析生成過程的有關質量特性的變化情況,看工序是否處於穩定受控狀態;再一類是供管理用的控制圖,主要用於發現生產過程中是否出現了異常情況,以預防產生不合格品。
6 Sigma的統計分析技術就需要採用SPC度量方法。
Delphi法
Delphi法是最流行的專家評估技術,在沒有歷史資料的情況下,這種方式可以減輕估算的偏差。Delphi法鼓勵參加者就問題相互討論。這個技術,要求有多種相關經驗人的參與,互相說服對方。
類比法
類比法適合評估一些與歷史專案在應用領域、環境和複雜度的相似的專案,透過新專案與歷史專案的比較得到估計資料。類比法估計結果的精確度取決於歷史專案資料的完整性和準確度。
針對專案工期估計,常採用計劃評估技術(Program Evaluation an Review Technique,PERT)進行估算。
針對專案成本估計,較好的方法有經驗估演算法、因素估演算法和WBS基礎上的全面詳細估演算法等多種方法。
(4) 基準指標
不少企業建立了基準指標,也有不少企業忽略了基準指標的建立。
為建立基準指標,建議採用如下步驟:
建立度量庫
收集歷史專案資料
量化歷史專案
建立各項基準指標

3. 量化管理方法

透過以上描述,不難看到,若軟體企業對識別出的所有度量物件都要在專案中去收集、去度量、去分析,無疑需要分配不少的資源、投入時間與成本。
筆者認為:在軟體企業識別出的大量需要度量的物件中,企業目前所真正關注的、而且識別出來能提高軟體過程改進的重要物件往往只佔20%,即 “80/20原則”:即百分之八十的量化結果價值是來自百分之二十的度量物件的收集與分析工作,其餘的百分之二十的價值則來自剩餘百分之八十的量化工作。所以,如何把有效的人力物力投入到這20%的目標中,採用恰當的量化管理方法是非常重要的。
此外,計量單位、度量技術的不恰當選用也是導致工作量增加、可操作性降低的原因。以程式碼行這種計量單位為例,若企業缺乏相應的資源與相應度量工具的支援,其度量結果的準確程度與可信度就會大打折扣。
即使有了較為準確的度量結果,若企業缺乏基準指標,則難以評價度量物件,難以完成各專案的比對;缺乏基準指標的度量結果提交給管理層,管理層仍然很難透過提供的資料做出決策。
Wolfhart Goethert和Matt Fisher在集合了目標驅動式量化管理GQ(I)M和基於平衡記分卡BSC量化管理的基礎上,提出了新的管理方法:BSC與目標驅動組合式的量化管理方法[4]。


我們將這種方法具體應用到軟體企業的量化管理,結合量化四要素,結合持續改進的管理思想,筆者認為應遵循的步驟如下:
(1) 應先明確軟體過程中的量化工作,該過程採用的:
明確企業的經營目標,弄清楚企業想知道什麼
從財務、客戶滿意、內部流程、學習和創新四個方面確定軟體量化過程的子目標
根據識別出的子目標,確定可量化的問題和指標
確定過程中的度量物件、計量單位、度量方法和基準指標
確定軟體專案中應度量物件、計量單位、度量方法和基準指標
建立歷史專案的度量庫
(2) 延伸至軟體專案時,可按如下過程具體化軟體專案的量化工作:
確實業務目標、軟體過程目標(在軟體過程的量化工作中獲得),結合兩者,形成本專案的目標
從財務、客戶滿意、內部流程、學習和創新四個方面確定軟體專案的子目標
根據認別出的子目標,確定可量化的問題和指標
結合軟體過程中確定的度量物件、計量單位、度量方法和基準指標,制定本軟體專案的度量物件、計量單位、度量方法和期望達到的基準指標(該專案的可以建立自己的基準指標)
制定度量計劃
(3) 透過實際試用,及時糾正度量物件、計量單位、度量方法和基準指標中存在的不合理的因素,以保證量化管理過程的有效性
(4) 持續改進:企業應基於自身的實際能力成熟度,建立適宜本企業的量化管理方法。隨著企業管理需求、能力成熟度的提高,透過量化過程、軟體專案中的資料收集、統計分析,持續改進量化管理方法的有效性。

4. 結論

透過度量庫建設環節,能讓管理層清晰瞭解企業目前狀態,管理層的目標期望不至於太脫離企業目前的能力;採用這種量化管理方法,也能夠保證軟體專案的目標與企業目標一致,找出需要量化的關鍵物件和基準指標。同樣,由於事先明確了計量單位和度量方法,可操作性得到了提高。此外,由於軟體專案的量化管理都是基於軟體過程的量化管理基礎上,就容易為企業建立一個統一的基線指標,容易將不同的專案進行比對。

另外,企業的目標是在不斷調整與持續改進的,量化管理要求也在不斷變化,量化管理水平將隨著企業成熟度的提高而提高。量化四要素也應在保持階段性穩定的基礎上根據企業所處的不同階段進行調整,也應隨著企業成熟度的提高而逐步改進、逐漸細化、精確。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/66009/viewspace-1029850/,如需轉載,請註明出處,否則將追究法律責任。

相關文章