由於稍早就聽說CMMI會在v1.3提到對於Agile作法的解讀，因此拿到CMMI-Dev-v1.3技術報告，首先就看了有關於Agile的部分。讀的的感覺是，這些似乎是SEI被強迫為Agile approaches而寫，寫出來的內容，SEI自己也認為是僅供參考，可有可無。

另外，想用Agile然後去規避文件作業，在CMMI的框架之下，還是行不通的，而且文件修改可能更加頻繁，尤其是PP、PMC、與PPQA...，因為結合了每日的活動...所以可能變成天天改。一個專案下來，計畫可能跟發展的產品一樣，是一天一個版本....

有關於CMMI-Dev v1.3中，對於Aigle環境，使用CMMI的解讀，相關素材，謹翻譯供參考。原文請自行參閱CMMI v1.3技術報告。

-----------------------------------------------------------------------------------------------------------

於運用Agile作法時，解讀CMMI
Interpreting CMMI When Using Agile Approaches

CMMI常規設計的目的是在各種不同情況下提供價值，並且以通用的用語來陳述。由於CMMI並不對所有特定的發展背書，只提供作法特有之少量資訊。因此，對於沒有在類似其目前所處環境中實作CMMI先前經驗的人員，可能認為解讀並不夠直覺。


為了協助該等使用Agile方法的人員，於其所處環境解讀CMMI，已在選定的過程領域中增加了註解。這些加入的註解，通常是列於CMMI-DEV中的下列過程領域的簡介註解中： CM, PI, PMC, PP, PPQA, RD, REQM, RSKM, TS, 及VER。

這些註解均以“In Agile environments (在Agile環境中)“為開頭，並列於範例框中，以協助您可以輕易地辨識它們，並提醒您，這些註解乃是如何解讀常規的範例，因此，它們對於過程領域，既不需要也不充分。


目前有多種的Agile作法。 “Agile環境(Agile environment)” 與 “Agile 方法(Agile method)”只是所有忠於Manifesto for Agile Development 之發展或管理作法的略示式[Beck 2001] 。

這類的作法由以下的各點所具體描述：
--客戶在產品發展的直接參與
--多重發展疊代的使用，以知悉並演進產品
--客戶願意分擔決策與風險的責任


許多發展與管理作法能分具這些特性的一項或更多，但還不能稱為“Agile”。例如，有些團隊可以論證是屬“Agile”，就算未使用用語Agile。就算你未使用Agile作法，你還是能在這些註解中找到一些價值。


在使用這些註解的時候，請務必謹慎。你對於過程領域的終極解讀，應與你所處情況的特殊性配適，包括當面全符合CMMI過程領域目標與常規的時候，你組織的業務、專案、工作群組、或團隊目標。就如稍早所提到的，這些註解應被看做是例子，而且對於過程領域的實作，既非必要亦不充分。


在Agile發展作法上，所給定之指導的通用背景與動機，可於SEI技術短文CMMI or Agile: Why Not Embrace Both! [Glazer 2008]中找到。

-----------------------------------------------
以下是各PA於Agile環境中作法的解讀...

CM：
在Agile環境中，由於要支援經常性變更、經常性構築(通常是每日)、多重基準、以及多重CM支援工作場所(例如，對個人、團隊、甚至是成對程式編寫)，組態管理(CM)是屬重要。如果組織做不到下列各項，則Agile團隊可能陷入泥沼：1) 自動化CM (例如，構築腳本(build scripts)、狀態記述、完整性檢查)，以及2)將CM當成單一標準服務集來實作。在啟動的時候，Agile團隊應識別將負責CM正確實作的個人。在每一個疊代開始的時候，CM支援的需要，要再次確定。CM以最小化團隊的分心，使工作完成為重點，謹慎地整合到每一個團隊的節奏中。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

PI：

在agile環境中，產品整合是一經常性、通常是每日的活動。例如，對於軟體，工作程式碼持續地以稱為“持續整合”的過程，加入到程式碼庫中。除了進行持續整合之外，產品整合策略能說明，供應者所提供的組件，將如何融入其中，功能性將如何構築(以分層vs.“縱切片”)，以及在何時要“重構(refactor)”。應於專案早期即訂定該策略，並予以修訂，以反映組件介面、外部饋送、資料交換、以及應用程式介面的演化與浮現。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)


