一種融合CMMI和靈活的政策的前進路線

本文的英文版為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和狀态獨立于特定的方法、實踐和工具，并是以具有不依賴任何方法和實踐選擇而引導前進和評估任何軟體工程狀态的能力。這個結果對于管理人員是友好且易于了解的。

1. 客戶(customer)空間由利益相關者的共同願景構架，以構想出具有令人信服和相應結果的機會的合理價值主張。
2. 解決方案(solution)由利益相關者綁定，這裡的利益相關者同意了需求和使用者故事，以及有利于操作和使用的軟體系統結構。
3. 工作(endeavor’s work)是由一支精挑細選，準備就緒的團隊執行的，并且是一種基于既定原則和基礎的工作方式

這些Alpha狀态檢查點是導向性名額，這些名額為這些Alpha狀态建議令人信服和滿意的結果。産品工作上的檢查點被加上，是為了內建可信的軟體工程期望。為了更好的結果，請遵循以下期望，取得基于實踐的方法與總體架構之間的更好的平衡，全面的思考并實施本地化：

1. 利益相關者之間達成一緻并共享同一願景。
2. 建立一個機會價值主張，該主張由利益相關者的願景來實作。
3. 需求和使用者故事是相關和被接受。它們都是為了實作願景。
4. 軟體系統結構已經确定，該結構由一個用于指導軟體實作領域特定的架構組成，并且該軟體實作是準備就緒的且實施起來沒有技術債。
5. 團隊成員間通力合作，共享工程願景，準備執行共同的願景，軟體工程過程，軟體項目管理，軟體産品工程，操作支援，和領域特定結構過程，方法和工具。
6. 團隊的工作方式已經建立了軟體工程過程、軟體項目管理、軟體産品工程和操作支援的堅實基礎。
7. 工作開始前，所有的準備工作應該完成，準備工作包括一緻的使用者需求，被認可的使用者故事，意見統一的利益相關者，堅實的工作方式基礎。
8. 所有工作産品依據已定義的标準進行檢查和準備，這個标準在完整性、正确性和一緻性方面應是最佳的。

Alpha是Abstract Level Progress Health Attributes的縮寫。簡單但是高效，這些明确的alpha和它們前進的自然狀态在引導一個工程實施和引導目前已經失去前進方向的軟體工業時非常有用。更加特别的是，alpha和它們的狀态序列（表1）包括：

1. 利益相關者 - 被認可的，已代表的，已參與，一緻同意的，已被滿意部署的，已被滿意使用的（這裡翻譯的不好）。
2. 機遇 - 已經識别的，軟體需要的，價值确定的，有活力的， 已确認的， 已形成好處的。
3. 需求 - 已構思的，已綁定的，一緻的， 已接受的， 已确認的， 以滿足的。
4. 軟體系統 - 結構已選擇的， 已證明的， 可使用的， 已就緒的， 可操作的， 已廢棄的。
5. 團隊 - 以選擇的， 形成的， 合作的， 執行的， 中止的。
6. 工作方式 - 已建立的理論， 已建立的基礎，在用的， 已保留的， 工作完好的， 廢棄的。
7. 工作 - 初始化， 準備， 開始， 在控， 總結， 關閉

這些標明的裡程碑是項目成功的名額。當這些狀态的完成被忽視或推遲， 工程的産品就會有很大的風險。表1展示了標明的對項目成敗有關鍵意義的裡程碑。

CMMI和精華核心

随着CMMI連接配接了監控項目的中層管理者，一個挑戰是提供一個更好的方式來監控項目工作。SEMAT和它的精華核心以及alpha狀态和他們的alpha檢查點提供了這樣的一個在CMMI和靈活都可以使用的思考方式，它是一個工業界可以大範圍應用的方法。使用人可以考慮如下的alpha狀态檢查點：

1. CMMI的利益相關方可以在卡内基梅隆大學和它的CMMI研究所的等級，主任評價員社群，Telecommunications的應用中的工業部門，金融服務， 制造商、運輸、醫療、公共工程和能源，電子商務，防務和那些在商務、管理、過程、工程和操作中的間接企業中被發現。因為如此多樣，利益相關方的一緻滿意非常難以實作。

• 利益相關方 —— 識别，表示， 涵蓋， 達成一緻， 滿足部署， 滿足使用

1. 不同利益相關者，機會價值主張也不同，而驅動他們的力量，如名望、經濟、任務、競争、外部資源、和優質保證也不同。是以，每一個利益相關者都有自己的機會價值主張，而他們的利益價值主張不可能一緻。

