在軟件企業實施敏捷和CMMI的績效管理方法(2)

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

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

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

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

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

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

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

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

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

原文轉自：http://www.kjueaiud.com