PMC：

SP 1.5 Monitor Stakeholder Involvement
在Agile環境中，專案產品發展活動中，受到支持之客戶及潛在終端使用者的參與，對於專案成功極其重要；因此，專案活動中，客戶與終端使用者的參與，應受到監視。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)


PP：

對於產品線，多種的工作活動集，能自本過程領域的常規中獲益。這些工作活動包括核心資產的產生與維護、將以該核心資產構築之產品的發展、以及調和整體的產品線努力，以支援與協調交互關聯之工作群組及其活動的運作。在Agile環境中，增量式發展的履行，涉及較傳統之發展環境中，更為頻繁實施的規劃、監視、控制、與重新規劃。雖然整體專案或工作投入的高階規畫通常都會建立，但是團隊還是要估算、規劃、並以一次一個增量或是疊代，實行實際的工作。團隊通常不對專案或疊代未知的部分做預測，除了預判的風險、重大事件、以及大規模的影響與限制條件。估算值反映出影響完成該疊代之時間、投入、資源、以及風險之疊代與團隊特定的因素。於每一疊代期間，經常性地實施(例如，每日)團隊規劃、監視、以及調整計畫。計畫的承諾，會在每個疊代規劃期間，工作指派與接受、使用者故事情節細述或估算、以及工作從受到維護之工作積存中，移至疊代等時候展現出來。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

PPQA：

在Agile環境中，團隊傾向於將焦點聚集在疊代的立即需要上，而非較長期的且更廣泛的組織需要。為了確保抓住客觀評估的真意，使之具有價值，並且有效率，要儘早討論下列事項：(1)客觀評估如何完成，(2)要評估哪些過程與工作產品，(3)評估的結果要如何整合到團隊的節奏中(例如，做為每日例行會議、檢核表、同儕審查、工具、持續整合、回顧等等的一部分)。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

QPM

SP 1.1 Establish the Project’s Objectives
專案品質與過程績效目標的例子包括：

--將變更請求積存的規模，維持在標的值之下。
--以標的日期，改善Agile環境中的速度至標的值。
--以標的日期，將閒置時間降低x%。
--時程落後維持在指定的百分比之下。
--以標的日期，降低總生命週期成本為指定的百分比。
--在不影響成本下，降低交付給客戶之產品的缺陷至10%。


RD：

在Agile環境中，客戶需要與想法，會反覆地徵詢、詳述、分析、以及確認。需求以諸如使用者故事情節、情境、使用案例、產品積存(product backlogs)、以及疊代結果(在軟體情況下為工作程式碼)的形式記錄。哪項需求會在給定的疊代中予以處理，是以風險評鑑、以及其在產品積存中相關的優先權來驅動的。那些需求(及其他工作物)的細節要予記錄，是由協調(團隊成員間、團隊間、以及後續的疊代)之需要，以及已知事物遺失之風險來驅動的。當客戶參與團隊之中時，仍然會有分離客戶與產品文件，以容許多種解決方案之探索的需要。當解決方案出現的時候，導出需求的職責，會分配給適當的團隊。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)


REQM：

在Agile環境中，需求透過諸如產品積存、故事卡、螢幕實體模型之類機制予以溝通與追蹤。對需求的承諾，若非以團隊集體式做出，即是由獲授權的領隊做出。工作指派是定期式(例如，每日、每週)根據進度調整，並成為需求與解決方案顯現的改善理解。需求與工作產品之全面性的追蹤性與一致性，是經由已經提及的機制，以及諸如“回顧”與“展示日”之類的疊代啟始或疊代結束活動等處理的。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

RSKM：

在agile環境中，某些風險管理活動是原本就嵌在所使用之Agile方法中的。例如，某些技術性風險可透過鼓勵實驗(早期“失效”)或執行例行疊代之外的“大釘子”來處理。然而，風險管理過程領域鼓勵採取更為系統化作法，以管理風險，包括技術性與非技術性風險。這樣的作法能整合到Agile的典型疊代中，並符合節奏；特別是，在疊代規劃、工作估算、以及工作驗收的期間。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

