回顧 cruisecontrol 導入結果之感想

在我為公司建置 cruisecontrol 每日建置系統時，我發覺同事們似乎認為有一個工具可以自動建置專案就夠了。儘管現在的自動建置過程，僅是制式地執行 make 或 ant 中幾項事先規劃好的工作項目。而同事們覺得這樣就算是「標準化」。並不打算更進一步地組織一套慣例化、甚至標準化的開發流程。

就執行結果來看，開發流程仍然是人人一把號，各吹各的調。有人寫的建置文件(Makefile/build.xml)專門給 cruisecontrol 的環境使用；他自己反而不用、也不能用在他自己的環境中。有些則是律定的工作項目只是佔個坑，實際上不做任何事。還有些建置文件，只能用於部署軟體釋出階段(release)的環境，而不能用於部署開發階段的環境。

這讓我聯想到 CMMI 導入時的一個現象。 CMMI 是制訂軟體開發標準流程的方法論，CMMI 並不直接告訴我們任何實務上改進專案開發速度與品質的方法，它僅是告訴我們可以做哪些事(通常是文件記錄)幫助我們檢視專案過程中的問題，再讓我們從中找出改進點，規劃公司的專案開發流程與持續改進。

然而台灣軟體業在導入 CMMI 時，往往流於形式(只要觀念不改，CMMI就是做表面文章)。把「文件記錄」當成重點，於是投入大量人手產出了一堆文件，卻沒有從中分析改進點，只是增加了一堆資源回收物。當然也浪費了不少時間。

不論是導入 cruisecontrol 或是 CMMI ，上述提及的動作，都不過是剛踏入門檻。離登堂入室，還遠著啊。

CMMI 所需記錄的資料，其實就在我們週遭。我們日常所用的工具就已經記錄了許多有用的訊息(運用訊息溝通網絡)。如何利用那些訊息，才是最重要的事。例如 IBM Jazz 協作平台的作法就相當聰明(IBM Jazz)，它們知道有許多的開發訊息就潛藏在專案開發工具的 log 之中。Jazz 平台透過所謂的連接器(Connector)，整合軟體開發週期中的各式工具 (甚至包含即時通訊軟體)，將這些工具的訊息彙集在一起。使得專案參與者可以透過一個共同平台，更快速地找到自己需要的訊息。

我個人認為 Agile method 要求程序人員對於「資訊處理」這件事要保有高度的敏銳嗅覺、甚至是採取偏執的態度。日常工作內容要主動且積極地程序化，交給計算機去處理。日常累積的工作記錄則要資訊化，提高再用程度。按理說程序人員是處於資訊處理技術領域最前線的人士，對他們提醒這些事似乎很荒謬。但我覺得大部份人就是不夠積極，還沒有把「寫成程式」變成直覺的思考反應。

如果這種態度沒有轉變的話，我認為倒不如就引進一整套敏捷開發工具，直接用工具制約程序員的開發行為。 缺點是要花大錢買工具。優點是不需要積極思考的程序人員。嘿... 這還是缺點吧。