國內專案中可以採用的軟體工程手段 (轉)

國內專案中可以採用的軟體工程手段 (轉)[@more@] 

為更好地開發，必須在專案組中引入一些軟體工程手段和方法。本文試討論了無論公司情況如何，一個專案經理都應該可以在專案組中實行的一些手段和方法；當然，公司情況良好則有更加可行的、更多的方法可以選擇；這裡只討論了最差情況下可以採用的方法。

本文按照最簡單的瀑布的各個階段分別列舉了一些方法，在其他模式中應該也可以採用。

需求的管理應該是貫穿整個開發過程。在這個階段，可以採用的方法有：

變更控制委員會)

建立CCB（change control board）是需求管理的前提，否則需求管理將成為一句空話。

CCB必須包含客戶方的決策人士，專案經理，專案經理的領導，關鍵設計人員，測試負責人，SQA.等，以5-7人左右為宜。

需求確認，發生變更等活動必須由CCB以會議形式批准。

CCB對整個專案有最高權力（不僅負責需求變更，還負責聽取專案經理彙報、關鍵中間工作產品評審等重要決策）

原始需求必須形成文件，被CCB評審，然後納入基線管理，所有變更都需要CCB評審。

該評審一般步驟：

1.  專案經理提出被評審，指出受影響、被牽涉物件，評估影響（主要是帶來的規模、工作量、成本），提出計劃和計劃人，舉出可能風險；

2.  CCB來決定是否同意或要求專案經理修改上述項；

3.  之後，專案經理提交執行情況彙報。

4.  最後，CCB指定代表或由SQA進行核實。

如果變更過小，過多，可以進行周彙總評審。

專案計劃是開發的指導或指令碼，事實上，在每一個階段開始時，都應該重新、小範圍修訂一下計劃。

生命週期

關於生命週期的選擇上，一直有而且會有很多爭議。目前，國內運用最多的是純瀑布生命週期；本人的看法是：一定有更好的選擇，但這是一個最、最少在實際中有爭議的選擇。

選擇合適的生命週期的要點是：一定要有選擇原因的陳述—本專案的特點，團隊特點，開發特點和公司或部門的特點；該問題必須事先在專案組中、CCB內被討論過並得到一定認可。

小里程碑

根據選定的生命週期模型，考慮到可以投入的人員，各個開發階段就呼之欲出了。每個階段的結束一定是一個里程碑。如果里程碑超過一個月，那麼應該在每經過一個月左右選擇合適的點作為小里程碑。

每達到一個里程碑時，專案經理應該提交本階段工作報告，一般應該包括：

1.  本階段活動統計和估計的數值和它們差異的原因

2.  工作產品完成情況

3.  需求變更情況統計

4.  問題及其解決情況的統計

5.  總結優點和缺點，指出對下一步工作的影響

CCB聽取該報告並評價該階段工作。

小里程碑可以防止專案失控，使專案經理、專案組和其上的管理層能夠正確認識到專案進展情況，並能協助專案開展、出謀劃策，專案視覺化好；避免專案發生大問題。

在最混亂的專案中，工作產品和中間工作產品都沒有被明確定義，或者可以朝令夕改，隨意新增或去除產品。決定工作產品和中間工作產品，是為了確定各個產品的重要性，計算其上的工作量以合理地投入足夠的、合適人員來開發它。

一般是將分解成模組甚至更細，要分多細由專案經理或分析員根據實際對專案產品的認識和人力、進度的壓力而定；一個忠告：開始做的細、做的認真，以後的工作都會相應容易很多。

一般人只分解產品。實際上，管理工作也應該分解的，而且也比較容易作。

估計常常被忽略掉，因為估計的結果往往會嚴重超出預算，讓人大吃一驚。而到了最後，結果又往往接近當初估計的數字。

估計應該每個階段作為計劃的一部分進行一次，每個新的估計都會更加準確。

估計應該選取有的人士參與，應該選擇合適的方法

估計的結果應該用於指導編制下一階段的計劃，即使不被正式接受，專案組也不應該忘記這些數字，時刻作為參照。

團隊建設

根據專案特點和人員特點，應該選擇合適的模式來組建團隊進行開發，每個人都應該有明確的責任和工作。

最低限度，每個人都應該有明確的責任和工作。

建立溝通渠道這一條可以不成文，但要成規矩。溝通渠道應該開放，暢通。為每個人指定彙報的領導、彙報的週期、彙報的方式和越級彙報的領導、條件和方式。

