基于CMMI與SCRUM的任務顆粒度劃分

中間件公司2008年通過了CMMI L3認證。在產(chǎn)品項目開發(fā)實施及準備認證的過程中，項目開發(fā)團隊與質(zhì)量管理團隊的觀點碰撞沖突不斷。項目開發(fā)團隊希望集中精力處理技術(shù)細節(jié)、研究產(chǎn)品開 發(fā)，質(zhì)量管理團隊按照CMMI L3對質(zhì)量管理體系的要求，建立項目管理過程中需要形成的大量項目文檔模板，并跟蹤檢查項目文檔記錄，兩個團隊工作目標、方向及重點不同，成為雙方討論的 焦點。

從產(chǎn)品項目團隊的角度來看：項目組不但要完成待發(fā)布版本的軟件程序及軟件工程文檔，還要根據(jù)CMMI L3對質(zhì)量管理體系的要求出具項目過程文檔，工作范圍增加了，又增加了項目管理過程可視化、質(zhì)量管理文檔化的要求，進度和成本也必須進行相應的調(diào)整。項目 組需要在產(chǎn)品發(fā)布的市場壓力、有限的資源限制下，減少項目開發(fā)的工作內(nèi)容，按照CMMI L3要求做好項目及開發(fā)過程資料整理，實現(xiàn)知識的傳承、文檔的可追蹤及度量數(shù)據(jù)的分析。這個調(diào)整本身導致項目經(jīng)理、度量員、配置管理員、質(zhì)量保證員在正常 軟件工程領(lǐng)域之外，必須要有額外的負擔，形成項目管理過程域及支持過程域所要求的文檔。其中項目管理過程域涉及項目計劃、項目監(jiān)督和控制、風險管理三個過 程；支持過程域涉及配置管理、度量和分析、過程和產(chǎn)品質(zhì)量保證、決策分析和解決方案四個過程。

在這個過程中，產(chǎn)品項目團隊與質(zhì)量管理團隊互相促進和推動，盡力朝著融合產(chǎn)品開發(fā)和質(zhì)量管理的要求前進，最終我們在CMMI認證的最短極限時間內(nèi)通 過了認證。但通過認證不是我們追求產(chǎn)品質(zhì)量的終極目標，在執(zhí)行質(zhì)量管理體系過程中發(fā)現(xiàn)的問題、項目組面臨的成本、進度、文檔壓力帶來的情緒困惑等。一直推 動我們進行更多質(zhì)量管理方法及工具的研究。

其中，業(yè)界熱議的敏捷開發(fā)一直給項目研發(fā)團隊帶來極大的誘惑，比如SCRUM，提倡頻繁運用“檢查-調(diào)整”周期，加速創(chuàng)造更具價值的軟件。項目管理 使用產(chǎn)品Backlog和Sprint Backlog，按照迭代，以Burndown圖管理項目進度，不需要編寫繁雜的項目管理過程文檔，而是強調(diào)從控制到授權(quán)、從契約到合作、從文檔到代碼的 工作模式轉(zhuǎn)變，整個項目管理過程由Sprint計劃會議、Scrum簡會、Sprint評審會議和Sprint回顧會議組成。所有的實踐圍繞著一個迭代、 增量的過程骨架。

我個人認為這是項目管理過程域全力圍繞工程過程域的過程框架，并沒有考慮項目管理過程域的資產(chǎn)追蹤、知識傳承和數(shù)據(jù)分析，以及支持過程域。我們需要 警惕作為Scrum核心、也是Scrum團隊強大生產(chǎn)力的基礎-對團隊處理和解決問題能力的檢驗、識別及持續(xù)改進。而Scrum是敏捷管理的一種實踐框 架，只定義了高層次的信息系統(tǒng)開發(fā)項目的管理流程，不涉及具體開發(fā)方法、人員的有效溝通技巧等，仍然需要其它領(lǐng)域相關(guān)理論及技能的補充。

