1、項目管理技法軟件開發項目管理智囊機構：項目管理室軟件開發項目管理是軟件開發領域的專業性項目管理活動，其成敗關系到整個項目的成敗，并影響到企業整體的商譽、市場和盈利力量。所以，軟件企業需要關注項目管理力量的提升。而實現這一目的的重要途徑之一就是設立項目管理智囊機構，通過積聚整個企業的項目管理專業學問、專業閱歷和專業人才來確保項目管理的勝利。假如軟件企業消失如下項目管理癥狀，就可以考慮采納項目管理智囊機構。 項目管理中總是重復相同的失敗大事，項目管理專業技能沒有得到積累; 項目管理的績效由于項目管理者個人的轉變而消失很大的差異; 針對項目的質量、進度和成本等事項的估算沒有適當的推斷標準; 企業內各

2、個項目的管理方法各自不同，沒有統一的標準和體系; 每個項目正式啟動之前，都不得不進行進行相同的說明和培訓; 項目管理者之間的項目管理相關學問沒有得到有效溝通和共享項目管理智囊機構主要是指項目管理室(project management office)，這是企業項目管理的智囊機構，與項目組(project team)不同：項目管理室對企業內項目的一般管理手法負責，但是只對各項目供應管理支援;而項目組需要對項目的運營和損益負責。詳細而言，項目管理室的主要職責在于：其一，項目管理標準統合，主要包括項目作業流程、項目作業進度、項目作業質量、項目作業成本、項目作業效率等事項的標準統一;其二，項目管理詢問

3、支援，項目管理室成員通過其豐富的項目管理閱歷和項目管理資料為項目管理供應問題解決方案、問題預防方法以及各種項目管理技能;其三，項目管理掌握支援，主要包括：作為項目之間的協調者，促進項目資源的合理安排;作為項目管理的監督者，猜測并監控各項目存在的各種風險并加以解決;其四，項目管理人才培訓，通過有方案的持續的系統的項目管理培訓體系為企業的進展供應項目管理培訓服務，并從企業內外查找優秀的項目管理者，確保企業擁有足夠的項目管理人力資源。NTT數據株式會社在PMO的實施方面就是一個典型。NTT數據為了確保企業項目管理者的質量和數量，在品質保證部內設立“項目管理推動室”作為項目管理的推動組織，重點從3個方

4、面來解決項目管理問題：其一，導入“PM企業內資格認證制度”，就是依據綜合了PMBOK、IT技能標準(IT skill standard)以及NTT數據自身擁有的PM專業學問等內容的PM力量基準，以企業內資格的形式確認擁有項目管理技能的人才的價值，提高PM的存在感和價值感;其二，PM職位的明確化，PM職位不僅包括最高層次的項目經理，還包括小組長以及小隊長，形成階段性的職務進階機制;其三，PM培訓體制的完善，就是確立共享和繼承NTT數據所擁有的PM專業學問的機制，以及完善促進討論學習的培訓措施。NTT數據為了進一步綻開“強化SI業務競爭力”這一重點經營方針，以及改善開發過程和提高項目管理力量，于2

5、022年11月設立“SI競爭力本部”，并在“SI競爭力本部”內設立項目管理室PMO，以期為項目管理者供應實務性支援，強化組織性的項目管理力量，以此開展整個企業的過程改善活動和項目管理活動。NTT數據還于2022年1月成立全資子公司NTT數據PMO株式會社(NTT DATA PMO CORPORATION)，這是集中了NTT數據項目管理專業學問的專家集團，由NTT數據中擁有豐富的系統開發閱歷和很強的項目管理力量的專業人員組成，特地為項目管理學問不足的項目供應管理專業學問、調查、討論、訓練培訓和詢問服務。最初以NTT數據本身的開發項目為目標開展活動，此后將漸漸擴大到NTT數據集團的全部企業。軟件開

6、發項目管理常用技術：效能推動器一般項目管理的常用技術在軟件開發項目管理中同樣具有價值，是項目管理的效能推動器。這些技術主要包括工作分解結構、里程碑、關鍵路徑法、方案評審技術、S曲線、掙值管理、目標管理、責任矩陣、資源需求直方圖、圖表化、頭腦風暴法、KJ法、蒙托卡羅模擬法、檢查清單/模板、基礎統計技術等。工作分解結構工作結構分解(WBS：work breakdown structure)是將項目完成之前的全部必要作業項目從上到下層次性排列出來。WBS是項目管理的起點，WBS的設計可以說是項目管理的最重要工具。項目管理的第一步是項目范圍定義，明確項目的交付物，進而定義項目需要進行的活動、角色、責任

