老實說
這個課程對我了解CMMI的幫助有限，這絕不是CMMI沒有用、或老師的課上的不好。
而是在上課前，我的人格特質加上工業管理的背景，讓我從一開始接觸SQA這個工作時，就促使我開始思考該用什麼樣的手法改進組織的軟體開發流程，讓它更有制度和效率，並提昇最後的軟體品質。
所以，我是在不同的公司內實作過類似 CMMI 內 Managed和Defined Level的流程領域 (AP, Area Process) 內的特定目標(SG, Specific Goal)和特定執行方法 (SP ,Specific Practice)，所以對CMMI已經有一些實作的經驗與體悟。
再加上過去的失敗軟體開發經驗，所以CMMI 課程對我而言，並非只是初淺的理解，而是另一個層次的協助，這點後文會提及。
接觸CMMI
是因為工作中需要替部門同事介紹CMMI V1.2，就將整本CMMI 的手冊好好的K過一遍。
我才慢慢發現「條條大路通羅馬」，原來我過去所用的這些手法，其實別的組織也曾遇過，甚至也採用過類似或相同的手法。
ISO 的導入經驗
我曾在過去服務的公司，協助導入ISO 9001 2008年版。光我一個人就寫了超過35份的規範，佔該公司的ISO文件總數三分之一，其中約有一半是沒有業界的「參考文件」、需要量身訂做的文件，包括：軟體開發部份的二、三階規範。
這個導入經驗，對我自修 CMMI也有很大的協助。因為，ISO和CMMI一個是香蕉、一個是蘋果，兩者不能直接比較優劣，但背後系統化、組織化、正規化的精神，兩者其實是一致的。
如果以系統的觀點來看二者時，在系統內互相援引，有適當的「介面」，不會衝突、也不會自相矛盾。
但即使如此，讀完CMMI的手冊後，我仍然有許多的問題。
其間，我試著問一個曾試圖說服我們公司導入CMMI的外部顧問。不過，因為我們公司一直沒有打算導入 CMMI，所以我也不好意思問太多細節問題，他也不大想回答我太細節的問題。
CMMI課程的收獲
CMMI課程對我而言，是讓我有機會在課堂中一步步串連CMMI 與過去的軟體開發專案失敗經驗與實作手法，讓我很清楚地知道每個流程領域關聯性與目標。
雖然過去也曾在工作中實作 CMMI ML2、ML3的SP，試著讓軟體開發流程更有制度、進而提昇軟體的品質，但回頭看了CMMI的要求後，才發現當時實作的手法其實還可以串聯的更好。
此外，藉由課堂的發問，解開了許多自修 CMMI 手冊後的疑惑，並釐清對 CMMI內有一些看似重覆的SG，以及PA 之間的Interface。
到了第三天上到CMMI內High Maturity的手法，工業管理的背景，讓我很快就知道CMMI High Maturity的手法，正是工業管理中慣用的手法：PDCA。
- P:藉由大量資料找到影響軟體開發專案的因子及其權數，
- D:然後採用對軟體專案較佳的手法去開發，
- C:在不同階段Monitor進度以控制實際與預期的差異，
- A:並試著找出差異的原因並提出改進與矯正措施。
我想這些獲益，和其他同學應該有很大的不同。
最後
我鼓勵所有有志於SQA工作的朋友去上CMMI課程，多多了解這個工具。
但我不建議一畢業、剛出社會的朋友，在沒有任何軟體專案經驗的情況下（學校的那種不算啦！）貿然去上CMMI課程。因為一來課程的費用不便宜（我是自費新台幣18000去上課的），二來 CMMI 課程的教學只是人體的「骨架」，如果少了實務經驗的「肉」支撐，是無法看出完整軟體開發模式的「人體」、看到 CMMI的全貌。
相比之下，有軟體開發實務經驗、與成功或失敗的軟體專案過程經驗，比較能了解CMMI 內各流程領域的存在必要性與關係，對課程的理解和體悟也會更多一些，這樣上課的效果也會更好。
不然，上完課後，你只是知道了一堆的專有名稱，你還是你、CMMI 也還是 CMMI。
沒有留言:
張貼留言