一般項目管理的常用技術(shù)在軟件開發(fā)項目管理中同樣具有價值，是項目管理的效能推動器。這些技術(shù)主要包括工作分解結(jié)構(gòu)、里程碑、關(guān)鍵路徑法、計劃評審技術(shù)、S曲線、掙值管理、目標(biāo)管理、責(zé)任矩陣、資源需求直方圖、圖表化、頭腦風(fēng)暴法、KJ法、蒙托卡羅模擬法、檢查清單/模板、基礎(chǔ)統(tǒng)計技術(shù)等。

工作分解結(jié)構(gòu)

工作結(jié)構(gòu)分解(WBS：work breakdown structure)是將項目完成之前的所有必要作業(yè)項目從上到下層次性羅列出來。WBS是項目管理的起點，WBS的設(shè)計可以說是項目管理的最重要工具。項目管理的第一步是項目范圍定義，明確項目的交付物，進而定義項目需要進行的活動、角色、責(zé)任以及項目組的結(jié)構(gòu)。項目范圍定義可以使用WBS，將項目的“交付物”自上而下逐層分解成易于管理的若干元素，組成一個樹狀圖。WBS每細(xì)分一層都是對項目元素更細(xì)致的描述，細(xì)分的元素稱為工作細(xì)目，其中最低層的工作細(xì)目即樹狀圖的葉節(jié)點叫作工作包，工作包定義了需要達成的性能、質(zhì)量、日程和成本。為了便于分層統(tǒng)計和識別，WBS中的每個元素都被指定一個惟一的標(biāo)識符，并分層表示。制作WBS的注意點是：不是以現(xiàn)存組織為基準(zhǔn)進行作業(yè)分解，而是以“做什么”為基礎(chǔ)，從零開始進行作業(yè)分解；不是項目管理者一個人單獨制作，而是項目組成員共同制作；WBS的任意層次的要素都需要具有(1)工作范圍明確、(2)日程確定、(3)具有成本計劃(預(yù)算)、(4)資源已經(jīng)分配、(5)具有業(yè)績測評尺度、(6)組織責(zé)任明確等特征。

計劃評審技術(shù)

計劃評審技術(shù)(PERT：program evaluation review technique)是用網(wǎng)絡(luò)圖來表達項目中各項活動的進度和他們之間的相互關(guān)系，并在此基礎(chǔ)上進行網(wǎng)絡(luò)分析，確定關(guān)鍵活動與丶?/span>路線，利用時差不斷地調(diào)整與優(yōu)化網(wǎng)絡(luò)，以求得最短周期。然后，還可將成本與資源問題考慮進去，以求得綜合優(yōu)化的項目計劃方案。PERT可以表現(xiàn)出工作包或者活動、擔(dān)當(dāng)者、交期、日程以及各活動之間的依存關(guān)系等等。PERT與WBS相互關(guān)聯(lián)和支援，使用PERT有賴于WBS的完成，但是PERT的制作又可以發(fā)現(xiàn)WBS的遺漏。PERT著眼于項目管理者應(yīng)該考量的“質(zhì)量、成本、交期(QCD)”，是質(zhì)量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于細(xì)枝末節(jié)，而是著眼于發(fā)現(xiàn)將來要直面的重要課題和問題點，從能否實現(xiàn)項目目標(biāo)而不是各工作包的角度進行分析。首先從微觀角度制作PERT，在考量各工作包的重要性以及相關(guān)性的基礎(chǔ)上著眼于QCD相關(guān)內(nèi)容：里程碑的設(shè)定；項目風(fēng)險的挖掘；項目瓶頸的抽出；人、財、物、信息、時間等項目資源的最佳分配；項目成員的最佳配置；工作包與活動的統(tǒng)合；工作包與活動的分解；現(xiàn)有資源的靈活運用；工作包之間、團隊成員之間的整體效果的分析；最短路線、重要路線等關(guān)鍵路線的確定；活動順序的妥當(dāng)性。

掙值管理

掙值管理(EVM：earned value management)是綜合項目范圍、進度計劃和項目資源，測量項目績效的一種方法。掙值管理通過比較計劃工作量、實際掙得多少與實際花費成本，決定成本和績效是否符合原定計劃。掙值管理將計劃與掙值換算為成本，并通過與達成實績所用實際成本的比較來對項目的實績進行度量和分析，可以說是成本與進度的統(tǒng)合控制管理工具。掙值管理也離不開偏差管理。

在項目過程中，通過監(jiān)視成本差異和進度差異以及成本效率指數(shù)、進度效率指數(shù)的變動，預(yù)測超過成本和進度滯后的情況后采取對策。在分析計劃與實績差異的原因及對策時，可以使用圖表化、頭腦風(fēng)暴法+KJ法。如果計劃與實績差異過大，就應(yīng)該考慮縮小項目范圍等對策。

頭腦風(fēng)暴＋KJ法

頭腦風(fēng)暴(brain storming)和KJ法都是發(fā)現(xiàn)問題和解決問題行動中實施創(chuàng)造性開發(fā)的方式。

頭腦風(fēng)暴法又叫作集思廣益法，它通過創(chuàng)造一個無批評的自由的會議環(huán)境，使與會者暢所欲言、充分交流、互相啟迪，產(chǎn)生大量創(chuàng)造性的意見，其目的是利用組合腦力刺激創(chuàng)造性，想出更多更好的主意。其作用在于：打破思維定勢，鼓勵開放性的思考；發(fā)揮集體智慧，在他人的看法上建立自己的意見；打破溝通障礙，形成團隊精神；防止少數(shù)人控制會議。其實施步驟如下：(1)將頭腦風(fēng)暴的中心議題寫在白板、膠片或掛圖上，確保每個人都充分理解中心議題的含義。(2)項目組成員輪流發(fā)言，任何意見都會得到肯定。輪流的過程鼓勵大家參與，但任何人如果沒想好則發(fā)言可以隨時跳過。(3)將每一條意見用大號字寫在膠片或掛圖上。用原話記錄每條意見，不作任何解釋。(4)繼續(xù)輪流發(fā)言，直到每個人都沒有意見為止。(5)復(fù)查意見記錄，去除完全重復(fù)的條目。小心識別并保留在用詞上有極細(xì)微差別的意見。頭腦風(fēng)暴法對于認(rèn)識現(xiàn)狀、整理問題、討論問題過程中挖掘參與人員的意見非常有效。在PMBOK所謂范圍、成本、質(zhì)量、溝通、風(fēng)險等知識領(lǐng)域的管理中比較有效。

在問題并不明朗的情況下通過KJ法可以使問題逐漸清晰起來。所以，在軟件開發(fā)過程中，多用于需求分析、業(yè)務(wù)分析等。在項目計劃階段，對于PMBOK所謂風(fēng)險管理知識領(lǐng)域中的風(fēng)險識別、對策立案等方面比較有效。但是，如果理解KJ法的成員比較少，其使用會比較困難。特地集中起來的創(chuàng)意和意見如果僅僅簡單加以分類，就難以引出問題點和創(chuàng)意點。

檢查清單/模板

在項目執(zhí)行期間，可以由項目管理團隊作成檢查清單或者模板(checklist/template)，也可以由項目管理室那樣的支持項目管理的組織在項目審查和監(jiān)督的成功案例和失敗案例的基礎(chǔ)上作成。檢查清單或者模板是組織的最佳實踐，通過這些經(jīng)驗的積累可以提高項目管理的效率，有助于防止失敗。檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏。模板作為產(chǎn)出物的雛形式樣，具有WBS、網(wǎng)絡(luò)圖、需求變更書、進展報告書、合同標(biāo)準(zhǔn)文件等形式。通過雛形的靈活運用，經(jīng)驗較淺的項目管理者可以明白必須做些什么，并能在其他項目中重復(fù)利用。

軟件開發(fā)項目管理檢查清單：天氣晴雨表

檢查清單用于確認(rèn)作業(yè)或工程是否存在遺漏，是反映項目管理是否存在問題的“天氣晴雨表”。下面是軟件開發(fā)項目管理的一個檢查清單，比本章中所言“軟件開發(fā)項目管理過程中的禍根及其后果”更加詳細(xì)。通過這個清單，可以發(fā)現(xiàn)項目管理存在的問題，并采取措施加以改善。

需求式樣晴雨表

• 是否存在穩(wěn)定的、完整的、書面的需求式樣？
• 是否已經(jīng)就需求事項煞費苦心地與顧客進行了溝通和確認(rèn)？
• 是否存在需求式樣尚未確定就以“暫定式樣”開始作業(yè)而事后返工的情況？
• 是否為了確認(rèn)顧客的需求而對“需求式樣書”進行了審查？
• 是否根據(jù)顧客提供的產(chǎn)品式樣書而直接進入了設(shè)計作業(yè)？
• 是否在作業(yè)途中不斷變更或追加需求式樣？
• 是否按照項目編號規(guī)則對每項需求賦予了惟一的編號？
• 是否已經(jīng)明確顧客方的項目推進體制以及最終決策者？
• 是否攝于顧客的特權(quán)優(yōu)位性而不經(jīng)討論地接受顧客的需求變更？
• 是否在遠遠超越自身能力而根本無法完成的情況下不能清楚地說“不”？
• 是否在作業(yè)已經(jīng)進入測試階段后還發(fā)現(xiàn)需求式樣理解有誤？
• 是否以單一窗口接收顧客的需求，確保一窗口輸入？
• 項目組成員的作業(yè)是否基于最新需求信息，而不是已經(jīng)失效的歷史信息？

項目計劃晴雨表

• 是否將估算視為一種特殊的技能，并將估算當(dāng)作一個小項目？
• 是否定期對項目計劃實施重新估算并根據(jù)實際情況加以調(diào)整？
• 是否對作業(yè)文檔等成果物的“量”進行了估計？
• 是否以適當(dāng)?shù)膯挝贿M行了作業(yè)量的估計？
• 項目作業(yè)是否具有詳細(xì)的日程表？
• 日程表確定之后，如果和實際情況出入較大，是否進行了調(diào)整？
• 是否接受了不切實際的開發(fā)日程，而其結(jié)果是，日程表僅僅成為一種形式？
• “工作量”和“難易度”是否會因為擔(dān)當(dāng)者的不同而出現(xiàn)巨大變動？
• 是否因為實際進展超前于計劃而沒有思考項目計劃本身存在的精度問題？

團隊管理晴雨表

• 是否存在明確的軟件開發(fā)行動單位：團隊？
• 是否雖然叫作團隊，但是并沒有認(rèn)識到協(xié)作而是專注于工作任務(wù)的分擔(dān)？
• 管理者是否仍然承擔(dān)以前作為技術(shù)者所承擔(dān)的具體開發(fā)作業(yè)任務(wù)？
• 項目管理者是否僅僅根據(jù)自己的經(jīng)驗而將需求式樣直接分派給“個人”？
• 項目管理者是否總是認(rèn)為項目沒有什么值得注意的問題？
• 團隊成員是否知道項目作業(yè)內(nèi)容的相互關(guān)系及其優(yōu)先級？
• 是否在項目啟動之后仍然還有項目組成員感到無所事事？
• 是否經(jīng)常有特定的項目組成員總是加班到深夜？
• 團隊成員是否知道并遵守統(tǒng)一的作業(yè)規(guī)范？
• 是否從作業(yè)流程上、從團隊協(xié)作上追究過程序缺陷的真正原因？
• 團隊成員是否在相互察看成果物后產(chǎn)生提高自己的作業(yè)水平的意識？
• 當(dāng)問題難點解決之后，是否向項目組成員介紹解決該問題的思維和方法？
• 項目組成員的出勤時間是否經(jīng)常相差很大而不尋找原因？
• 項目組成員在遇到技術(shù)難題時是否與項目組其他成員溝通并尋求支援？
• 項目組成員在討論問題時是否出現(xiàn)無條理的、非建設(shè)性的討論？

作業(yè)流程晴雨表