TS：

在Agile環境中，焦點置於早期的解決方案探索上。透過使選擇與折中決策更為明顯的方式，技術解決方案過程領域，既採各別方式，亦隨時間的推移，協助改善該等決策的品質。解決方案可從功能、特徵集、或其他能促進產品發展之組件的角度來定義。當團隊外的某個人會在未來憑藉該產品來工作、釋出資訊、維護日誌、以及其他資料，通常會含括於該已安裝的產品中。為了支持產品的未來更新，(折中結果、介面、以及採購的部件之)理由闡述要予以捕捉，以使產品存在的理由，能夠有更清楚的了解。若獲選的解決方案屬於低風險，則正式捕捉決策的需要，就會大大地降低。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)


VER：
在Agile環境中，由於客戶參與經常性釋出，驗證與確認相互支援。例如，缺陷能引發雛型或早期釋出版本，早產而未能通過確認。相反地，儘早且持續地確認，協助確保驗證適用至對的產品上。驗證與確認過程領域，協助確保受審與受測工作產品、使用之方法與產品、以及納管介面等選擇的系統作法，驗證與確認協助確保缺陷的儘早識別與處理。產品愈複雜，則就愈需要系統化的作法，以確保需求與解決方案間的相容性，以及需求和產品使用方法的一致性。(參閱Part I中“於運用捷式作法時，解讀CMMI。”)

SP 1.1 Select Work Products for Verification
驗證方法的例子包括下列各項：
--軟體架構評估與實作符合性評估
--路徑涵蓋測試
--負載、壓力、以及效能測試
--基於決策表的測試
--基於功能解構的測試
--測試個案再用
--驗收測試
--持續整合(亦即，儘早識別整合議題的Agile作法)

----------------
引文:

看完林兄所提供之資訊，小弟仍無法清楚了解，Agile之開發模式下，如何符合CMMI各流程目標。
是故，若專案以Agile模式開發時，現階段似乎不容易符合CMMI各流程領域(PA)之目標與要求~

這個部分，您應該可以請教一下貴公司的LA，她們可以判斷。

其實能不能符合CMMI要求，就是看CMMI的架構要什麼，而不是Agile要什麼。而個人也說了，這些各PA的Agile環境註解，看來是SEI不得已之作。否則SEI不需要強調"that these notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area. (這些註解乃是如何解讀常規的範例，因此，它們對於過程領域的實作，既不需要也不充分。)"而且這段話，還提了兩次(就是在"強調"的意思)。

既然要實作CMMI、要符合CMMI的要求，以取得CMMI的評鑑通過，當然是要從CMMI的角度來看，而不是Agile的角度來看，更何況，CMMI所描述的是組織的成熟度，而不是軟體。所以根本也沒有所謂"現階段似乎不容易...云云"。除非SEI願意把CMMI的架構的鬆緊度降級吧，但是，如果那麼做，是否能夠支持美國國防部的專案，就不得而知了。

又，以SEI所提出來的註解來看，也顯示出，SEI希望，Agile環境能夠注重文件(管理計畫、需求、設計之類的文件)、真正地去重視與掌控風險，要有序地工作，所有的變更，都能立刻真正有效地反映出來(例如，在文件中)。

----------------
引文:

有關於Configuration Management，FCA/PCA在CMMI v1.1一個字也沒提，在CMMI v1.2，列於系統工程的環境部分，在CMMI v1.3系統工程與軟體工程都要做，有趣的是，所謂的提到，都只是一段描述性的文字而已。不論是for Dev或是for ACQ通通都一樣。照說，ACQ是獲取者角度，這兩者應該談更多才對，可惜CMMI-ACQ裡沒有強調，也沒有提詳細做法。在美軍的軍規與軍方手冊中，認為不論是系統工程或是軟體工程，此兩項稽核是design-based acquisition一定要做，而performance-based acquisition只做FCA。

業主/獲取者如果同意開發者(廠商)使用Agile Engineering開發軟體系統，那麼，在軟體驗收測試之後，在交付之前，就一定要做好FCA與PCA，並訂定產品基準，免得弄到最後又說，廠商給的不是業主要的，給的產品與需求不相符，產品與文件不一致。

----------------
引文: