軟體工程三大陣營, RUP, CMMI, Agile Method
日前我參加了 2006 IBM 開發者大會，有幸聽聞尖端軟體工程團隊成員介紹最新的軟體開發趨勢「議程：大師看未來-軟體開發趨勢展望」。原本安排由 Dr. Ivar Jacobson (UML 創始人之一) 主講，可惜因颱風作梗，改由陳博士 (從 Rational 時代就跟隨 Dr. Jacobson 的團隊成員) 主講。這樣也好，陳博士以中文講說，省去了現場翻譯的語言隔閡。
陳博士提到了現階段軟體工程中，有三大主流陣營，即 RUP (Rational Unified Process)、CMMI、Agile Method (See also: 敏捷編程 (Agile programming) 與輕量級開發介紹文件@developerWorks) 。這三者的訴求與著重面並不相同，我以往也未將這三者放在一起。要將這三者並列，真要有點本領了。 Dr. Jacobson 就是有此本領者。 Dr. Jacobson 融通 RUP, CMMI, Agile Method 三者之長，提出了新的軟體工程概念，稱為「 Essential UP」，這稍後再說吧。
Agile Method Camp
我個人是傾向 Agile Method/eXtreme Programming 的，因為它導入過程最簡單，導入成本低，並不需要購置各式軟體，例如 Agile Method 強調最有用的規劃和討論工具，是傳統的筆和紙，並不要求額外建置什麼樣的軟、硬體環境。然而 Agile Method 的入門門檻也最高。此為何故？蓋因 Agile Method 對工具的依賴程度最低，主要是 programmer 觀念上的改變，卻也因此形成了它的高門檻。「觀念」、「Know-How」是最難培養與訓練的。 Agile Method 的領會過程，是「頓悟」的 (忘了在哪裡看到這麼一句話「你不能要求一個初學者了解 MVC 架構好在哪裡，你只能告訴他要這麼寫程式。等經驗累積之後，有一天，他就能突然體會 MVC 架構的好處。」)。 若無豐富經驗之累積及正確觀念之輔佐，不能體會其要義。若要在專案小組中導入 Agile Method ，必須要有資深 programmer 引導才能成事。是以其特徵之一為 pair programming (二人一組，結對作業)。
RUP Camp
那 RUP 呢？對我而言， It is too fat 。陳博士在議程中也這麼說 Today's process is large and fix size.
不論你要進行的專案是大是小，你要準備的工具都是一樣多。不論你是蓋一整棟房子，還是做一把椅子，在 RUP 中，陳博士形容「你都要帶一整套百科全書」。 RUP 對工具的依賴度很高， IBM Rational 提供了一整套搭配工具，如果不使用這些工具，幾乎推不動 RUP 。雖然缺乏彈性，但入門門檻就降低不少了，只要把這些工具丟給 programmer ，就算是不懂 OOP, MVC 等等觀念的 programming team ，也能很快導入 RUP 。只要會用工具，不懂觀念也可以導入 RUP 。
CMMI Camp
最後說說 CMMI 。雖然我個人曾在一家通過 CMMI level-2 的軟體公司待過，但遺憾的是，我不了解 CMMI 的導入過程及意向。我只能說 CMMI 著重軟體製造過程，而不著重程式開發概念，你用 OOP 也好，用 SA/SD 也罷，都可以導入 CMMI 。
CMMI 理論上看來不錯，跟 RUP, Agile Method 也不衝突，可以相輔。但我實際所見，卻不是那麼一回事。也許在臺灣， CMMI 已經淪為和 ISO 同等級之物，只剩下表面文章而已。舉個例子來說，在我先前服務的軟體公司中，有人專門負責編寫測試案例 (Test Case) ，這很正常。但是該公司是用 M$ Word 編寫測試案例，這種事放在 Agile programming team 中，可以當笑話來看。如果 compiler 可以編譯寫在 M$ Word .doc 的 code ，我用 M$ Word 來編寫測試案例又何妨？偏偏事實並非如此。這表示我必須至少寫兩份測試案例的內容，一份寫在 source code ，另一份寫在 .doc 。然後測試結果再用剪貼的方式貼在 .doc 中。只因為文件格式不一樣，所以同一件事，我要做兩份工，這可錯了。想想 Agile Method 的特徵，其中之一是「source code is document」。就是要讓 programmer 做同一件事時，不要寫多份文件。所以 test code 要用可讀性高的敘述表示 (舉例來說 Assert.areEqual(100, pos.x); 和 perror((pos.x == 100) ? "Successed: pos.x is equal 100." : "Failed: pos.x is not equal 100."); 這兩句敘述的意義相同，但可讀性以前者為佳)。非程式敘述的說明，則以註解方式同樣寫在 test code 中。最後利用報表工具，去調用 test code ，擷取測試結果，將測試案例和結果以設定的輸出格式，產生報表文件。就像用 XML 去搭配 XSLT+CSS 一樣，一份內容(XML)，用不同的輸出格式，讓工具幫你產生報表(XSLT+CSS)，而不是自己另外編排。
前述是將 CMMI 結合到 Agile programming team 中。但我所看到的 CMMI 實作方式，只是讓 programmer 重覆編寫不同格式文件。軟體開發成本不降反昇。最讓我垢病的是，在導入 CMMI 的過程中，既無工具相輔 (如 RUP)，也無觀念引導 (如 Agile Method) ，使 CMMI 淪為報表文件的製造工作。徒見其弊，不見其利。
相關文章
- RUP 概念入門參考文章
- 台灣資訊軟體業缺乏資深programmer
- 先說故事再動手設計, 從一個簡單故事看 Test Driven Development
- Working with PHPUnit3, part 2 - 撰寫測試案例
- 軟體工程的 GPS
- 敏捷方法實務研討會會後筆記1 - 溝通與 Pair programming
- Innovate 2011 IBM 開發者大會記事
- Innovate 2012 IBM 開發者大會記事
- Innovate 2013 IBM 開發者大會記事
- 2014 IBM 開發者大會高雄場記事
樂多舊回應