• 是否存在專注于組織整體的開發(fā)作業(yè)和項目流程的人或者小組？
• 是否存在項目開發(fā)作業(yè)的標(biāo)準(zhǔn)作業(yè)流程？
• 是否存在記述顧客需求式樣的文檔標(biāo)準(zhǔn)？
• 是否存在設(shè)計書的文檔標(biāo)準(zhǔn)？
• 是否不經(jīng)過設(shè)計階段而直接進入編碼階段？
• 設(shè)計階段是否實施了以設(shè)計為對象的審查？
• 編碼階段是否實施了以代碼為對象的審查？
• 中途式樣變更后，是否未經(jīng)其影響范圍的分析就直接分配給擔(dān)當(dāng)者？
• 是否未經(jīng)單體測試就直接開始綜合測試？
• 是否時至最后才發(fā)現(xiàn)此前隱藏的諸多問題？
• 是否無視已經(jīng)發(fā)現(xiàn)的問題而繼續(xù)推進作業(yè)？
• 是否多次重復(fù)出現(xiàn)以前相同的錯誤而沒有吸取教訓(xùn)？
• 是否沒有專門的測試人員而在交付之前還是由開發(fā)者自己實施測試？
• 對式樣需求是否確立了適當(dāng)?shù)臏y試項目？
• 測試是否幾乎沒有自動化手段？
• 過程改善方面是否存在可以商量和咨詢的人員？
• 是否鼓勵各開發(fā)小組寫作事后分析報告，至少能就項目進程開會討論？
• 是否組織正式的活動，就軟件開發(fā)與質(zhì)量控制流程的相關(guān)問題相互切磋？

項目配置晴雨表

• 是否在發(fā)現(xiàn)潛在的缺陷時難以確定其對現(xiàn)有模型的影響范圍？
• 是否只有擔(dān)當(dāng)者知道而沒有向所有成員公布缺陷的修正范圍和修正方法？
• 是否因為修改一個程序缺陷而引發(fā)多個新的缺陷？
• 擔(dān)當(dāng)者是否能在任何時間對源程序做自由的變更？
• 開發(fā)期間是否定期對制作過程中的文件和程序進行備份？
• 是否確立了資源備份在非常時期的因應(yīng)方式？
• 需求式樣書和設(shè)計書等正式文件是否存在“確認(rèn)”手續(xù)？
• 項目文檔是否一直保持最初的狀態(tài)，即使在式樣變更后仍然沒有變化？
• 是否在項目后期難以想起中途式樣變更的“理由”？
• 對于程序缺陷和式樣變更，是否能追蹤其修改點？
• 對于開發(fā)環(huán)境目錄中的舊代碼是否難以判斷其能否刪除？
• 開發(fā)文檔是否會出現(xiàn)鏈接到舊版本的情況？

教育培訓(xùn)晴雨表

• 是否描繪出現(xiàn)在的開發(fā)組織多年后的“風(fēng)姿”？
• 在組織上，是否對現(xiàn)在的人員實施技術(shù)性教育和培訓(xùn)？
• 是否確立了員工教育培訓(xùn)的計劃和目標(biāo)？
• 是否將技術(shù)學(xué)習(xí)視為個人任務(wù)而沒有組織上的“方向”？
• 項目開發(fā)人員所持有的軟件開發(fā)文獻的平均數(shù)量是否在1冊以下？
• 項目作業(yè)休息時間是否毫不涉及嶄新技術(shù)方面的話題？
• 項目組成員是否不知道軟件工程的意思？
• 是否不了解“凝聚度”、“結(jié)合度”等詞匯的意思？
• 是否難以說出5個以上的軟件質(zhì)量特性及其副特性？

項目審查晴雨表

• 參與者是否了解審查的整體流程？
• 是否帶著目的而非盲目地實施審查作業(yè)？
• 是否僅僅局限于代碼審查而不顧及其他？
• 審查者是否只關(guān)注形式而非實質(zhì)？
• 是否明確審查對象物，針對“物”而非“人”？
• 是否記錄審查結(jié)果并追蹤缺陷修正結(jié)果？
• 是否將審查的反饋結(jié)果導(dǎo)入下一項目中？
• 審查會議是否演化成為問題解決會議？

其他

• 是否采取了數(shù)據(jù)備份以及病毒防范等措施？
• 對電子郵件的應(yīng)對是否總是滯后？
• 是否感到電子郵件的應(yīng)對很繁瑣？