軟體次文化與CMMI能力成熟度
雖然書中溫柏格認為使用「成熟度」一詞不是很恰當，不過我個人認為把它用來和CMMI對照起來(我用的是Continuous Representation)，其實蠻有相似之處，所以我整理了以下這一個表。
軟體次文化 | 次文化意涵 | CMMI成熟度名稱 | 成熟度意涵 |
模式0 (渾然不知) | 我們都不知道我們正循著一個過程在做事。 | Level 0 (Incomplete) | 存在著達成各項目標的通病。幾乎沒有易於鑑別的工作產品或產出。 |
模式1 (變化無常) | 我們全憑當時的感覺來做事。 | Level 1 (Performed) | 過程中的目標通常可以被達成，但其成果並未被嚴謹地被規劃和追蹤。組織中的個人認知到某項工作應予執行，其中會存在一份該項工作在必要時予以執行的一般性協議。過程中有可資鑑別的工作產品，同時這些工作產品可以證明目標達成的與否。 |
模式2 (照章行事) | 我們凡事皆依照工作慣例（除非我們陷入恐慌）。 | Level 2 (Managed) | 過程依據指定的程序交付工作產品，並經過們劃及予以追蹤。工作產品要忠於標準及需求。和Level 1的主要差別為，目前交付工作產品之過程績效，是在預定時程及所需資源範圍內，完成已明示的品質需求。 |
模式3 (把穩方向) | 我們會選擇結果較好的工作慣例來行事。 | Level 3 (Defined) | 過程依據奠基於良好的軟體工程原理定義之過程來執行與管理。過程的個別實踐，是運用標準、書面化之過程裁適後且奉核定的版本，以成就過程的成果。建立過程定義(範疇)所需的資源也到定位。與Level 2的主要差別為，乃有已建立的過程，會運用能達成其過程結果的已定義過程。 |
模式4 (防範未然) | 我們會選擇結果較好的工作慣例來行事。 | Level 4 (Quantitatively Managed) | 已定義的過程之執行，在定義的管制界限內要與實際相符，以達成其預設的過程目標。績效的詳細量測值要予蒐集及分析。如此，可以引導對過程的計量式瞭解，以及改善績效預測與管狂的能力。績效是以計量方式來管理的。工作產品的品質是以計量式表達。與Level 3的主要區別，乃是已定義的過程現在是在預劃的範圍內，毫無差異地執行，以成就其過程的結果。 |
模式5 (全面關照) | 人人時時刻刻都會參與所有事務的改善工作。
| Level 5 (Optimizing) | 過程的績效被最佳化，以滿足企業目前與未來的需要，同時，過程達到可重覆的能力，符合其預劃的企業目標。績效的計量式過程效果與效率目標，依據組織的企業目標而訂定。根據這些目標做持續性的過程監控，可以經由對得自計量回饋與改善所獲結果的分析達成。對過程最佳化需要對創新的想法與技術試行，改變沒有效果的過程，以符合預劃的目標或目的。與Level 4的主要區別，乃是已定義及標準的過程，現在動態地變革、有效地調適，以滿足目前與未來的企業目標。 |
所有的軟體公司或是從事軟體相關的工作人，都必然會落到某一個特定的範圍中，而大部份的軟體公司都會落在0-3之間
由於0嚴格來說不能算是一個標準，所以我們也不加探討，我們從模式1說起
模式1就是傳說中的「超級程式設計師」的狀況，在許多軟體公司剛起步時，大部份的情形都是由一個或少數主要的技術人員做系統的開發，所以產生了許多的傳奇，這些人創造出系統的鶵型，因此他們的事蹟被當做公司的神話所傳訟，在這一個模式中，所有的開發細節都被少數人所掌握，因此，績效或成果的好壞都由這一個或少數的人決定。
而在CMMI的定義中，這一個階段的重點在於要做專案計劃，而CMMI所指的專案計劃，不是說只要畫畫甘特圖就好，必需要考慮的範圍，包含PMBOK所規範的9大知識領域，而在CMMI中它利用Process Area定義大的Process流程，而在每一個Process Area中，定義了Generic Goal 及 Specific Goal來規範必需要完成的目標。
從我個人的經驗來說，當軟體公司在這一個階段時，專案計劃常常是被當做簽約用或參考用的，而實際的執行雖然會參考專案計劃的內容，但是對於時程上的安排，常常是無能為力，只有儘量去把事情完成的想法而已；至於像是成本、風險等等，是完全沒有能力去處理的。
模式2則是由於模式1成功了，逐漸產生許多的客戶，於是原先的超級程式設計師升級成「超級技術負責人(或超級專案經理)」由他統領整個團隊，也由於需要溝通的緣故，會產生一部份的規則或SOP，但是旗下的工程師們，不見得能夠了解這些規則或SOP的原意，所以僅止於型式上的執行，導致當開發過程發生了一些掌控外的情形，整個團隊也會陷入混亂；而這一個負責人或專案經理，則必需獨自想辦法解決因難。
在CMMI的定義中，這一個階段重點會放在Process的建立，對於資源、時程、品質、成本等等，已經有了初步的掌握能力，而且會比較準確的依照專案計劃中的規劃去完成和執行專案；同時，在這一個階段會出現所謂的SOP，用以處理和面臨一些狀況的處理，但是由於SOP僅能規範專案中比較容易掌控的部份，所以仍是要依靠強大的專案經理成才把事情做得比較好。
以我個人的經驗來說，會因為客戶的量到一定的程度，資訊溝通的成本會變很高，所以會適度導入一些系統去改善此情形，我曾待過的軟體公司，曾導入過簡單的PMIS及Bug Tracker系統，以節省部份成本，但是我們往往忽略一個重要的因素，只是想著把某個系統或某種開發方式導入就以為可以改善困境，而缺乏對整個流程的改善和了解。
模式3則是雖然和模式2很類似，但是它的經理所倚仗的是了解以及充份管理經驗，所以為何溫柏格會使用「把穩方向」這一個詞來形容這一個階段，即便他們遇到了不在SOP或是被定義的流程中的問題，他仍然可以朝向事情比較好的向方去完成專案；除此之外，還有一個重要的表象可以和模式2區隔，就是「為專案或工作所引進的工具真正的被使用，而且使用的很好」。
從CMMI的定義中，這一個階段的重點在於組織對於專案的承諾及從組織的觀點和專案的流程進行各項互動。
當組織已經能夠針對專案的流程給予承諾與互動時，這意味著，由組織所推動的流程改善，都必需要確實的被落實，不管是和績效的結合或是對PM的要求，所以也不容易看到會有「特權」的PM，可以任意妄為，做專案變成是每件事都要玩真的。
很遺憾，我個人並沒有這麼幸運，可以在這一個模式或環境中的工作經驗，所以我引述我曾聽過的話讓給位想像一下，之前上課時，有一位老師，他們的公司已達到CMMI的Level3的標準，他說：在開會的時候，直接討論的都是問題本身和如何解決，不太需要考慮和誰溝通需要小心或注意什麼，而每一次的專案會報，可以從提出的數據就掌握專案的進度和狀況，不太需要針對每一個專案都詳細Run一遍，而且，開完會後，每個人都明確的知道自己的任務和工作，一切都會在預期的狀況下進行。
這讓我想到以前每週的專案會報，都要針對每一個專案討論，一花就一個上午，可是我們還是不清楚要做啥，只好依靠過去的專案經驗決定，真的是有天壤之別啊。
模式4則是針對模式3中，引進更多更準確的測量基礎，透過這些數據，更清楚而準確的描繪出專案的輪廓，並提供和確保更好的專案品質。
而CMMI的定義中，也是如此描述，而這數據的累積不只提供管理上便利，更提供了預測專案的可能性。
模式5則是具備了針對這些數據的分析能力，並能夠不斷持續性的改善，說的白話一點，就是整個組織都變成一個學習型的組織，會自行去修護組織做事方法的缺陷，並且做得更好。
==============================================
CMMI部份資料來源：軟協CMMI流程與工具應用 上課講義
留言列表
藍色的我 (4)