建議在專案中開展專案日誌，週報制度，具體的方式方法可以參考PSP,TSP。該制度的要點是：日誌首先是對自己負責，不能作為評價員工的依據，它是屬於成員“開放的“。如果要求每天填滿8小時工作，這樣的日誌沒有任何意義；事實上，在本人的專案組中，根據日誌，一般沒有人每週投入工作的時間超過35小時，平均只有28小時左右—當然，你依然可以看到他們每天都很忙碌的樣子，有時還有加班呢。

周例會制度是本文推薦最有可行性的軟體開發管理手段。每週用1-1.5小時左右，每個人簡要彙報本週工作和下週計劃的工作，工作中的問題和難點，這時，他會得到整個專案組的建議和幫助；專案經理可以印證瞭解到的專案進展情況；團隊氣氛由此加強。如果還有很多富餘的時間，專案組可以討論一下開發技術、技巧，進行一些技術交流。

總之，溝通不足是軟體開發中很大的問題，而且越是大專案就越嚴重。

沒有規矩，不成方圓。專案組一定要有一些紀律，不能完全依靠自律。

這方面，有公司文化、氛圍積澱為基礎是最好，否則就應該制訂一些規矩了。

這也是保持團隊的重要組成部分。

至於開發規範，根據專案不同而有所不同，要點是：必須有，哪怕不完美！

而且，應該開誠佈公，儘早公示。

風險估計應該每個階段都進行一次，一般是根據風險列表，大家一起來估計。

其實也是讓大家充分認識到專案的處境和潛在的困難。

這件事，做了總比不做好。

評審專案計劃

專案計劃必須得到CCB會議形式的認可，否則一定會有問題！

在這個階段，週期性內部評審和走查的目的更多是為了交流，檢查模組間是否能夠協作、是否有矛盾和遺漏，作為平時非正式溝通的一個強有力的補充，大家取長補短，集思廣益，幾個人的腦袋總比一個腦袋強；第二個目的是質量控制。第三個目的才是控制進度。

根據上述特點，評審自然應該採用會議方式，也許會有人覺得冗長、拖沓，浪費了一些人不必要的時間；但是該方式的效費比非常好，是值得的；至於組織會議的人，一般是專案經理，應該多動腦子，調動大家的積極性。有人會提出使用checklist的方式，本人的經驗是：該方式削弱了溝通量，而且需要良好的制度的支援，否則容易走形式。

專案計劃制訂後，專案跟蹤工作就要開始了。跟蹤表應該每週填寫，這樣專案中的問題會被及時發現；而且最好不要用project跟蹤，而是自己製作一張或尋找合適的軟體。一般是根據專案計劃制訂，有下列內容：任務包，計劃的規模、工作量、進度，實際的規模、工作量、進度，二者的誤差以及原因分析。

任務包完成的百分比應該如何填？本人的標準是：如果只是聽成員彙報，沒有100%完成的都是0%，是0-100原則；聽了成員彙報，自己簡單察看過工作產品的，是0-50-100原則；仔細檢查過的，可以參照成員的彙報，按0-25-50-75-100原則填寫。如果一個5工作日的工作包，上邊寫著完成43%，那是一點意義也沒有的。

專案跟蹤的結果用於分析專案進展情況，里程碑報告，務必真實。

變更控制的具體手段請參照需求階段的原則。在本階段，一般只是開發人員發現需求不合理，或相互設計矛盾而要求變更。一些非基線變更的控制不需要那麼嚴格，意思是不需要CCB評審，但專案經理要根據實際情況決定是否召集專案組內相關人員的評審。

同時，應該在這個階段讓大家養成遵守變更規定的習慣。

進入到編碼階段，對專案的認識已經非常清晰了。根據設計，甚至可以計算出未來的程式碼行數。重新進行工作估計，可以更好地分配人員到合適各人技術特點和興趣的方面，提高專案組的積極性；同時，可以使管理層清晰認識到專案進展的真實情況，做出正確的決定或避免他們做出錯誤的決定。

 :namespace prefix = o ns = "urn:schemas--com::office" />

編碼的標準在現在已經逐漸趨向統一，但是仍然有必要在專案組中推行或制訂編碼標準。

統一的編碼標準，可以使專案組內可以容易地互相協助、交流，為走查、測試等工作奠定良好的基礎。