• 機會 —— 識别， 軟體需要， 價值基礎， 可行性， 位址， 應累算利益

1. 使用者故事圍繞着政策目的，含義，和各類利益相關方的結果，包括主要名額包括能力控制，容量控制，變更控制，複雜度控制，缺陷歸0，優化，預測性控制，品質控制，釋出頻率，可重複性，彈性、計劃控制、跨度和響應，市場時機，可追溯性。是以，使用者故事在持續的探尋結果上可能會缺乏一緻性。

• 需求 —— 構思，有界限的，前後一緻，可接受的，能溯源（這裡的addressed我覺得應該是這個意思），令人滿意的

1. CMMI的結構基于五個成熟度等級和每個成熟度的過程域要求。正是在過程域中，使用者故事和利益相關者能被擴充來包含靈活和賽博安全的條件。

• 軟體系統 —— 架構以標明的，可論證的，可使用的，準備好的，可操作性的，報廢的

1. CMMI是其采納者的一種工作方式，橫跨管理，過程，和工程。軟體工程管理（SPM）是基于承諾管理範例：計劃、控制、和測量。計劃包含行為和産品，任務和回報，以及支出和計劃估計，掙值管理系統。軟體産品工程（SPE）基于生命周期行為、方法和工具，這些内容在不論瀑布、增量和疊代的開發中都會使用。操作支援（OPS）是基于創造軟體産品，該産品每次都能得到正确的響應，其使用的過程和其支出和計劃有關，并確定軟體産品和過程。領域特定結構（DSA）的成熟度由在應用領域中所記錄的模型、方法和範例的廣度和深度決定。

• 工作方式 —— 已建立的理論，已建立的基礎，在用的，在布設的，工作良好的，廢棄的

1. 團隊在一起工作，共享同一工程願景，并準備好履行共同願景、軟體工程過程、軟體工程管理，軟體産品工程，操作支援和領域特定架構處理，方法和工具。

• 團隊 —— 主任評價員，目标組織評價團隊，評價團隊已形成，評價團隊訓練，評價實施，評價報告完成，評價延期

1. 工作集中于擷取重要的産出，這些産出和使用者故事和工作方式有關，該工作方式高于未來CMMI評價的預期。

• 工作 —— 初始化，準備，開始，控制，總結，關閉

1. 工作産品聚焦于對完整性、正确性和一緻性的完善和期望，具體有以下内容：

• 工作産品已作為工作方式的一部分定義。
• 工作産品已經被生産，共享于團隊，已檢查
• 工作産品是完整的，其部件可通過先前産品追溯
• 工作産品是正确的，它的部件已經被确認，且被證明是正确的。
• 工作産品在風格，記錄表格，系統結構和建構規則上一緻。
• 工作産品是有價值的，可追溯到使用者故事和工作方式中的“完成”标準。

總結

融合靈活和CMMI需要防範不可調和的沖突點，将靈活看成是一種方法來建構某一個工程的工作方式的基礎，将CMMI看成是一個有用的架構，該架構的内容涉及軟體工程的高層管理者承諾群組織管理能力，以及采用SEMAT和其精華核心的新的思考方式來評定工程進展狀态和選擇下面的步驟。

這樣來說，在一個工程中需要作什麼和預定的順序和依賴關系模式分離。通過alpha狀态轉換解釋項目進展和相似的選擇下一步驟被留給項目組，并僅通過對實作機會價值的貢獻來告知。

結合alpha狀态期望，進行全局化思考和本地化實施，是非常有用的。在解決瀑布式生命周期的背景下，靈活與CMMI之間的緊張根源與過早地滿足需求相關聯時，這就是最好的例證，所有這些因素都被認為是CMMI思維方式所固有的。通過本地化視角來看問題，以及通過工程團隊標明的工作方式，團隊可以選擇沒有需求就開始工作，部分需求就開始工作，或者在開始時擁有所有需求。

盡管如此，不論團隊選擇什麼方法解決需求，alpha狀态對于評估目前完成度和通過目前狀态（包含構思，綁定，前後一緻，受理，處理，滿足等）來提煉下一步狀态的期望很有用。總之，alpha狀态的追蹤透漏出工程的混亂邊緣有多近，甚至是否無條件信任團隊是明智的。

關于作者

這篇文章對于我有點難，裡邊很多詞語和用法和常見的英國文法不一樣，請大家對照着原文來看