本文的英文版爲CMMI官方推薦文章《The Way Forward A Strategy for Harmonizing Agile and CMMI》，發表於2016年的CrossTalk。趙星漢學習兼翻譯於2020年5月
摘要： 敏捷和CMMI就像是完全相反的兩種範例——或許它們是否能互相融合或增強？敏捷和CMMI的臨界點是什麼？以及爲什麼是這樣。在LinkedIn的博客裏，敏捷或CMMI的支持者們都是如此的極力反對另一個學派的觀點，以至於讓兩方理性的共存是一個不可能的任務，這種情形一直持續到如今。一種新的思維方式由Ivan Jacobson在Software Engineering Methods and Technology (SEMAT) and Essene Kernel提出，這種想法有助於解決這個難題。
準備這篇論文的目的是從實際出發說明發表於《軟件工程方法與技術以及精華內核》的這種思考方式,並將CMMI架構和敏捷方法這兩種截然不同的方法之間的問題在一個統一的架構應用內融合。
基礎的機會價值主張，擴展和加速SEMAT and its Essence Kernel的傳播和採用，將通過系統地將其應用到領先框架和方法的受衆和用戶羣中來實現，從而影響和吸引新的支持者到SEMAT and Essene Kernel，以及它的思考方式，工作方式…最終轉化他們。如今擁有數量最多支持者的方法架構是敏捷和CMMI,所以我們提出一種方法來調和這兩者的緊張關係。現在的問題是，這兩者的協調工作是否已經實現完成，或者正在艱難的推進中。
CMMI
CMMI是一個過程成熟度框架，而敏捷是一種軟件開發方法。Watls Humphrey將軟件過程看作製造軟件產品的工具，方法和實踐的集合，這裏過程的質量大體的決定了軟件產品的質量。而在敏捷中，敏捷和開發人員和用戶將保持在一個相對封閉的環境，並專注於所分配的當前工程的必須的需求。任何其他的人和事件都被排除於環境之外。這一點與CMMI的從上至下的方式，全局範圍聯動，合規驅動和以組織爲中心的文化形成對應。倘若與CMMI成熟度框架進行適當的融合共存，一個敏捷實施或許可以看成CMMI實施的一個實例。但是，大部分敏捷實踐並不滿足CMMI的過程要求，哪怕是最低的CMMI的2級過程要求。
軟件的能力成熟度模型（CMM）爲軟件的過程改進提供了路線。而後能力成熟度模型集成(CMMI)將其擴展到系統和軟件工程過程改進的獲取、開發和維護方面。
在資本和垂直整合的傾向下，CMMI被全世界範圍內的政府，軍隊和商業組織作爲過程改進的標準採用。CMMI是一個通過過程績效來聚焦保證產品質量的最佳實踐框架。從最開始，CMM就避開基於實踐的方法，而是採用整體框架。
從1980年代晚期的創新者和早期使用者開始，以及1990年代的逐漸作爲主流，如今CMMI一直處在市場優勢並蠶食落後者的市場份額，這時他們的主任評價員制度，如同工會的成員一樣，試圖通過與CMMI評估相一致而保持他們的市場份額，卻忽視了更加重要的軟件工程，軟件產品工程，以及軟件工程管理等以實際爲基礎的方法。
敏捷
而作爲“新貴”的敏捷卻並非如此，它的相對自由的市場，橫向整合理論在市場中取得了如同“火山爆發”一般的巨大的顛覆性效果。敏捷在程序員中獲得了更多的支持，它爲從業者提供了一套可實施的方法，而不是簡單的一個爲企業中層設計的框架。不僅如此，敏捷還授權並賦予程序員對於他們工作路線的決策權，而這些以前在CMMI中是中層管理者的權限。總的來說，敏捷的價值在於選擇的自由性,以及交付形式的改革，同時拒絕和貶斥合規性概念。簡單來說，敏捷連接了做工作的程序員和用工作產品的用戶，而CMMI連接了檢查工作的中層管理者。
助推CMMI的價值主張
CMMI並不是沒有價值，儘管美國防禦部門（US Department of Defence)和一些原先的資助放棄了CMMI，但它擁有自己的支持者，並應得到更多的支持。缺乏穩定的資金支持，CMMI就像一艘滿載珍貴貨物的大船卻找不到港口靠岸一樣，直到重新修正它的機會價值主張。
這就是CMMI面臨的窘境，在一方面被低估，一方面卻被充分重視之間維持着平衡。透過這些掙扎，一些人致力於擴展CMMI的價值範圍，並通過新的思維方式來重申CMMI的機會價值主張。現在正是時候來超越這個日益萎縮的市場，超越敏捷的分裂以及過度的主任評價員制度來踐行Ivan Jacobson推出的對解鎖CMMI更大的價值的可行易行的主張，並擊破基於實踐的方法和總體框架之間的限制。很少有組織發現他們現行的管理策略在敏捷小組中能正常適用的情況。進一步說，CMMI對於授權開發團隊解決日常工作中遇到的問題幾乎沒有幫助。
協調的路徑
一個敏捷的實例是不可能在非特定設計的情況下符合CMMI的規定的。一個敏捷的組織需要在目的和資源上做出詳盡的規定來滿足CMMI的規定。必須通過人員提供基於過程的證據,基於過程實施的驗證，以及通過測量結果進行基於產出物的確認。這時一個艱鉅的任務，而敏捷在開始時就是缺乏承諾的。
類似的，CMMI也不能在非特定設計的情況下就借用敏捷。相反，CMMI架構應該對敏捷的導向、內部觀察、從下往上，本地化，需求牽引，小組集中文化和它的敏感性和自我管理進行準確的協調。此外，敏捷也應該對CMMI以及它的從上至下，全面研發，合規驅動，組織集中文化進行協調。所有這些也是一個艱鉅的任務，而它成功的可能性取決於目前不具備的領導力。
迴避一下現在宗教一般的狂熱，或許我們需要一個立竿見影的方法來對敏捷和CMMI進行評估。例如，那種方法對處理目前面對的賽博安全的挑戰更有效果？同樣的，那種方法能處理更加嚴酷的其他挑戰？如果不是簡單的在敏捷和CMMI中保持絕對的的中立，那麼這個問題的答案可能會圍繞實踐中賽博安全挑戰所需要的各種專業知識來界定,比如軟件保證（Software Assurance）、可信性和嚴格性等方面。敏捷和CMMI如何面對緊縮的挑戰？敏捷依靠它的內部觀察、自底向上、本地需求牽引，小組集中文化來解決那些緊縮。他們如何積累可信度和軟件保證？
- 不論公司或者政府，現在的經濟氣候就是一種緊縮。這種緊縮和可負擔的挑戰開始於21世紀，對公司和組織起到了相當大的約束作用。與當下的時代保持一致，下一代軟件工程的短期目標是驅動系統和軟件工程能夠利用智能和可信技術達到“做的更多，花費更少，時間更短”的效果。非常明顯的緊縮目標是敏捷的長期手段。
- 軟件保證只有在可信的前提下才有意義，也就是說，覆蓋關鍵需求的可信軟件部分需要特殊的軟件部件、子系統和系統。軟件保證在可信方面有兩方面能力的要求，即生產可信軟件的能力以及確認可信軟件的能力。每一方面都對工程和技術層面有着嚴格的要求。軟件保證的分層防禦方法的核心是構建內安全性（Build Security In）以及嚴謹並可驗證的正確運用（0，1）斷言，沿構成主程序的多個主要子程序進行查驗，這些子程序都應只有一個入口和出口。
架構 vs 方法
原始的CMM集中於軟件過程，它的原型在1988年公佈，目前已經廢棄。CMMI公佈於2000年，致力於軟件開發，並將範圍擴展到系統工程、產品採購（product acquisition)，綜合團隊(integrated team)以及需求開發方面。CMMI現在劃分成了三個組成部分，成爲了保證一個組織在軟件開發（CMMI-DEV 2006），採購（CMMI-ACQ 2007）和服務（CMMI-SVC 2009）三方面能力的基礎。現在CMMI的現行版本是1.3，它公佈於2010年12月。（目前已經是2.0版本）
因爲其起源，CMMI缺乏對業務調整與戰略規劃的明確關聯，缺乏對企業重要價值的來源。另外，利用其從上之下的命令和控制決策制定，CMMI可以在一個封閉系統中運行的很棒。而在一個開放的組織環境中，有更多的自下而上的基於全體贊同的決策，其他選擇或許更合適。當在CMMI的價值上附加上外部壓力時，敏捷和迭代開發的優勢在20世紀70年代起被認知，並在“六西格瑪”中被廣泛採用.CMMI的資源和價值區間被廣泛質疑和測試。甚至Watts Humphrey也表示了關注。
被問及CMMI前進的方向時，Watts Humphrey贊同在高成熟度組織的效率方面存在問題，特別是在流程效率基線的使用和主任評價員模型方面。他爲“程序上的（the what）”和“可操作的（the how）”的過程做了仔細的區分。但是，程序上的過程需要職能機構去貫徹；而可操作的過程需要教導一個自我管理的可信賴的勞動力去應用它的方法。
與培育革新的需求相一致，官僚性質的從上至下的評價驅動的合規可能讓位給自下而上的多元化自我指導團隊，賦予他們權力和自主權。正如CMMI聚焦於在過程執行中確保產品質量，敏捷處理如何在定義好的方法下構建軟件，這個方法的重心在於提升顧客的滿意度。相似的，六西格瑪後來也提供瞭如何着重於在數據驅動決策和減少浪費的方面使用加工品模板，測量方法和控制圖。
CMMI 價值
卡內基梅隆大學軟件工程過程成熟度框架由五個級別組成。初始級別的特徵是沒有有序的過程和缺少期望。第二級是定義了管理軟件支出、日程和變更的過程，維持項目承諾過程所需要的一切。第三級定義了技術過程，比如，系統設計和在組織中輔助其應用的技術轉變機制，比如，軟件工程過程組。第四級有初始過程和產品測量方法。第五級利用系統的過程測量來持續改進過程和產品。
CMMI的價值能在系統的角度得到更全面的認知，並最終取決於對一個企業的軟件價值增長。軟件價值更大的視角需要考慮系統工程和與其密不可分的軟件工程中的必要的角色。總的來說，CMMI的價值是起到對於戰略軟件管理的促進作用。戰略軟件管理主要是圍繞什麼是顧客最需要的，調整最好的能力去提供它，理解正確的實踐，測量它的關鍵參量，挑選最重要的承諾變化，計劃持續改進，提升改進的能力，以及堅持到底。
(注：文章這裏使用的是strategic software management，strategic可以翻譯成“關鍵”，我覺得翻譯成關鍵軟件管理也不太對，所以這裏我都翻譯成了“戰略軟件管理”，歡迎討論)
圍繞戰略意圖、手段和測量結果，CMMI的價值能夠被戰略軟件管理所撬動。戰略意圖聲明可以直接在組織及其行業部門的業務管理，流程，工程和運營文化驅動因素的背景下進行闡述。CMMI與它的本地軟件工程過程組（SEPG）及它的全球範圍的主任評價員促進了一種組織文化，專業性的環境，和爲維持世界範圍內的使用和培養專業使用所設計的過程框架。Ivan Jacobson提出的思考方式提供了一種在全局範圍內解鎖CMMI隱含價值的手段。
SEMAT and the Essence Kernel
SEMAT formulation and its kernel是軟件工程的本質和共同點。七個維度的共同點用Alpha（含義在後文有解釋，這裏的alpha快搞死我了）表示，連接到每一個Alpha的前進的序列狀態是其基礎。這些Alpha和狀態獨立於特定的方法、實踐和工具，並因此具有不依賴任何方法和實踐選擇而引導前進和評估任何軟件工程狀態的能力。這個結果對於管理人員是友好且易於理解的。
- 客戶(customer)空間由利益相關者的共同願景構架，以構想出具有令人信服和相應結果的機會的合理價值主張。
- 解決方案(solution)由利益相關者綁定，這裏的利益相關者同意了需求和用戶故事，以及有利於操作和使用的軟件系統結構。
- 工作(endeavor’s work)是由一支精挑細選，準備就緒的團隊執行的，並且是一種基於既定原則和基礎的工作方式
這些Alpha狀態檢查點是導向性指標，這些指標爲這些Alpha狀態建議令人信服和滿意的結果。產品工作上的檢查點被加上，是爲了集成可信的軟件工程期望。爲了更好的結果，請遵循以下期望，取得基於實踐的方法與總體框架之間的更好的平衡，全面的思考並實施本地化：
- 利益相關者之間達成一致並共享同一願景。
- 建立一個機會價值主張，該主張由利益相關者的願景來實現。
- 需求和用戶故事是相關和被接受。它們都是爲了實現願景。
- 軟件系統結構已經確定，該結構由一個用於指導軟件實現領域特定的架構組成，並且該軟件實現是準備就緒的且實施起來沒有技術債。
- 團隊成員間通力合作，共享工程願景，準備執行共同的願景，軟件工程過程，軟件項目管理，軟件產品工程，操作支持，和領域特定結構過程，方法和工具。
- 團隊的工作方式已經建立了軟件工程過程、軟件項目管理、軟件產品工程和操作支持的堅實基礎。
- 工作開始前，所有的準備工作應該完成，準備工作包括一致的用戶需求，被認可的用戶故事，意見統一的利益相關者，堅實的工作方式基礎。
- 所有工作產品依據已定義的標準進行檢查和準備，這個標準在完整性、正確性和一致性方面應是最佳的。
Alpha是Abstract Level Progress Health Attributes的縮寫。簡單但是高效，這些明確的alpha和它們前進的自然狀態在引導一個工程實施和引導目前已經失去前進方向的軟件工業時非常有用。更加特別的是，alpha和它們的狀態序列（表1）包括：
- 利益相關者 - 被認可的，已代表的，已參與，一致同意的，已被滿意部署的，已被滿意使用的（這裏翻譯的不好）。
- 機遇 - 已經識別的，軟件需要的，價值確定的，有活力的， 已確認的， 已形成好處的。
- 需求 - 已構思的，已綁定的，一致的， 已接受的， 已確認的， 以滿足的。
- 軟件系統 - 結構已選擇的， 已證明的， 可使用的， 已就緒的， 可操作的， 已廢棄的。
- 團隊 - 以選擇的， 形成的， 合作的， 執行的， 中止的。
- 工作方式 - 已建立的理論， 已建立的基礎，在用的， 已保留的， 工作完好的， 廢棄的。
- 工作 - 初始化， 準備， 開始， 在控， 總結， 關閉
這些選定的里程碑是項目成功的指標。當這些狀態的完成被忽視或推遲， 工程的產品就會有很大的風險。表1展示了選定的對項目成敗有關鍵意義的里程碑。
CMMI和精華內核
隨着CMMI連接了監控項目的中層管理者，一個挑戰是提供一個更好的方式來監控項目工作。SEMAT和它的精華內核以及alpha狀態和他們的alpha檢查點提供了這樣的一個在CMMI和敏捷都可以使用的思考方式，它是一個工業界可以大範圍應用的方法。使用人可以考慮如下的alpha狀態檢查點：
- CMMI的利益相關方可以在卡內基梅隆大學和它的CMMI研究所的等級，主任評價員社區，Telecommunications的應用中的工業部門，金融服務， 製造商、運輸、醫療、公共工程和能源，電子商務，防務和那些在商務、管理、過程、工程和操作中的間接企業中被發現。因爲如此多樣，利益相關方的一致滿意非常難以實現。
- 利益相關方 —— 識別，表示， 涵蓋， 達成一致， 滿足部署， 滿足使用
- 不同利益相關者，機會價值主張也不同，而驅動他們的力量，如名望、經濟、任務、競爭、外部資源、和優質保證也不同。因此，每一個利益相關者都有自己的機會價值主張，而他們的利益價值主張不可能一致。
- 機會 —— 識別， 軟件需要， 價值基礎， 可行性， 地址， 應累算利益
- 用戶故事圍繞着策略目的，含義，和各類利益相關方的結果，包括主要指標包括能力控制，容量控制，變更控制，複雜度控制，缺陷歸0，優化，預測性控制，質量控制，發佈頻率，可重複性，彈性、計劃控制、跨度和響應，市場時機，可追溯性。因此，用戶故事在持續的探尋結果上可能會缺乏一致性。
- 需求 —— 構思，有界限的，前後一致，可接受的，能溯源（這裏的addressed我覺得應該是這個意思），令人滿意的
- CMMI的結構基於五個成熟度等級和每個成熟度的過程域要求。正是在過程域中，用戶故事和利益相關者能被擴展來包含敏捷和賽博安全的條件。
- 軟件系統 —— 架構以選定的，可論證的，可使用的，準備好的，可操作性的，報廢的
- CMMI是其採納者的一種工作方式，橫跨管理，過程，和工程。軟件工程管理（SPM）是基於承諾管理範例：計劃、控制、和測量。計劃包含行爲和產品，任務和反饋，以及支出和計劃估計，掙值管理系統。軟件產品工程（SPE）基於生命週期行爲、方法和工具，這些內容在不論瀑布、增量和迭代的開發中都會使用。操作支持（OPS）是基於創造軟件產品，該產品每次都能得到正確的響應，其使用的過程和其支出和計劃有關，並確保軟件產品和過程。領域特定結構（DSA）的成熟度由在應用領域中所記錄的模型、方法和範例的廣度和深度決定。
- 工作方式 —— 已建立的理論，已建立的基礎，在用的，在佈設的，工作良好的，廢棄的
- 團隊在一起工作，共享同一工程願景，並準備好履行共同願景、軟件工程過程、軟件工程管理，軟件產品工程，操作支持和領域特定架構處理，方法和工具。
- 團隊 —— 主任評價員，目標組織評價團隊，評價團隊已形成，評價團隊訓練，評價實施，評價報告完成，評價延期
- 工作集中於獲取重要的產出，這些產出和用戶故事和工作方式有關，該工作方式高於未來CMMI評價的預期。
- 工作 —— 初始化，準備，開始，控制，總結，關閉
- 工作產品聚焦於對完整性、正確性和一致性的完善和期望，具體有以下內容：
- 工作產品已作爲工作方式的一部分定義。
- 工作產品已經被生產，共享於團隊，已檢查
- 工作產品是完整的，其部件可通過先前產品追溯
- 工作產品是正確的，它的部件已經被確認，且被證明是正確的。
- 工作產品在風格，記錄表格，系統結構和構建規則上一致。
- 工作產品是有價值的，可追溯到用戶故事和工作方式中的“完成”標準。
總結
融合敏捷和CMMI需要防範不可調和的矛盾點，將敏捷看成是一種方法來構建某一個工程的工作方式的基礎，將CMMI看成是一個有用的架構，該架構的內容涉及軟件工程的高層管理者承諾和組織管理能力，以及採用SEMAT和其精華內核的新的思考方式來評定工程進展狀態和選擇下面的步驟。
這樣來說，在一個工程中需要作什麼和預定的順序和依賴關係模式分離。通過alpha狀態轉換解釋項目進展和相似的選擇下一步驟被留給項目組，並僅通過對實現機會價值的貢獻來告知。
結合alpha狀態期望，進行全局化思考和本地化實施，是非常有用的。在解決瀑布式生命週期的背景下，敏捷與CMMI之間的緊張根源與過早地滿足需求相關聯時，這就是最好的例證，所有這些因素都被認爲是CMMI思維方式所固有的。通過本地化視角來看問題，以及通過工程團隊選定的工作方式，團隊可以選擇沒有需求就開始工作，部分需求就開始工作，或者在開始時擁有所有需求。
儘管如此，不論團隊選擇什麼方法解決需求，alpha狀態對於評估當前完成度和通過當前狀態（包含構思，綁定，前後一致，受理，處理，滿足等）來提煉下一步狀態的期望很有用。總之，alpha狀態的追蹤透漏出工程的混亂邊緣有多近，甚至是否無條件信任團隊是明智的。
關於作者
這篇文章對於我有點難，裏邊很多詞語和用法和常見的英語文法不一樣，請大家對照着原文來看