day48_專案管理學習筆記
阿新 • • 發佈：2018-12-12
- 課程目標
- 認識專案管理
- 瞭解軟體專案管理的整個過程
- 軟體工程師在`整個專案過程中要做哪些工作`
- 提前規劃自己的職業生涯，遇到機會立即抓住機會
- 通過學習本課程學會用 `專案管理的方式去工作`
- 課程安排
- 第一章：專案與專案管理
- 第二章：專案啟動
- 第三章：專案規劃
- 第四章：專案實施及控制
- 第五章：專案結束
- 第六章：課程學完後的思考
一、專案與專案管理
1.1、專案的定義
專案與日常運作圖解：
專案與日常運作的區別：
- 專案是一次性的，日常運作是重複進行的。
- 專案是以目標為導向的，日常運作是通過效率和有效性體現的。
- 專案是通過專案經理及其團隊工作完成的，而日常運作是職能式的線性管理。
- 專案存在大量的變更管理，而日常運作則基本保持連貫性的。
專案的特徵：
- 有明確的目標性
- 有明確的時限性
- 資源成本的約束性
- 專案的不確定性
- 唯一性(一次性)
專案的定義：
- 日常運作：連續不斷、周而復始的活動。
- 專案：是為了創造一個唯一的產品或提供一個唯一的服務而進行的臨時性的活動。
1.2、專案管理的定義
專案管理的重要性：
- 據有關統計，全球的專案投資高達十萬億美元，其中在美國有2.5萬億美元，佔GDP25%，全球從事專案管理人員大約有11650多萬人，其中美國有450多萬人。中國未來5年內在資訊化建設的投資有上萬億人民幣。
- 軟體專案越來越複雜（需求、技術、使用者關係、後期維護等），很多專案都失敗了，導致失敗的根本原因：是缺乏有效的專案管理，缺乏合格的軟體專案經理。
- 企業成功：在於有效的推行專案管理。
專案管理的通俗理解：
- 假設我們要做一件事情，有一定的約束和目標要求，諸如時間、資金、人力等條件限制，那麼如何在這些約束條件下有效地達到我們預想的目標，通過相關的理念、技術方法和工具進行管理的過程就是專案管理。
專案管理的定義：
- 使專案能夠按照預定的
成本、進度、質量順利完成並讓所有干係人得到滿意，而對成本、人員、進度、質量、風險等進行分析和管理的活動。
1.3、專案管理框架
專案管理框架：
- 五大標準化過程組
- 十大知識領域
- 四十七個過程
專案管理的五大標準化過程組：
- 啟動階段專案的可行性分析、立項、招投標、合同簽署。
- 計劃階段範圍定義、進度安排、資源計劃、成本估計、質量保證計劃、風險計劃、實施計劃等。
- 實施及控制階段專案實施、進度控制、費用控制、質量控制、變更控制等。
- 結束階段範圍確認、質量驗收、費用結算與審計、專案資料驗收、專案交接與清算、專案審計與評估、專案總結等。
專案管理的十大知識領域：
專案管理的四十七個過程：
二、專案啟動
2.1、初始專案分析
專案型別：
- 合同專案招投標、合同談判、合同簽署，甲乙雙方有合同約束。參考專案文件“XXXXX合同書”
- 內部專案確定任務範圍和相關各人員進行有效地配合，無合同約束。
初始化專案分析：
- 專案可行性分析根據市場、技術、人員等各資源分析專案的可行性，對分析結果進行認證討論。
- 專案範圍分析確定專案的功能模組、邊界範圍等。
- 專案干係人分析分析確定專案相關人員，包括：專案發起人、專案開發人員、測試人員、維護人員、客戶等。
常用的專案生存期模型：
- 瀑布模型
- 原型模型
- 增量模型
瀑布模型：
- 瀑布模型（Waterfall Model）是通過設計一系列階段順序展開的，從系統需求分析開始直到產品釋出和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好“返回”上一個階段並進行適當的修改，專案開發程序從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。
瀑布模型的特點：
- 專案需求很明確
- 解決方案也很明確
- 類似的專案如：
- 庫存管理系統
- 短期專案
原型模型：
- 原型模型即樣品模型，先借用已有系統作為原型模型，通過“樣品”不斷改進（迭代），使得最後的產品就是使用者所需要的。
- 原型模型採用逐步求精的方法完善原型，使得原型能夠“快速”開發，避免了像瀑布模型一樣在冗長的開發過程中難以對使用者的反饋作出快速的響應。
- 常用的原型工具：Axure
原型模型的特點：
- 在專案開始前，專案的需求不明確
- 需要減少專案需求的不確定性
- 類似的專案如：
- 第一次開發的產品，驗證可行性
增量模型：
- 增量模型融合了瀑布模型的基本成分（重複應用）和原型實現的迭代特徵，該模型採用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟體的一個可釋出的“增量”。
- 當使用增量模型時，第1個增量往往是核心的產品，即：第1個增量實現了基本的需求，但很多補充的特徵還沒有釋出。客戶對每一個增量的使用和評估都作為下一個增量釋出的新特徵和功能，這個過程在每一個增量釋出後不斷重複，直到產生了最終的完善產品。
增量模型的特點：
- 專案開始，明確了需求的一部分，但是需求可能會發生變化
- 對於市場和使用者把握不是很準，需要逐步瞭解
- 對於有龐大和複雜功能的系統進行功能改進，就需要一步一步實施的
2.2、生存期模型
選擇生存期模型
- 評審、分析專案的特性
- 選擇適合專案的生存期模型
專案經理的角色
- 專案組織的領導者
- 專案組織的管理者
- 專案組織的決策者
- 專案組織的分析者
- 專案組織的計劃者
- 專案組織的控制者
- 專案組織的組織者
- 專案組織的評價者
- 專案組織的協調者
專案經理的責任
- 專案計劃
- 組織實施
- 專案控制
2.3、專案立項
專案立項-專案章程
- 確認專案存在的檔案，包括對專案的確認、對專案經理的授權和專案目標的概述等。
- 將專案啟動階段的工作內容形成統一的立項文件，文件沒有統一的格式根據公司實際管理水平制定。
- 參考資料：專案章程
專案立項—立項申請報告
- 明確專案的目標、時間、專案使用的資源和經費，而且得到執行該專案的專案經理和專案發起人的認可。
- 參考資料：專案立項申請報告
招開專案立項會
- 通常由公司PMO(專案管理辦公室)組織立項會，對專案的調研、範圍、專案經理等進行確定授權、評審、最後要有評審報告。
- 參考資料：立項評審報告
三、專案規劃
- 範圍計劃
- 進度計劃
- 成本計劃
- 質量計劃
- 人力資源計劃
- 溝通計劃
- 風險計劃
3.1、範圍計劃
WBS任務分解：
工作分解結構（Work Breakdown Structure，簡稱WBS）就是把一個專案按一定的原則分解，專案分解成任務，任務再分解成一項項工作，再把一項項工作分配到每個人的日常活動中，直到分解不下去為止。- 即：專案 --> 任務 --> 工作 --> 日常活動
- 工作分解結構以可交付成果為導向對專案要素進行的分組，它歸納和定義了專案的整個工作範圍，每下降一層代表對專案工作的更詳細定義。
- WBS總是處於計劃過程的中心，也是制定進度計劃、資源需求、成本預算、風險管理計劃和採購計劃等的重要基礎。
工作包：
- WBS的最低層次的專案可交付成果稱為工作包(Work Package)，具有以下特點：
- 工作包可以分配給另一位專案經理進行計劃和執行。
- 工作包可以通過子專案的方式進一步分解為子專案的WBS。
- 工作包可以在制定專案進度計劃時，進一步分解為活動。
- 工作包可以由惟一的一個部門或承包商負責。用於在組織之外分包時，稱為委託包(Commitment Package)。
- 工作包的定義應考慮80小時法則(80-HourRule)或兩週法則(Two Week Rule)。
- 即：任何工作包的完成時間應當不超過80小時。在每個80小時或少於80小時結束時，只報告該工作包是否完成。通過這種定期檢查的方法，可以控制專案的變化。
任務分解原則：
- 1、將主體目標逐步細化分解，最底層的日常活動可直接分派到個人去完成；
- 2、每個任務原則上要求分解到不能再細分為止；
- 3、日常活動要對應到人、時間和資金投入。
任務分解方法：
- 1、採用樹狀結構進行分解；
- 2、以團隊為中心，自上而下與自下而上的充分溝通，一對一個別交流與討論，分解單項工作。
3.2、進度計劃
制定MPP
- 使用MPP工具制定進度計劃
- 參考資料：軟體專案計劃.mpp
四、專案實施及控制
團隊管理的要點：
- 合理的人員結構
- 明確的職責及工作分工
- 適度的激勵政策
- 集體責任感和榮譽感的培養和加強
- 共同提高的指導思想
編碼的基本原則：
- 嚴格按照系統設計說明書完成軟體的編碼工作。
- 執行制定的軟體編碼規範。
- 提煉公用程式碼，加強公共模組的開發，提高開發效率。
- 注重軟體階段性成果及文件資料的管理工作，加強版本控制。
編碼規範：
- 標示符的命名規範
- （1）符號的名字應儘量能反映它所代表的型別、含義、功能、呼叫特點等。
- （2）應有一定的實際意義，使非本程式編寫的同行能夠見名知意。這有助於加強對程式功能的理解，增加程式的可讀性。
- 註釋規範
- （1）序言性註釋 類、方法名之前，對定義、輸入、輸出、引數、功能、呼叫形式等整體說明。
- （2）功能性註釋 方法內部實現過程的段落性註釋。描述其語句說明、程式段或變數完成的功能及意義。
- 程式的書寫格式
- （1）在程式的編寫中應學會使用使用空行和縮排，以增強程式程式碼的段落性和可讀性。
- （2）迴圈、分支巢狀層次不要太深。
- 公共程式碼的抽取及開發
- 軟體開發過程中往往存在大量的公共程式碼，在進行任務分解的時候要善於抽取出較多的公共程式碼，並安排技術能力較強、開發經驗豐富的軟體工程師承擔公共模組的開發任務，降低軟體開發中的重複勞動，提高軟體編碼的工作效率及軟體質量。
- 程式碼質量管理
- 正確理解設計說明書
- 強制要求所有開發人員的程式碼符合編碼規範
- 定期和不定期的程式碼走查(code walkthrough)
- 編碼規範模板
- 軟體測試V模型
- 單元測試
- 單元測試是針對軟體設計的功能方法，進行正確性檢驗的測試工作。其目的在於發現`各模組`內部可能存在的各種差錯。
- 單元測試需要從程式的內部結構出發設計測試用例。多個模組可以平行地獨立進行單元測試。
- 整合測試
- 將所有模組按照設計要求組裝成為系統。這時需要考慮的問題是：
- 模組介面的資料是否會丟失
- 模組之間的功能是否產生不利的影響
- 模組組合起來能否達到預期要求
- 全域性資料結構是否有問題
- 將所有模組按照設計要求組裝成為系統。這時需要考慮的問題是：
- 系統測試
- 是將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起，進行資訊系統的各種組裝測試和確認測試，系統測試是針對整個產品系統進行的測試。物件不僅僅包括需測試的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等。
- 驗收測試
- 驗收測試是以使用者為主的測試。軟體開發人員和QA（質量保證）人員也應參加。
- 由使用者參加設計測試用例，使用生產中的實際資料進行測試。