7、以及項目組的結構。項目范圍定義可以使用WBS，將項目的“交付物”自上而下逐層分解成易于管理的若干元素，組 成一個樹狀圖。WBS每細分一層都是對項目元素更細致的描述，細分的元素稱為工作細目，其中最低層的工作細目即樹狀圖的葉節點叫作工作包，工作包定義了需要達成的性能、質量、日程和成本。為了便于分層統計和識別，WBS中的每個元素都被指定一個惟一的標識符，并分層表示。制作WBS的留意點是：不是以現存組織為基準進行作業分解，而是以“做什么”為基礎，從零開頭進行作業分解;不是項目管理者一個人單獨制作，而是項目組成員共同制作;WBS的任意層次的要素都需要具有(1)工作范圍明確、(2)日程確定、(3)具有成本

8、方案(預算)、(4)資源已經安排、(5)具有業績測評尺度、(6)組織責任明確等特征。方案評審技術方案評審技術(PERT：program evaluation review technique)是用網絡圖來表達項目中各項活動的進度和他們之間的相互關系，并在此基礎上進行網絡分析，確定關鍵活動與丶?/span路線，利用時差不斷地調整與優化網絡，以求得最短周期。然后，還可將成本與資源問題考慮進去，以求得綜合優化的項目方案方案。PERT可以表現出工作包或者活動、擔當者、交期、日程以及各活動之間的依存關系等等。PERT與WBS相互關聯和支援，使用PERT有賴于WBS的完成，但是PERT的制作又可以發覺WB

9、S的遺漏。PERT著眼于項目管理者應當考量的“質量、成本、交期(QCD)”，是質量最佳化、成本最小化、交期最短化的分析工具。PERT不拘泥于細枝末節，而是著眼于發覺將來要直面的重要課題和問題點，從能否實現項目目標而不是各工作包的角度進行分析。首先從微觀角度制作PERT，在考量各工作包的重要性以及相關性的基礎上著眼于QCD相關內容：里程碑的設定;項目風險的挖掘;項目瓶頸的抽出;人、財、物、信息、時間等項目資源的最佳安排;項目成員的最佳配置;工作包與活動的統合;工作包與活動的分解;現有資源的敏捷運用;工作包之間、團隊成員之間的整體效果的分析;最短路線、重要路線等關鍵路線的確定;活動挨次的妥當性。掙

10、值管理掙值管理(EVM：earned value management)是綜合項目范圍、進度方案和項目資源，測量項目績效的一種方法。掙值管理通過比較方案工作量、實際掙得多少與實際花費成本，打算成本和績效是否符合原定方案。掙值管理將方案與掙值換算為成本，并通過與達成實績所用實際成本的比較來對項目的實績進行度量和分析，可以說是成本與進度的統合掌握管理工具。掙值管理也離不開偏差管理。在項目過程中，通過監視成本差異和進度差異以及成本效率指數、進度效率指數的變動，猜測超過成本和進度滯后的狀況后實行對策。在分析方案與實績差異的緣由及對策時，可以使用圖表化、頭腦風暴法+KJ法。假如方案與實績差異過大，就應當

11、考慮縮小項目范圍等對策。頭腦風暴+KJ法頭腦風暴(brain storming)和KJ法都是發覺問題和解決問題行動中實施制造性開發的方式。頭腦風暴法又叫作集思廣益法，它通過制造一個無批判的自由的會議環境，使與會者暢所欲言、充分溝通、相互啟迪，產生大量制造性的看法，其目的是利用組合腦力刺激制造性，想出更多更好的辦法。其作用在于：打破思維定勢，鼓舞開放性的思索;發揮集體才智，在他人的看法上建立自己的看法;打破溝通障礙，形成團隊精神;防止少數人掌握會議。其實施步驟如下：(1)將頭腦風暴的中心議題寫在白板、膠片或掛圖上，確保每個人都充分理解中心議題的含義。(2)項目組成員輪番發言，任何看法都會得到確定

12、。輪番的過程鼓舞大家參加，但任何人假如沒想好則發言可以隨時跳過。(3)將每一條看法用大號字寫在膠片或掛圖上。用原話記錄每條看法，不作任何解釋。(4)連續輪番發言，直到每個人都沒有看法為止。(5)復查看法記錄，去除完全重復的條目。當心識別并保留在用詞上有極微小差別的看法。頭腦風暴法對于熟悉現狀、整理問題、爭論問題過程中挖掘參加人員的看法特別有效。在PMBOK所謂范圍、成本、質量、溝通、風險等學問領域的管理中比較有效。在問題并不明朗的狀況下通過KJ法可以使問題漸漸清楚起來。所以，在軟件開發過程中，多用于需求分析、業務分析等。在項目方案階段，對于PMBOK所謂風險管理學問領域中的風險識別、對策立案等

13、方面比較有效。但是，假如理解KJ法的成員比較少，其使用會比較困難。特地集中起來的創意和看法假如僅僅簡潔加以分類，就難以引出問題點和創意點。檢查清單/模板在項目執行期間，可以由項目管理團隊作成檢查清單或者模板(checklist/template)，也可以由 項目管理室那樣的支持項目管理的組織在項目審查和監督的勝利案例和失敗案例的基礎上作成。檢查清單或者模板是組織的最佳實踐，通過這些閱歷的積累可以提高項目管理的效率，有助于防止失敗。檢查清單用于確認作業或工程是否存在遺漏。模板作為產出物的雛形式樣，具有WBS、網絡圖、需求變更書、進展報告書、合同標準文件等形式。通過雛形的敏捷運用，閱歷較淺的項目管

