CMMI差异分析改善规划报告.pdf

november 9, 2011 copyright 2011 by hermesoftware technology inc. page 1 of 18 資策會智慧網通系統研究所行動多媒體中心資策會智慧網通系統研究所行動多媒體中心 差異分析與差異分析與改善規劃報告改善規劃報告 評鑑單位：赫家科技股份有限公司 中華民國 100 年 11 月 09 日 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 2 of 18 content 一、 差異分析背景簡介. 4 1.1 組織現況與背景介紹. 4 1.2 差異分析目標. 4 二、 cmmi 簡介 4 2.1 關於 cmmi 模式 . 4 2.2 流程領域. 8 三、 差異分析內容與結果. 10 3.1 差異分析範圍. 10 3.2 差異分析結果與改善建議. 10 3.2.1 requirements management (reqm) 11 3.2.2 project planning (pp) . 12 3.2.3 project monitoring and control (pmc) . 13 3.2.4 process and product quality assurance (ppqa) . 14 3.2.5 configuration management (cm) . 15 3.2.6 measurement and analysis (ma) 16 3.2.7 一般目標 gg2 與執行方法(generic practice) . 16 3.2.8 總結 17 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 3 of 18 revision history ver date author summary of changes 0.1 11/2/2011 ariel chou draft version 0.2 11/5/2011 ariel chou revised subjects and content 1.0 11/9/2011 ariel chou formal released version november 9, 2011 copyright 2011 by hermesoftware technology inc. page 4 of 18 一、一、 差異分析背景差異分析背景簡介簡介 1.1 組織現況與組織現況與背景介紹背景介紹 資策會智慧網通系統研究所本身導入 cmmi ml3 流程，具備標準的組織規範與相關 流程。此次進行差異分析的單位為其下的行動多媒體中心之網路影音組。網路影音組 團隊共有十五名成員，主要負責多媒體相關技術的研發，如智慧電視網路串流等。 該小組的業務包含承接經濟部技術處專案，以及銷售其所開發的技術元件或產品給業 界客戶，並可能包含部分商品客製化服務。 網路影音組的產品研發主要採用 iterative 模式，並於近期接受台北科技大學輔導， 導入 scrum 開發模式。北科大團隊近年來致力於學界及業界推動具有 agile 精神的 scrum 流程，智通所網路影音組在其協助下，實際應用 scrum 流程於新技術產品的 開發，希望在保持 scrum 快速短期的開發型態精神下，也能與美國卡內基美隆軟體 工程學院所制定的 cmmi 流程改善模式接軌，加強既有工作產出品質的管控。 1.2 差異分析差異分析目標目標 此次差異分析將著重在網路影音組目前採用 scrum 流程所執行的專案活動與 cmmi ml2 的要求進行比對與分析，界定兩者間的差異及各流程領域的未來改善事項。 並 以現行情況為基礎，在增加最少負擔之前提下，建議改善事項，以期開發團隊能在執 行 scrum 生命週期的同時，也能符合 cmmi ml2 的要求規範。 主要目標歸結如下： n 界定現行 scrum 流程活動與 cmmi ml2 之差異。 n 對不符合事項提出改善建議，以協助改善 scrum 流程，讓未來使用 scrum 流 程團隊也能滿足 cmmi 要求，通過 cmmi 評鑑。 二、二、 cmmi 簡介簡介 2.1 關於關於 cmmi 模式模式 流程是組織持續改善的要素之一，而 cmmi 為一種流程改善的方法，提供組織有效 流程的必要元素。它可以用來指引一個專案、一個部門、或整個組織的流程改善。 cmmi 整合了傳統各自分開的組織功能，設定流程改善目標與優先順序，指引發展高 品質流程，同時也可作為現行流程的評鑑參考。cmmi 模式將許多經過驗證的業界經 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 5 of 18 驗與方法加入架構中，對於組織流程改善及發展、取得、與維護產品或服務的管理能 力提供了完整指引。 組織可藉由 cmmi 模式之協助，設定組織流程改善的目的及優先順序、改善流程並 確保流程的穩定度、能力度及成熟度。cmmi 共有 cmmi-dev、cmmi-svc、 cmmi-acq 三種模式。有意導入 cmmi 進行流程改善的組織，應就其組織發展與經 營目標，選擇適合的模式。 cmmi 同時提供了兩種不同的 representation：continuous representation 及 maturity representation，讓導入的組織就其企業目標與專案特性而選擇所採用的 representation，以達成能力成熟度。 l continuous representation：採用能力度(capability)，共有 0 到 3 四個能力度。 每個能力度會對應一個一般目標，和一組經過定義的一般執行方法。在 continuous representation 內，可以依改善的重點及組織經營的目標，選擇流 程領域的改善順序。此種作法可以降低組織經營的風險範圍。並以流程領域為基 準或藉由對成熟度層級之比對，促使組織內部或跨組織的相互比較。 l staged representation：採用成熟度(maturity)，共有由 1 至 5 五個成熟度。每 個成熟度，包含一組事先定義好的流程領域和一般目標。staged representation 適用於組織整體的流程能力與成熟度提升。從最基本的管理執 行方法開始，以預定並已認可之進階層級的路徑逐步導入，每個層級均為向上進 階層級的重要基礎。staged representation 允許使用成熟度在組織內或跨組織 作比較。 上述兩種 representation 都包含了下列的元件(model component)：流程領域 (process areas)、特定目標(specific goals)、特定執行方法(specific practices)、一般 目標(generic goals)、一般執行方法(generic practices)、典型的工作產品(typical work products)、細部執行方法(subpractices)、註解(notes)、專業領域強化 (discipline amplifications)、一般執行方法詳細說明(elaborations)，以及參考資料 (references)。 由於此次針對網路影音小組的差異分析是以 staged representation 為基礎，因此在 此簡單介紹其所包含的五個成熟度等級： l ml1: initial: ml1 意味著專案的執行並無一定的流程，而組織也無法提供穩定的環境。這些 組織的成功，往往依賴組織成員的能力與英雄主義，並非遵循一套經過驗證的流 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 6 of 18 程。此類的組織也經常會產生可運作的產品和服務；不過它們經常會超過專案的 預算和時程。 屬於 ml1 成熟度的組織特徵包含了：過度承諾的傾向、在緊急關頭放棄流程， 以及無法重複成功經驗。 l ml2: managed ml2 的組織已達成成熟度第二級所有流程領域的 specific 及 generic 目標。因 此組織專案之需求、流程、與工作產品是已被管理的，而且其流程是經過規劃、 執行、度量及控制的。 在處於壓力的期間，其所定義的流程規範，將可提供協助以確保現行的執行方法 保持不變，因此專案的執行和管理，會依循計畫進行。而在定義的里程碑或重要 時間點，管理階層都可以瞭解工作產品的狀況和服務的交付情形。 l ml3: defined ml3 的組織已具備組織標準流程，不僅涵蓋內部各類型專案執行的生命週期， 並提供調適指引讓專案得以依其特定情況進行流程調適。ml3 的流程除了專案 管理與支援類流程領域外，增加了流程類及工程類方面的相關流程領域。 ml3 的流程除了較 ml2 多了更多的流程且更為詳盡與嚴謹外，更具有整個組織 的一致性。 l ml4: quantitatively managed ml4 則是在根據客戶、最終使用者、組織及流程執行者的需求，建立品質和流 程績效的量化目標，並以該目標為管理流程時的準則。通常組織會選擇對整體流 程績效有重大影響的子流程， 針對這些流程，蒐集流程績效的詳細度量資料， 並進行統計分析，並據以界定流程變異的特殊原因，以適當地修正特殊原因的來 源，避免未來再度發生。同時會將品質和流程績效的度量結果，整合至組織度量 資料庫，以支援未來以事實與經驗為基礎的決策。 在 ml4 成熟度之流程績效是由統計和其他的量化技術所控制，並且可以用量化 方式預測。但在 ml3 成熟度之流程僅能在品質上是可預測的。 l ml5: optimizing 經由漸進和創新的技術性改善，ml5 成熟度專注於持續改善流程績效，持續修 訂組織的量化流程改善目標以反映持續變動的經營目標，並當作管理流程改善的 準則，據以度量與評估已推展之流程改善的效果。 靈活和創新的最佳化流程，有賴於被充分授權之工作團隊的參與，並且要配合組 織的經營價值與目標。組織對改變和機會的快速反應能力，可藉由發現加速學習 和分享學習的方法來加強。流程改善是每個人的責任，它也會導致持續改善的循 環。 ml4 與 ml5 的主要區別在於所要克服的流程變異類型。在 ml4 中，流程專注 於克服特殊原因的流程變異，並提出統計上的可預測結果。雖然流程或許可以產 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 7 of 18 生可預期的結果，但該結果未必足以達到預期的目標。ml5 則專注於克服共同 原因的流程變異，並改變流程(也就是改變流程績效的平均值)以改善流程績效(同 時維持統計上的可預測性)，以便達成預期之流程改善的量化目標。 組織成熟度描述組織可達到的預期結果，它也是預測組織下一個進行中專案可能結果 的方法之一。例如：在成熟度第二級，組織經由建立可行的專案管理流程，已由無特 定章法提升到有制度可循。當組織達成所設定之成熟度所有流程領域的一般及特定執 行方法時，就提升了組織成熟度，並獲得流程改善的好處。 一般目標一般目標(generic goal)與一般執行方法與一般執行方法(generic practice) 在 cmmi 模式的 staged representation 中，每一個流程領域都有其不同之特定目標 （specific goal），但卻有相同的一般目標（generic goal）。一般目標說明須達成 什麼樣的制度化，以符合該流程領域的需求。 ml2 成熟度的流程領域，包括下列的一般目標： gg2 已管理流程之制度化：將流程制度化為已管理流程 ml3 成熟度或更高等級的流程領域，包括下列的一般目標： gg3 已定義流程之制度化：將流程制度化為已定義流程 當某流程已制度化為已定義流程時，該流程同時也滿足了制度化為已管理流程所需的 所有事項，所以 gg3 隱含(subsume)了 gg2 的要求。成熟度第三級(含)以上的流程 領域只有一個一般目標(即 gg3)，但 gg3 除了包括其特定的一般執行方法(generic practice)之外，也包括 gg2 的一般執行方法。 以下對 ml2 之 gg2 所包含的一般執行方法(generic practice)作說明： gp 2.1 建立組織政策：其目的在於定義組織對流程的期望，並使組織中受影響的人 都能瞭解這些期望。一般而言，資深管理人員擔負著建立與溝通組織之指導原則、方 向及期望的責任。 gp 2.2 規劃流程：其目的在規劃執行流程和資源、準備執行流程所需的計畫、準備 流程說明，以及取得相關關鍵人員對該計畫的同意。 gp 2.3 提供資源：其目的在確保獲得執行流程所需的資源。資源包含充分的資金、 合適的硬體設施、有技能的人力及適當的工具。 gp 2.4 指派責任：其目的在於整個執行流程和達成指定結果的過程中，都有人能負 責任。而被指派責任的人必須有適當的授權，以執行該責任。 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 8 of 18 gp 2.5 訓練人員：其目的在於確保人員具有必要的技巧和專業知識，以執行或支援 流程的執行。 gp 2.6 管理建構：其目的在建立並維護流程的指定工作產品(或其他說明)在整個生 命週期的完整性。 gp 2.7 界定並納入相關的關鍵人員：其目的在建立並維護關鍵人員在流程執行期間 預期的參與程度。 gp 2.8 監控流程：其目的在執行直接的日常流程監控，以維護流程適當的能見度。 必要時，須採取適當的矯正措施。流程監控包括流程或流程所產生之工作產品及相關 屬性之度量工作。 gp 2.9 客觀評估遵循程度：其目的在提供稽核，確保流程依計畫執行，並遵循該流 程的說明、標準及程序。 gp 2.10 與上層主管審查各狀況：其目的在使上層管理人員對流程的執行有適當的了 解。 2.2 流流程領域程領域 cmmi 所有的流程領域，可依其類別分為下列四類： l 流程管理類(process management)：涵蓋與流程的定義、規劃、資源分配、推 展、實作、監督、控制、評鑑、度量及改善相關的各種專案活動。包含下列流程 領域: n 組織流程專注 (organizational process focus, opf) n 組織流程定義 (organizational process definition, opd) n 組織訓練 (organizational training, ot) n 組織流程績效 (organizational process performance, opp) n 組織績效管理 (organizational performance management, opm) l 專案管理類(project management)：包括與專案的規劃、監督及控制有關的專案 管理活動。包含下列流程領域： n 需求管理 (requirements management, reqm) n 專案規劃 (project planning, pp) n 專案監控 (project monitoring and control, pmc) n 供應商協議管理 (supplier agreement management, sam) n 整合的專案管理 (integrated project management for ippd, ipm) n 風險管理 (risk management, rskm) n 量化專案管理 (quantitative project management, qpm) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 9 of 18 l 工程類(engineering)：包含所有工程專業領域(例如：系統工程與軟體工程)皆可 共用的發展活動和維護活動。工程類流程領域包括五個有相互關係的流程領域。 這些相互關係源於應用某產品發展流程，而不是某特定的專業領域，如軟體工程 或系統工程。包含下列流程領域： n 需求發展 (requirements development, rd) n 技術解決方案 (technical solution, ts) n 產品整合 (product integration, pi) n 驗證 (verification, ver) n 確認 (validation, val) l 支援類(support)：支援類流程領域包含支援產品發展與維護的活動。支援類流 程領域所說明的流程，在執行其他流程時會使用。一般而言，支援類流程領域以 專案為對象，而針對組織時，會比較通用的方式來說明流程。例如：所有的流程 領域都會使用流程與產品品質保證，以客觀評估該流程領域的流程和工作產 品。包含了下列的流程領域： n 建構管理 (configuration management, cm) n 流程與產品品質保證 (process and product quality assurance, ppqa) n 度量與分析 (measurement and analysis, ma) n 決策分析與解決方案 (decision analysis and resolution, dar) n 原因分析與解決方案 (causal analysis and resolution, car) 若依成熟度區分，則排列如下： l ml2: n 需求管理 (requirements management, reqm) n 專案規劃 (project planning, pp) n 專案監控 (project monitoring and control, pmc) n 供應商協議管理 (supplier agreement management, sam) n 建構管理 (configuration management, cm) n 流程與產品品質保證 (process and product quality assurance, ppqa) n 度量與分析 (measurement and analysis, ma) l ml3: n 整合的專案管理 (integrated project management for ippd, ipm) n 風險管理 (risk management, rskm) n 需求發展 (requirements development, rd) n 技術解決方案 (technical solution, ts) n 產品整合 (product integration, pi) n 驗證 (verification, ver) n 確認 (validation, val) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 10 of 18 n 組織流程專注 (organizational process focus, opf) n 組織流程定義 (organizational process definition, opd) n 組織訓練 (organizational training, ot) n 決策分析與解決方案 (decision analysis and resolution, dar) l ml4: n 組織流程績效 (organizational process performance, opp) n 量化專案管理 (quantitative project management, qpm) l ml5: n 組織績效管理 (organizational performance management, opm) n 原因分析與解決方案 (causal analysis and resolution, car) 三、三、 差異分析內容與結果差異分析內容與結果 3.1 差異分析範圍差異分析範圍 此次針對網路影音組所執行之差異分析的範圍如下： n cmmi 模式 : cmmi-dev staged representation version 1.3 n 成熟度層級: maturity level 2 n 適用的流程領域: pp, pmc, reqm, ppqa, cm, ma n 組織單位: 網路影音組 n 組織中執行的專案型態生命週期: 產品開發scrum 3.2 差差異分析異分析結果結果與改善建議與改善建議 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 11 of 18 以下部份將此次差異分析結果依照 ml2 中的每個流程領域，分別說明該流程領域之 目的、網路影音組之專案執行現況、以及評鑑單位針對分析比較後的改善建議， 以 協助受輔導單位完整改善其內部流程，進而提昇產品開發品質。 3.2.1 requirements management (reqm) 需求管理的目的，是在專案生命週期中管理專案產品及產品組件的需求，並界定 這些需求與專案計畫及工作產品間的差異，以有效控制需求變更對專案產生之影 響。 組織現況組織現況分析分析： 需求的來源是由product owner提出，以會議、簡報展示、及email等方式 與潛在客戶溝通產品的功能與需求。(sp 1.1) 需求以user stories的方式記錄在product backlog中。(sp 1.1) 當客戶與product owner確認功能需求後，product owner會將記錄在 product backlog中的user stories提出來，在planning meetings裡與 members討論並取得共識承諾。(sp 1.2) 需求的變更通常會在sprint會議中討論，將變更的需求轉化成product backlog 中的新stories，放在未來的sprint中執行。 (sp 1.3) 在每個sprint的planning meeting及daily meeting中會討論及確保專案計畫 與產出物跟需求保持一致。(sp 1.5) 改善建議：改善建議： n 對 product backlog 中因需求變更產生的 stories 予以標註標記 由於需求的變更對產品或專案的執行會產生影響，除了在 planning meeting 討論是否接受該變更及其可能影響的產出物外，藉由適當的標註可以統計及 追蹤需求變更的次數與頻率，以有效地分析及管理需求變更在整個產品開發 生命週期所造成的衝擊。(sp 1.3) n 建立垂直及水平需求追溯 從需求至設計，且至程式碼並未建立垂直追溯性，且需求（stories）彼此之 間亦未建立水平追溯性。建議建立出雙向的需求追溯表，或利用工具來建立 及管理 story id 與設計、程式碼、及測試案例間的相關追溯，以利專案進行 及後續維護，並因應需求變更所可能產生的衍生成本。(sp 1.4) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 12 of 18 3.2.2 project planning (pp) 專案計畫的目的是在專案初期建立未來專案執行的完整規劃，根據專案的範圍與 需求對專案相關的工作、預算、時程、成本、資源、風險、訓練等項目進行計畫 與評估，並獲得專案相關人員之承諾，做為未來專案執行的依據與基礎。 組織現況分析：組織現況分析： 軟體開發生命週期採用scrum，每個sprint期間為兩週。(sp 1.3) 每個sprint所要執行的user stories記錄在ezscrum中，每個story會分解為多 個tasks。(sp 1.1) 每個story的規模預估是以story point為單位（通常盡量控制在121之間）。 (sp 1.2) project master及members在planning meeting進行規模與人力預估，每個 member依據經驗對每個story提出預估，經討論共識後決定預估值，並將每 個story拆解成多個tasks，並依照product owner所訂出的importance value 排序訂出每個task所需工時。(sp 1.4) 每個sprint的時程固定為兩週，所有tasks的時間安排在ezscrum中。(sp 2.1) 專案潛在風險與解決方法會在planning meeting或不定時與product owner 討論，有些可能會記錄在whiteboard，但未有系統地識別及監控追蹤。(sp 2.2) 專案資料使用google doc, mercurier等管理，在google doc中有要管理的 文件列表（目前只有部分文件）。(sp 2.3) 專案所需使用軟體或工具在wiki中有描述，ezscrum中亦記錄了每個task的 工作指派。(sp 2.4) 專案人員接受了ezscrum及相關技術的教育訓練，但未在專案初期對執行專 案人員所需的知識與技能進行規劃。(sp 2.5) 除scrum 生命週期流程文件所定義的專案成員外，其他會參與專案的相 關人員並未明確指出（如客戶、度量、建構管理、稽核人員）。(sp 2.6) 對專案的各項計畫內容分布在ezscrum, wiki。(sp 2.7) planning meeting 中會討論審查專案相關計畫，依可用資源進行調整，並 獲取專案成員的執行承諾。會議後會產生sprint backlog。(sp 3.13.3) 改善建議：改善建議： n 建立識別與監控專案風險的機制方式 專案中的風險對專案有可能產生顯著的影響，甚至造成專案的延誤或失敗。 建議在專案初始及執行過程中，有系統地識別及管理可能風險。目前雖然不 定時在會議中會討論到風險相關議題，但是並未有系統地識別及監控它們直 november 9, 2011 copyright 2011 by hermesoftware technology inc. page 13 of 18 到解決或關閉。可考慮建立風險議題行動事項表，據以追蹤及監控。 (sp 2.2) n 強化與整合專案計畫內容 建議應強化整合專案計畫內容，除了現有存在於 ezscrum 及 wiki 的內容外， 還應涵蓋專案人員所需的知識與技能、教育訓練、及專案成員以外的其他參 與專案之關鍵人員的規劃，以確保專案順利執行，亦容易維持專案資料間之 一致性。(sp 2.7) n 指派開發以外之相關人員責任 除了 scrum 流程提及的開發人員外，亦應指派負責建構管理(cm)、度量與 分析(ma)、流程與產品品質保證(ppqa)之專案人員。(sp 2.6) n 將 scrum 生命週期流程文件公布於 wiki 目前 scrum 流程雖為團隊共識，並有一份流程文件參考，但是該文件並未納 入正式管理。建議將包含 scrum 流程及詳細活動、人員責任分工說明發佈於 組織層級，以利於既有團隊人員或新進人員隨時可以查看及學習了解。(sp 1.3) 3.2.3 project monitoring and control (pmc) 專案監控之目的是在專案執行過程中，依據專案計畫對專案的時程、進度、風險、 資源等各種計畫中之項目進行管理，並持續追蹤專案所產生的各種問題及解決行 動直到結束。 組織現況分析：組織現況分析： 由scrum master每日召開專案例行性會議(daily meeting)，監控及追蹤專案 進度並討論各項議題。(sp 1.1, 1.2, 1.6) project members每日經由更新ezscrum中tasks的check-in/out以更新個人 進度。(sp 1.1, 1.2, 1.6) product owner and master 不定時檢查google doc與mercurie，以確定相 關專案資料是否適當儲存。(sp 1.4) 專案藉由planning, daily, review (demo), retrospect 等會議監控相關人員的 參與。(sp 1.5) 每兩週於每個sprint結束召開review (demo) meeting，進行完成產品的展示 簡報。(sp 1.7) 部分議題或行動事項記錄在whiteboard，但缺乏機制以確保所有行動事項皆 能持續追蹤制關閉結束。(sp 2.12.3) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 14 of 18 改善建議：改善建議： n 應確保專案所識別出的風險持續監控至結束 專案在執行的過程常會發生意外的風險與問題，採取適當機制系統性地追蹤 專案風險，降低風險發生的機率及避免風險的發生，或採取適當的應變措施， 以有效控管風險對專案的影響。(sp 1.3) n 建立議題或行動事項追蹤機制 建議可合併建立風險議題行動事項表，以有效管理及監控行動事項，促 進問題的解決與改善，並確保專案重要議題能持續追蹤至關閉為止。(sp 2.12.3) 3.2.4 process and product quality assurance (ppqa) 流程與產品品質保證之目的是以稽核的方式定期或不定期的檢視流程及工作產品 是否被遵循，同時收集組織成員對流程之意見與回饋，並持續追蹤不相符事項直 到修正完成或結束。 組織現況分析：組織現況分析： 組織層級設有ppqa流程及人員，以進行流程及產品之稽核。但目前採用 scrum流程的專案並未納入稽核檢查活動中。(sp 1.1, 1.2, 2.1, 2.2) 改善建議：改善建議： n 發展 scrum 流程的稽核表 建議應發展針對 scrum 流程稽核表(check list)，並且納入在組織稽核單位的 檢查活動中，以協助監控流程是否被遵循實施，工作產品(work product)是否 有按流程制定規則產出。(sp 1.1, 1.2) n 實際執行稽核，追蹤與溝通問題 稽核單位在執行稽核的過程中，應將發現的問題記錄成為稽核報告，並持續 的追蹤與溝通相關問題，同時應將稽核結果通知相關主管，以利問題的解決 與改善。(sp 2.1, 2.2) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 15 of 18 3.2.5 configuration management (cm) 建構管理之目的在建立專案工作產品之清單及其儲存與管理的方式，並對重要之 工作產品建立基準與變更控管，以保持專案相關產出的完整性。 組織現況分析：組織現況分析： google doc中有屬於建構項的部分文件列表，wiki中則談到部分專案文件 及其儲存方式。(sp 1.1) 專案以郵件溝通部分與建構管理有關的事項，如版本編號規則、公開發行準 則。 (sp 1.2) 文件使用google doc， 程式碼使用mercurier來進行控管。(sp 1.2) 每週會對程式碼建立兩次基準 ，作為內部發行之用。通常每兩週（里程碑） 會建立外部發行的基準。(sp 1.3) google doc會對文件的變更予以紀錄，並產生revision history。程式碼 check-in的時候會給予bug/issue id的註解。(sp 2.1) google doc 對不同的人員有不同的權限控管，程式碼的變更必須通過一個 指定人員驗證才能check-in到centralized repo。(sp 2.2) mercurier系統自動產生建構項的異動紀錄。(sp 3.1) 改善建議：改善建議： n 確保訂定完整建構管理項目（包含程式碼與文件） 專案於執行過程中會產出許多文件及程式碼，應在專案的規劃時即將其中重 要而有保存列管價值的項目列出，將這些項目納入建構管理，以有效管理建 構項目。目前雖然在 google doc 有列出部分文件清單，但是並不完整。 (sp 1.1) n 專案主要交付文件建議納入比較基準 對於專案主要交付文件項目(如 srs, sdd 等)，除成為建構項目外，建議亦 納入比較基準內進行管控，輔助維持專案開發內容之一致性。(sp 1.3) n 加強建構項目的變更管理 對於因需求變更所產生的建構項目變更，應在 check-in 的註解中加註 story id，以增進建構項目之安全性與加強變更之控管，亦可追溯因需求產生的變 更。(sp 2.1) n 執行建構稽核 對建構活動及比較基準應盡行稽核，以確保比較基準的正確與完整性。此工 作亦可交由組織的稽核人員負責。(sp 3.2) november 9, 2011 copyright 2011 by hermesoftware technology inc. page 16 of 18 3.2.6 measurement and analysis (ma) 衡量與分析之目的在訂立組織或專案衡量目標，並收集及累積專案執行中之相關 數據與經驗，並對收集到的資料進行分析，以持續改善流程。 組織現況分析：組織現況分析： scrum流程有描述與burndown chat有關的度量項。(sp 1.2) 部分度量項如story point, sprint burndown chart, task burndown chart會經 由ezscrum收集呈現。(sp 2.1, 2.3) 改善建議：改善建議： n 依據專案需求訂定度量目標及度量項 專案通常會有一些從客戶面或執行面上對於時程、成本、或品質上的要求 （如 bug rate, bug trend, effort/cost deviation, etc.），這些要求並非僅限於 開發面或是由 burndown chart 所能涵蓋。因此，專案應依據這些需求訂出適 用於專案的度量目標及對應的度量項，並指出這些度量項的收集方式與時間 點，及如何分析與溝通結果，以便之後在專案執行過程或結束時收集這些數 據。(sp 1.11.4) n 收集與分析度量相關數據 依據組織所訂出的度量目標，收集與分析該目標之相關數據，並將分析結果 紀錄及保存，且與相關人員溝通分享。藉由專案之度量資料的收集，未來可 用來調整預估參數，讓預估更為精準，同時也能藉以分析流程中需要改善的 地方。(sp 2.12.4) 3.2.7 一般一般目標目標 gg2 與與執行方法執行方法(generic practice) 由於每個流程領域都有相同的一般目標與執行方法要求，因此綜合所有流程領域 的 gg2 現況與改善建議如下。 組織現況分析：組織現況分析： 智通所本身已建立ml2及ml3各流程領域的組織級政策，其政策可以涵蓋及 適用於網路影音組在ml2流程領域的改善需求。 (gp 2.1) november 9, 2011 copyright 2011 by hermesoftwar