第6章 計劃與執行
本章大綱 6.1 何謂專案管理？ 6.2 如何準備一個專案計畫？ 6.3 專案時程的規劃 6.4 專案的追蹤與管理 6.5 結語
學習目標 瞭解專案管理的內容 學習如何去規劃一個專案計畫 瞭解時程的規劃 瞭解專案的追蹤及管理
何謂專案管理？(1/8) 軟體開發失敗的原因 下列是造成軟體專案失敗的常見因素： 除第一項之外，其它各項幾乎都與專案管理有關。 誤解用戶的需要。 專案的範圍定義不清。 專案的變更處置失當。 專案在計劃、追蹤及控制上的管理不佳。 溝通出現問題。 團隊合作不佳。 除第一項之外，其它各項幾乎都與專案管理有關。
何謂專案管理？(2/8) 專案管理的相關術語 專案：一個暫時性的派遣，是任務、人力、資源及交付項目的集合，以完成某項任務。 產品：專案最有價值的產出與結果。 專案計畫（project plan）：未來專案演進之詳細說明及描述。 里程碑（mileston）：到達一個活動的終點；是一項短期專案進展之正式報告。 交付項目（deliverable）：交付給顧客之里程碑。
何謂專案管理？(3/8) 專案管理（project management）：包含計畫、預算（或估算）、監督、控制，以完成專案之活動。 時程規劃（schedule planning）：專案管理的核心步驟，決定專案的工作要以怎樣的順序進行，以及何時開始與結束。 專案追蹤（project tracking）：確認專案的進展是否依照原訂時程及預算逐步進行。 專案管理流程（project management process）：係指專案進行計畫、執行與結案的步驟。
何謂專案管理？(4/8) 專案管理的意義 為了要如期完成專案。亦即在符合時程與預算的限制下，達到產品預定的功能與品質。 滿足或管理顧客的需求。顧客的需求並非一成不變，唯有透過專案管理的手段，才有可能管理或者更進一步滿足顧客的需求。 透過管理確保專案團隊專注在工作目標上。亦即避免成員在專案進行的過程中，因為其它因素而分心，導致無法準時完成預定的工作，進而造成專案的失敗。 建立有效的溝通機制。亦即確保團隊成員與顧客間能有效地一起工作，並適當地分配（時間）資源。
何謂專案管理？(5/8) 軟體專案的兩大基本面向 透過管理，在專案的「產品」、「資源」、「時程」，以及「品質」四者之間取得平衡。 計劃：重點在於定義目標與工作任務、確認專案資源與安排計畫時程等，這些需要具備足夠的工程技術背景去完成。 管理：著重在執行的效率、目標的確認、計畫進度的追蹤、有效的溝通與專案的紀律等，牽涉到計畫的執行與人員的管理。 兩者是專案一體的兩面。有計畫而無管理，則計畫是空的；反之，無計畫而有管理，則管理是假的。 如圖6.1所示 。
圖6.1 軟體專案的兩大面向
何謂專案管理？(6/8) 專案管理的九大知識領域 專案管理協會（Project Management Institute）在其所發表的專案管理核心知識（Project Management Body Of Knowledge, PMBOK）白皮書中，將專案管理分成九大知識領域，如圖6.2所示。
圖6.2 專案管理的九大知識領域
何謂專案管理？(7/8) 軟體專案的特殊性 軟體獨具的可塑性 軟體專案的單一性 軟體至今尚未能發展出標準的開發程序。 軟體開發至今尚無法準確地預測何時會出狀況，以及如何做最好，似乎隨便採用任何一種開發方法都可以，沒有一個標準的工程準則。 軟體專案的單一性 軟體開發的規律，受限於專案當時的外在條件，當外在條件不同時，甲專案所獲得的規律，未必適用於乙專案。
何謂專案管理？(8/8) 專案成敗的影響因素 商業的影響。 實作的文化。 領域知識。 團隊成員的經驗。 技術的成熟度。 用戶需求的穩定性。 系統的規模。 專案的時程。
如何準備一個專案計畫？(1/11) 專案計畫的目的 提供一個平台與框架。讓管理者對資源、人力與進度做合理的安排與估算。 約定。作為專案相關人員共同的工作依據與參考；讓每個人都知道要做什麼、何時做，並取得共識以減少團隊的溝通成本。 作為衡量專案進展的基礎。 確認並事先化解任何可能的資源衝突。 證明開發人員已於事前想過專案主要的開發議題。
如何準備一個專案計畫？(2/11) 非專案計畫的目的 專案計畫的內容 驅使專案團隊為了一個不切實際的目標拼命工作。 用充滿希望的想法制定計畫，誘使相關人員或爭取管理階層的支持。 專案計畫的內容 專案計畫的重心，主要在於範圍、時程、資源及品質等四大目標之間的平衡。內容應包含以下幾個重點： 專案目的／目標 系統範圍及限制 專案組織
如何準備一個專案計畫？(3/11) 更詳細的計畫則需要一一描述以下各個項目的內涵： 風險分析 軟硬體資源與環境 工作展開與分配 專案時程 專案的監控與報告 驗收與測試計畫 更詳細的計畫則需要一一描述以下各個項目的內涵： 願景：目的、目標 範圍：功能、特性、介面、整合、限制 工作／任務：定義、分解、進入點（相依性）、完成條件（簽核）
如何準備一個專案計畫？(4/11) 資源：時間、工具、技術、訓練 時程：工作分配、資源分配、里程碑 人員：團隊組織、角色、責任、能力、決策權 風險：辨識、暴露、化解、監控及執行 產物：交付項目、會議紀錄 發布與監督：進度報告、時間花費 作業流程：品管、需求、除錯、變更控制、上線
如何準備一個專案計畫？(5/11) 專案的願景與目標 專案的範圍 專案的願景與目標，基本上可視為一個溝通工具，讓所有的團隊成員、專案經理、顧客，以及高階主管等專案關係人，藉此得到共識，知道專案要做些什麼、要往何處去。 專案的願景是一個方向，而目標則是展開來的具體項目，是可以被定義的。 專案的範圍 專案範圍係為說明系統所要達成的功能範圍。 專案範圍有時不易取捨，可利用價值分析來協助，決定專案的範圍要規劃多大，以使專案所投入的資源能發揮最大的效益。
如何準備一個專案計畫？(6/11) 工作分解結構（Work Breakdown Structure, WBS） 賦予專案一個工作展開的結構，根據專案的範圍將工作分解成若干主要工作項目，與次級工作項目，以便安排各種活動。 WBS用在軟體開發上，有三種分解方法 名詞法：即WBS的結構由名詞所組成。 動詞法：著重在專案的開發流程上，可反映出專案接近最後目標的程度，以及專案目前的進度為何。 組織法：工作依照人與團隊來劃分，通常用在當團隊分散在不同地方的情況下，以釐清哪個小組該做什麼；當團隊成員分屬不同的功能小組時，也可用組織法來分工。
如何準備一個專案計畫？(7/11) WBS的呈現可有許多方式，如單純的軟體任務清單、類似的組織圖、或心智地圖（mind mapping）等工具。 大型專案應先切割成適當大小的系統，再用WBS展開。 WBS的範例，如圖6.3所示。
圖6.3 WBS的呈現方式
如何準備一個專案計畫？(8/11) 專案的資源安排 軟體專案所需要的資源 人力資源：人力的投入、專案的組織 軟體資源：開放原始碼、商業套件、開發工具等 時間資源：有多少時間可用、如何分配 環境資源：軟、硬體的需求 通常人是最寶貴的資源，時間次之，軟體再次之，而機器與硬體設備居末。愈是稀少性、愈是重要的資源，在規劃時愈應審慎的安排。它們之間的關係可由圖6.4表示。
圖6.4 軟體專案所需的資源
如何準備一個專案計畫？(9/11) 軟體專案可交付的項目 軟體開發各階段分別有不同的交付項目，茲分述如下： 籌劃階段的可交付項目有：可行性分析報告、專案計畫、其它各種輔助計畫（草稿） 。 需求定義與分析階段的可交付項目有：軟體需求規格、資料模型、驗證與測試計畫、專案計畫（修正版）、其它各種輔助計畫。 系統分析階段的可交付項目有：系統功能表、資料模型（修正版）、系統概念模型、需求對照表、功能設計文件、專案計畫（修正版）。
如何準備一個專案計畫？(10/11) 專案計畫的產生 專案計畫書產生的參考流程： 系統設計階段的可交付項目有：資料模型（修正版）、系統設計模型、整合測試計畫（草稿）、系統測試計畫（草稿）、需求對照表（修正版）、上線計畫、系統設計文件、專案計畫（修正版）。 專案計畫的產生 專案計畫書產生的參考流程： 定義專案目標與範圍 工作劃分與展開（找出工作項目與子工作項目） 找出工作項目之間的關連 估算工作項目的人力與時間 找出潛在的風險 建立初始計畫 修正計畫 寫成正式文件
如何準備一個專案計畫？(11/11) 其它輔助計畫 除了專案計畫之外，其它的輔助計畫書如： 品保計畫：描述專案的品管程序及標準。 軟體驗證計畫：描述系統測試及驗證的方法。 構型管理計畫：描述版本的結構與管理程序。 維護計畫：預測系統維護的需求、成本及勞力投入。 人員發展計畫：描述如何發展專案人員的技能與經驗。
專案時程的規劃(1/6) 安排工作時程 工作時程安排的目標在於 安排時程時，需要描述整體的工作方式，例如： 將資源做最佳化利用，並儘量減少工作之間的相依性，避免發生後面工作等待前面完成的情形，以降低時程延誤的風險。 考慮溝通成本的大小和複雜度，儘量減少潛在的溝通失誤。 安排時程時，需要描述整體的工作方式，例如： WBS的分割方式。 選擇何種軟體開發流程。 軟體開發的階段與里程碑。 最上層的工作項目，以及彼此間的關連與開發順序。
專案時程的規劃(2/6) 工作劃分與工作時程的關係 工作劃分與工作時程之間的關係，是相互考量、彼此影響；因為工作的分割，並不是一次到位，而是會受到時程安排的影響。 比較確定、清楚的工作可排在前面，而較需要花費時間釐清的工作，可能就往後排。 另一方面，時程排在前面的，工作就會分解得比較細；反之，則較為粗略。
專案時程的規劃(3/6) 安排工作時程的工具 計畫評核圖（Program Evaluation and Review Technique, PERT chart） 是一種以網路結構表達的圖形工具，可用在專案的時程與追蹤。 優點是透過演算法的推算，可知道每個工作節點最早開始與最晚開始的時間、最早完成與最晚完成的時間，並計算出中間的浮動時間為何。 另一個重要目的，是計算圖形上的關鍵要徑，以估算整體專案完成所需的時間。 如圖6.5所示。
圖6.5 PERT圖示意圖
專案時程的規劃(4/6) 甘特圖（Gantt chart） 主要作為表明計畫時程、協調，以及進度追蹤之用。 甘特圖與PERT圖是相輔相成的。前者較簡單，工作項目一目了然，但是無法看到工作間的相依性；相反地，後者能看到工作間的相依性，但是很難看出工作之間的階層性，或某個時間點的專案進展。 如圖6.6所示。
圖6.6 甘特圖示意圖
專案時程的規劃(5/6) ETVX（Entry, Task, Validation, and Exit） 任務內容（tasking）：說明工作內涵與細節。 驗證方法（validation）：說明如何知道某項任務是否已正確地完成。 結束條件（exit）：說明任務應做到怎樣的程度才可結束或離開；過猶不及都不好，專案資源需要做最有效的利用。
專案時程的規劃(6/6) 風險與替代計畫 軟體專案具有高度的不確定性及存在風險因素，兩者交互影響的結果，使得軟體專案幾乎不可能完全照著計畫走。 要解決上述的困境，在計劃工作時程的安排上，應預留緩衝時間，並且同時要預備替代方案，以便計畫的執行不如預期時，能夠有調整因應的空間或方案。
專案的追蹤與管理 (1/6) 90%完成症候群 許多專案深陷於90%完成症候群，亦即專案自初期一路進展直到90%完成時，就再也無法往前。 主要原因有二： 專案的控管或進度的查核過於鬆散，缺乏良好的品質監督機制，導致之前隱藏在軟體內的瑕疵，在系統逐漸完成之際一一浮現，阻礙了專案的進展。 在專案的後期，用戶需求不斷地擴大或蔓延，導致專案疲於應付，不斷地修改程式，以追逐新的目標。 如圖6.7所示 。
圖6.7 90%完成症候群的原因
專案的追蹤與管理 (2/6) 專案控管的層級 專案控管的層級可分為三層 專案委員會：為專案的最高裁決單位，召集人是專案的最高主管；而參加者包括顧客代表等專案關係人。 專案經理：為專案日常管理的最高單位，成員主要是專案開發團隊。 專案團隊：平時主要負責工作的執行，接受專案經理的領導，依照計畫進行軟體開發。 查核頻率與查核的層級有關。專案管理的層級愈高，查核頻率與詳細程度就會愈低；反之，則愈高，如圖6.8所示 。
圖6.8 專案控管的層級與資訊傳遞
專案的追蹤與管理 (3/6) 依照重要性排序 專案的監控需要花費時間與資源，並且也會對專案本身的活動，形成一定程度的干擾，所以必須把重要性排出來；愈不重要的任務，就愈不需要插手。 高風險項目也是管理者所必須關注的，必須列入日常專案追蹤的會議裡，需要持續地關注。 會使用到關鍵資源的工作項目，要列入重要性排序，定期加以追蹤。
專案的追蹤與管理 (4/6) 可用於查核專案進展的工具有很多，列述如下：
專案的追蹤與管理 (5/6) 收穫價值分析（Earned Value Analysis, EVA） 用來衡量專案的進度，並預測其完成日期與最終的成本，以提供時程與成本在專案過程中的變化。 收穫價值分析可利用三個數字指標來評估並比較專案的進展，分別是： 已完成工作之預算成本（Budgeted Cost of Work Performed, BCWP）- 即earned value 依時程工作之預算成本（Budgeted Cost of Work Scheduled, BCWS）- 應該用掉之累計預算成本 已完成工作之實際成本（Actual Cost of Work Performed, ACWP）
專案的追蹤與管理 (6/6) 收穫價值追蹤圖 收穫價值追蹤圖可一目了然知道專案現在的進度位置，以及過去的歷史與中間的變化。 其優點是簡單可行，因為它所衡量的是專案的花費（亦即金錢）或數量（亦即勞力支出），這些都是已知的資料。 缺點是它所衡量的單位不是時間，而多數軟體專案所最在意的，卻是時間，也就是專案能否如期完成？ 如圖6.9所示。
圖6.9 收獲價值追踨圖 SV=BCWP-BCWS SPI=BCWP/BCWS(Schedule Performance Index) CV=BCWP-ACWP CPI=BCWP/ACWP(Cost Performance Index) EAC=BAC/CPI (Estimate At Completion)
結語 軟體開發原本就是一項困難重重的活動，若要確保軟體開發的成功，必須對軟體專案管理有深入的瞭解。而其中專案經理所扮演的角色最具代表性，如果他不清楚自己該負的責任，則專案很容易失敗。 專案經理的四大任務 撰寫計畫 監控與查核 撰寫報告 人員的挑選與考核