每個軟件公司都可以并且應(yīng)該做好的度量——缺陷度量
就算一個開發(fā)極不規(guī)范公司，我想總會對缺陷有一定的管理辦法吧？至少缺陷會被記錄下來（哪怕是各種方式），而不會只是口頭說而毫無記錄吧？
大多數(shù)軟件公司都會有一套管理缺陷的系統(tǒng)，我們應(yīng)該如何把缺陷度量做得更好呢？
我們需要目標驅(qū)動地把度量工作做好，首先有兩個最基本的要求：
1.缺陷被準確的記錄和跟蹤。
2.客觀地依據(jù)缺陷狀況對軟件發(fā)布進行決策。
根據(jù)這兩個要求，我們需要詳細定義缺陷的屬性，這些缺陷的屬性就是我們要度量的內(nèi)容。很多公司都會定義缺陷的描述、嚴重程度等屬性，另外也會規(guī)定發(fā)布的時候，什么嚴重級別的缺陷不能超過多少個等要求。
以上兩個目標只是缺陷度量的兩個基本目標，如果更深入一點，我們希望能預防缺陷的再次發(fā)生，最簡單有效的辦法就是：直接讓項目組成員一起來分析缺陷的原因，讓大家避免重犯。
如果想做更系統(tǒng)更深入的分析，就需要考慮在組織層面來做這個分析工作。這時有必要增加缺陷一個屬性，叫做“缺陷來源”，就是說產(chǎn)生這個缺陷的源頭是在哪里，是需求沒有分析到位，還是設(shè)計沒有做好，還是編碼出問題？按“缺陷來源”來分析公司不同類型的項目的缺陷情況，您就會發(fā)現(xiàn)公司的軟件開發(fā)過程最有問題的是哪個過程？哪些過程做得比較好？這些分析結(jié)果會很好的指引過程改進的方向。
缺陷度量有很多可以發(fā)掘的地方，這是每一個公司都應(yīng)該做好也是最有條件做好的一種度量。
成功的基礎(chǔ)——軟件規(guī)模度量
最近有這樣的一個辯論，功能點VS代碼行，辯論的焦點就是用哪一種來代表軟件規(guī)模更好一點。項目規(guī)模的度量大有學問，如果您想去聽聽專業(yè)的軟件功能點法課程，您可能要付上高昂的學費，并且有可能學了后還不知道如何用上這個辦法。這里我不想談?wù)撨@兩種辦法，這些方法可能僅是理論上可行，目前我也沒有見到過一個成功實踐這類方法的案例。
我們?yōu)槭裁匆M行軟件規(guī)模度量呢？目的無非是：
1.作為報價或者決策的依據(jù)。
2.安排具體的項目進度。
3.可以作為組織的生產(chǎn)力數(shù)據(jù)，可以有很多用途，如：各項目間橫向比較，供以后項目參考等。
如果是為了投標報價，建議用Delphi法，功能點法、代碼行法太慢了，不能適應(yīng)商戰(zhàn)社會，投標經(jīng)常是沒有這么多時間讓你去折騰的。Delphi法的大致方法如下：
1.找?guī)酌Y深專家，一起對項目進行WBS，把項目的工作分解為十幾條最多二三十條的工作項。
2.全部專家各自估計每條工作項的工作量，并向其他專家闡述自己的理由。
3.第一次各專家估出來的結(jié)果可能差異比較大，每位專家聽取別人的意見后，重新估算。
4.按照上述辦法，各專家反復估算幾次，一般次數(shù)就是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。
如果是為了目標2，安排具體的項目進度，我建議用“傻瓜估算法”，而我們親愛的微軟，就是采用這樣的方法來估算規(guī)模的。這樣的辦法雖然原始，但有效，并且容易掌握。雖然這種辦法被扣上主觀成分大、項目間難以橫向?qū)Ρ鹊?、難以積累歷史數(shù)據(jù)等多種“罪狀”，但不好意思，用功能點法或者代碼行法就很準嗎？我們親愛的軟件工程師們認可功能點法或者代碼行法嗎？搞功能點法代碼行法等這些“虛”辦法，還不如老老實實地WBS，直接估算每個工作的工作量。
第一步：把公司內(nèi)部最有項目經(jīng)驗最有估算經(jīng)驗的工程們召集在一起，制訂組織級別的估算表框架。
軟件開發(fā)活動，可以分類以下幾類：
l 直接生產(chǎn)軟件的活動，如：需求開發(fā)、設(shè)計、編碼、測試等工程類活動。
l 項目管理類活動，如：編寫項目計劃、計劃跟蹤、發(fā)布評審等活動。
l 項目支持類活動