＊＊ 本文同步發表於 FB 社團－軟體設計鮮思維 ＊＊

昨日與一位業界的前輩喝咖啡聊聊 (兼談合作事宜)，他是國內頗負盛名的 CMMI 輔導認證的顧問。

雖是相當資深且擔任多家知名大企業的顧問，但仍孜孜不倦，時程總是排滿，利用空檔時間至許多技術課程單位當學生，藉此了解下業界採用所謂的方法論/新技術．．．等。

他分享了兩件軼事：

• 他至台大上 C#.NET 語言入門課程，有約40來位的學員上課。
  講師竟然跟他們說，現在系統開發根本不需要設計，只要會操作工具、拉一拉畫面，簡單的下幾個指令，就可以很快速的產出應用程式。
• 他上某單位現在最夯的 SCRUM 開發流程課程，講師拿它與其它方法論比較，甚至還嚴重的批判，而其中更是包括了 CMMI (顯然誤解，它並非是流程方法論)。

  這位前輩很感慨甚至有些不悅，尤其是批判到他的專業領域－CMMI，明明就只是一種制定達成目標的框架而已，怎麼會是拿來與 SCRUM/Agile 等相提並論呢？

他認為講師應該是擺在以該課程的主題為中心來傳授相關知識與技能的，但怎麼能對自身並不了解的領域妄下斷論/批判，進而傳達非常不正確的觀念，這豈不是誤人子弟呢？！

哈，其實軟體業沒啥新鮮事，這些見聞也都早已習以為常了。尤其是隨著系統開發廠商提供的工具/機制越完善，雖然可以大幅減低開發的時間，但卻也造就了軟體人員的墮落，過度地依賴這些工具的使用，卻少有思考軟性較具本質性「虛」的那一面向。

我與那位前輩稍微解釋下，針對第一點，講師只要稍微修正下講法即可。不是不做設計，而應該是說抱著「簡單設計 (simple design)」的態度 ，事後再佐以「重構 (refactoring)」來逐漸修正調整，快速的 I&I (iterative & incremental)以構成設計/實作一體的開發循環。

設計是必然會做的，但該講師顯然誤解所謂的「設計」是那種以往 (其實現在也很多單位是這樣做)要做仔細規劃、產出一堆文件卻不適用實作的 Waterfall 方式。

至於 CMMI 與 SCRUM/Agile/RUP 等方法論之間的關係，我在9年前就曾發表過「利用 UML 類別圖表達 CMMI Content 與範例說明」。

其實簡單的說，因為 CMMI 只是制定各等級所謂成熟度的目標框架，但它並沒有提供要如何 (How-to)達成 (achieve)的作法；如何達成正是這些方法論可以提供的，所以其實把 CMMI 視為 Interface，上述方法論視為是實現 (realize)該 Interface 的具體性類別 (concrete class)；兩者可以形成很好的互補，並非是拿來比較、相互衝突的。