編碼標準制訂後，首先要進行專案組內培訓。不過與其說是培訓，不如說是討論和統一認識，建立未來強制執行和檢查的前提。（不教而誅謂為虐，教而後誅謂為化）

根據經驗和一些統計數字，走查的效果要優於測試。

走查要以統一的編碼標準為基礎，反過來，統一的編碼標準也是透過走查而在專案組中建立起來的。本人的經驗是：開始時，安排每週2次走查，每次1小時，只檢查一個人的一個功能，重點是編碼標準，其次是；大家可以透過走查學習他人的優良風格，改正自己的不足；兩週後整個專案組基本上風格就統一了，這之後就應該把重點放在功能上，其次是BUG。

專案跟蹤在本階段較容易，因為量化的東西比較多，虛的東西比較少。基本方法與上個階段相同。透過跟蹤，已經可以看出那些模組在上個階段沒有設計好。

跟蹤要有分析，分析有了結果要有行動。

在這個階段，一般是開發人員在實現時發現一些設計錯誤而要求變更；這時，就要求專案經理嚴格把關，與設計人員、開發人員一起研究是否真的需要變更，還是實現者沒有領會設計者的意圖。如果需要變更，則要謹慎地研究影響範圍，評估損失。

在這個階段的中、後期，隨著部分產品逐漸成形，客戶會提出變更要求；此時要注意原則，同時要搞好關係，當然，首先是原則—CCB同意。

事實上，版本控制在專案一開始時就應該展開，但未必所有的專案組都能夠做到，能做好的就更加寥寥無幾了。但在編碼階段，則最好要進行版本控制了，良好的控制機制可以減少很多無用功，甚至避免一些災難。

良好的版本控制不是來自好的版本控制工具軟體，而是版本變更控制的制度以及因此形成的良好習慣。建立一個成文的規定或規範並保證它的實行，才能使版本控制不流於形式。

如果進行了版本控制，則建議推行MISRA Rule 10-- 不得殘留被註釋掉的廢程式碼。

常用的版本控制工具有VSS,,rational套件中的clearcase也很好，只是會用會的人不多；下開發時，它自帶的SCCS也是很好用的。

一個糟糕的程式總是會不斷地被要求修改，測試工作大部分是由少數幾個程式或個別程式設計師完成的程式引起的。不斷地修改的產品無論改多少次都不會變成好產品。

因此，應該制訂程式返工標準，一個可以參照的值是15BUG/1000Line。達到了這個標準，直接刪除該程式，要求程式設計師重寫；新程式再次達到這個標準時，就換人。而且，應該嚴格執行這條規定—前提是：該規定在編碼階段就通知了大家。

測試階段的日建立簡直是被迫進行的，特別是在初期；否則測試簡直進行不下去。

但是注意不要喪失原則，為了趕進度破壞了版本控制。

測試階段是客戶提出變更最多的時候，注意不要喪失原則，要堅持CCB評審。必要的變更是必須進行的，但是要仔細評估其影響。匆匆進行的變更既破壞了規矩，也往往破壞了產品。記住一句名言：如果廚師做菜的時間長了，那是因為他想把菜做的更好。

如果在這個階段沒有一個良好的版本控制行動的話，測試工作一定會有一種混亂的感覺；而且，這是日建立的前提。

專案跟蹤在這個階段是最困難的。因為事情往往瑣碎而且交織在一起。專案經理既當裁判，又作記分員，還要是教練、隊長，必要時還要親自上陣。一個好的產品，在測試階段一定不會一團糟的。

但是，需要堅持專案跟蹤；積累這個階段的資料，才能真正評價專案、專案組每個成員、專案採用的技術（包括管理技術）優點和缺點，為公司、個人積累起經驗。所以，雖然這個時候專案經理很忙、很累、有很多重要的事情要處理，但還是應該堅持專案跟蹤。

專案收尾時應該進行專案總結，主要是評價專案產品、採用的技術、管理方法、優勢、缺點和專案組每個成員。

透過專案跟蹤獲得的資料可以作為評價的基礎，但是不能做量化的評定（分級或者打分），只能是定性的評價—一個儘量詳盡的文字說明。總結的目的是面向未來的新專案，而不是懲戒某些人，定量的評價對於下一個全新的任務基本上沒有任何幫助。

如何能夠正確地評價和使用人，依然是一個管理學難題。

歡迎討論：to:huangjien@163">huangjien@163.net