關(guān)于項目計劃，CMMI提出了建立和維護涉及項目范圍、估算、項目生命周期、工作量、成本、進度、風險、數(shù)據(jù)、資源、所需知識和技能、利益相關(guān)者的 全面的計劃；而敏捷開發(fā)只聚焦在了產(chǎn)品和Sprint的任務分解及工作量估算，作為項目管理的最小單元-任務：Sprint任務細分標準為每項耗時約 4~16小時，超時視為尚未恰當界定的任務。Scrum提倡使用經(jīng)驗性過程方法控制軟件開發(fā)項目：經(jīng)驗性過程控制方法的三大支柱是可見性、檢查及適應，適 用于復雜問題處理；預定義過程控制不適用于復雜問題處理，往往造成對不合格產(chǎn)品進行大量昂貴的返工。

CMMI注重前期的計劃、設計及跟蹤管理，敏捷注重任務細分、迭代快速執(zhí)行，前者更注重文檔，后者更注重軟件，在不可能拋開CMMI的前提下，本著 求同存異的原則，我個人認為，CMMI與敏捷開發(fā)最終都要求有一個詳細的任務分解文件，旨在統(tǒng)一項目所有相關(guān)人員對項目任務的一致認識。雖然細分任務的要 求一致，但CMMI和敏捷對達到細分任務的過程要求不同。

在細分任務的過程中，SCRUM提倡召開Sprint計劃會議，通過頭腦風暴的方式，將一個月左右的迭代任務細化到4~16小時的單個任務顆粒度， 形成項目的詳細月度迭代任務計劃。在這個過程中所有的項目成員應該已經(jīng)無意識的、但卻自然而然的運用了CMMI項目管理過程域的實踐要求，考慮了資源、人 員技能、項目風險、利益相關(guān)者、進度、成本、數(shù)據(jù)等很多方面，只是不像CMMI要求的必須形成文檔。所以不管哪種項目管理模式，團隊最終都要形成一個極詳 細的項目任務計劃。這應該是兩者的共識。也是項目管理團隊極力要達到的目標。

因為兩者形成項目任務計劃采用的方式和流程不同，除了詳細任務分解計劃，使用CMMI過程框架的質(zhì)量管理體系必須規(guī)定若干附加的計劃文檔，比如：工 作量估算文件、進度估算文件、費用估算文件、進度計劃、風險計劃、質(zhì)量保證計劃、度量計劃、資源計劃、培訓計劃、配置管理計劃、測試計劃、關(guān)鍵依賴關(guān)系、 評審計劃等等。但CMMI同樣沒有提供實踐這些方面的專業(yè)方法及工具。作為實施CMMI的公司來講，文檔的繁簡程度要靠公司自己根據(jù)組織及項目實際情況制 定，并建立一些針對特殊情況免于執(zhí)行的剪裁偏離指南。這應該是為敏捷之路提供了一個方便之門。

而且據(jù)SCRUM大師肯.施瓦伯及CMM的開發(fā)者之一馬克.波爾克的分析，SCRUM能夠滿足CMM L2的全部KPA及CMM L3的大部分KPA，沒有滿足的KPA主要是處理實踐方法制度化的部分。因此SCRUM減輕了項目和組織的文檔及管理成本。

由此看來，在SCRUM提倡將任務顆粒度控制在4-16小時的基礎上，通過4-8小時的Sprint計劃會議討論時間，運用CMMI提倡的估算、項 目生命周期、工作量、成本、進度、風險、數(shù)據(jù)、資源、所需知識和技能、利益相關(guān)者等多角度考慮問題，制定出項目組為期一個月的迭代周期的任務目標，并在 Sprint計劃會議上同時附加產(chǎn)生格式簡潔的風險、成本、估算等文件，積極的減輕項目組文檔負擔，充分討論項目組任務列表，與所有成員達成共識。從而可 以為項目迭代周期的順利完成打好可控的項目計劃基礎。