14、理者可以明白必需做些什么，并能在其他項目中重復利用。軟件開發項目管理檢查清單：天氣晴雨表檢查清單用于確認作業或工程是否存在遺漏，是反映項目管理是否存在問題的“天氣晴雨表”。下面是軟件開發項目管理的一個檢查清單，比本章中所言“軟件開發項目管理過程中的禍根及其后果”更加具體。通過這個清單，可以發覺項目管理存在的問題，并實行措施加以改善。需求式樣晴雨表 是否存在穩定的、完整的、書面的需求式樣? 是否已經就需求事項煞費苦心地與顧客進行了溝通和確認? 是否存在需求式樣尚未確定就以“暫定式樣”開頭作業而事后返工的狀況? 是否為了確認顧客的需求而對“需求式樣書”進行了審查? 是否依據顧客供應的產品式樣書而直

15、接進入了設計作業? 是否在作業途中不斷變更或追加需求式樣? 是否根據項目編號規章對每項需求給予了惟一的編號? 是否已經明確顧客方的項目推動體制以及最終決策者? 是否攝于顧客的特權優位性而不經爭論地接受顧客的需求變更? 是否在遠遠超越自身力量而根本無法完成的狀況下不能清晰地說“不”? 是否在作業已經進入測試階段后還發覺需求式樣理解有誤? 是否以單一窗口接收顧客的需求，確保一窗口輸入? 項目組成員的作業是否基于最新需求信息，而不是已經失效的歷史信息?項目方案晴雨表 是否將估算視為一種特別的技能，并將估算當作一個小項目? 是否定期對項目方案實施重新估算并依據實際狀況加以調整? 是否對作業文檔等成果物

16、的“量”進行了估量? 是否以適當的單位進行了作業量的估量? 項目作業是否具有具體的日程表? 日程表確定之后，假如和實際狀況出入較大，是否進行了調整? 是否接受了不切實際的開發日程，而其結果是，日程表僅僅成為一種形式? “工作量”和“難易度”是否會由于擔當者的不同而消失巨大變動? 是否由于實際進展超前于方案而沒有思索項目方案本身存在的精度問題?團隊管理晴雨表 是否存在明確的軟件開發行動單位：團隊? 是否雖然叫作團隊，但是并沒有熟悉到協作而是專注于工作任務的分擔? 管理者是否仍舊擔當以前作為技術者所擔當的詳細開發作業任務? 項目管理者是否僅僅依據自己的閱歷而將需求式樣直接分派給“個人”? 項目管理

17、者是否總是認為項目沒有什么值得留意的問題? 團隊成員是否知道項目作業內容的相互關系及其優先級? 是否在項目啟動之后仍舊還有項目組成員感到無所事事? 是否常常有特定的項目組成員總是加班到深夜? 團隊成員是否知道并遵守統一的作業規范? 是否從作業流程上、從團隊協作上追究過程序缺陷的真正緣由? 團隊成員是否在相互察看成果物后產生提高自己的作業水平的意識? 當問題難點解決之后，是否向項目組成員介紹解決該問題的思維和方法? 項目組成員的出勤時間是否常常相差很大而不查找緣由? 項目組成員在遇到技術難題時是否與項目組其他成員溝通并尋求支援? 項目組成員在爭論問題時是否消失無條理的、非建設性的爭論?作業流程晴

18、雨表 是否存在專注于組織整體的開發作業和項目流程的人或者小組? 是否存在項目開發作業的標準作業流程? 是否存在記述顧客需求式樣的文檔標準? 是否存在設計書的文檔標準? 是否不經過設計階段而直接進入編碼階段? 設計階段是否實施了以設計為對象的審查? 編碼階段是否實施了以代碼為對象的審查? 中途式樣變更后，是否未經其影響范圍的分析就直接安排給擔當者? 是否未經單體測試就直接開頭綜合測試? 是否時至最終才發覺此前隱蔽的諸多問題? 是否無視已經發覺的問題而連續推動作業? 是否多次重復消失以前相同的錯誤而沒有吸取教訓? 是否沒有特地的測試人員而在交付之前還是由開發者自己實施測試? 對式樣需求是否確立了適當的測試項目? 測試是否幾乎沒有自動化手段? 過程改善方面是否存在可以商議和詢問的人員? 是否鼓舞各開發小組寫作事后分析報告，至少能就項目進程開會爭論? 是否組織正式的活動，就軟件開發與質量掌握流程的相關問題相互切磋?項目配置晴雨表 是否在發覺潛在的缺陷時難以確定其對現有模型的影響范圍? 是否只有擔當者知道而沒有向全部成員公布缺陷的修正范圍和修正方法? 是否由于修改一個程序缺陷而引發多個新的缺陷? 擔當者是否能在任何時間對源程序做自由的變更? 開發期間是否定期對制作過程中的文