2008 IBM developerWorks開發者大會記要
今天(11月5日)去台北參加 2008 IBM developerWorks 開發者大會。今年的專題是 RSDC (Rational Software Development Conference)，還創造了一個 R-Heros 戰隊。分別是 架構神人、析哈天后、時空司令、克隆女王、霸葛殺手、版管將軍，他們的顏色分別是藍、橙、灰、橘、青、綠。嗯，真難記，應該要跟日本動畫多學學... 呃，我扯到哪去了。總之呢，今天的議程也算是最新的 Rational 開發工具的說明會吧。
2006的專題是 EssUP 、2007的專題是 Jazz (Jazz project)，今年的專題 RSDC。其實今年 RSDC 的內容，有很大一部份是圍繞著與 Jazz platform 相關的 Rational Team Concert。只是去年偏向說明 Jazz platform 的概念，而今年則是以 Rational Team Concert, Rational Software Delivery Platform 等軟體具體地介紹開發者如何在日常工作中使用這些工具。此外， SOA 也一直是近年來開發者大會中必不可少的內容。除此之外，我個人比較關注還有 B3 議程《加速研發: 開放源碼軟體與 IBM Rational》和 B4 議程《跨地協作開發實戰手冊》。
加速研發: 開放源碼軟體與 IBM Rational
這個議程介紹的是協力廠商 Black Duck 的產品。他們的產品用途在於，如何讓企業大舉引入開放源碼軟體，但又能控管程式碼的授權方式，以避免程式碼授權衝突，避免感染 "GPL病毒"而被迫釋出整套軟體。
企業對於開放源碼，可以說是又愛又怕。一方面，愛它的低成本，藉由引用現成的開放源碼可以加快軟體開發時程與降低開發成本。另一方面，卻又怕那天吃上侵權的官司，開放源碼的授權內容更有所異，有些還有授權衝突。在眾多開放源碼授權中，最有特色的就是 GPL 系列了。主講人就特別舉了 Cisco 一個無線Router產品的例子，這項產品的韌體部份，最初的開放廠商就使用了 GPL 的 code。但 Cisco 一直到 FSF 提告後才知道這件事，最後也應 GPL 的要求，將該產品韌體的源碼整個公開。
Black Duck的產品就是在應付上述的情形，它建置了龐大的源碼資料庫。一方面，它可以檢查開發人員所撰寫的程式碼中是否使用開放源碼的 code ，以避免諸如 "感染GPL病毒" 的事件，以及授權衝突。另一方面，它也可以針對軟體需求，從資料庫中提出有哪些現成的開放源碼資料可以引用，以加速開發工作。
附帶一提，我是 GPL-ism ，使用 GPL 的程式碼並不會對我造成任何困擾。
跨地協作開發實戰手冊
這個議程的內容，就是談 IBM ECM Development Labs (ECM = 企業內容管理) 近兩年來導入 Agile method (敏捷編程) 的實務經驗。議程內容又分成兩個部份，第一部份是引進 Agile 的實務經驗，第二部份則是導入 Rational 等協作工具以達成跨地域協同合作的軟體開發方式。主講人指出，他們一開始是在使用即有工具的情形下導入 Agile method。其中值得一提的是，他們在導入 Agile method 後，明顯改變了以往的文件記錄方式。現在只製作必要的文件，而免去了許多利用率非常低的文件。主講人接著指出他們在評估過 Jazz platform 的內容後，認為 Jazz platform 非常適合 Agile method ，因此計劃將開發工具逐步轉移到 Jazz platform 上，以更有效地實行跨地域協作開發。
這 IBM ECM Development Labs 的客戶中，有世界百大企業中的八十家企業、世界前25大銀行中的23家、世界前25大保險業中的24家。隨著 IBM ECM Development Labs 的成功經驗，IBM 內部有愈來愈多的團隊也在導入 Agile method 了。如果有任何人仍然說 Agile method 只能用在小專案，不適用大型的企業級軟體專案的話，那麼請他看看這一篇。 Agile method 絕對適用企業級軟體專案，而且非常有效率地確保軟體開發速度與品質。
Agile method 顯然是非常熱門的話題。議程中有不少提問，其中兩個我覺得值得記下。
- 問題: 在跨地協作開發時，是否有一個總專案經理，以及數個地區專案經理呢？
主講人的回答非常重要。他說，確實每個地區的小隊都有一個小專案經理，以及一個總攬全局的大專案經理，但是在 Agile method 中，專案經理的角色任務跟以往的開發流程並不相同。在 Agile method 中，專案經理的角色只是規劃工作大項、協調開發工作，並不直接指揮開發人員該做什麼。每一次 iteration 的工作內容，都是由開發人員在每一次的 scrum meeting (XP 中稱為 standing meeting) 敲定的。開發人員決定每次 iteration 中的工作量有多少，而專案經理則是決定工作項目的重要性。如果專案經理決定提高一個工作項目的重要性並將其排入現行 iteration 中，那麼就要將現行 iteration 中較不重要的工作項目移到下一輪 iteration。專案經理不再命令式地指揮所有開發工作的作法與進度。意識到此一角色轉變非常重要。 - 問題: 每個 iteration 的時間如何決定？
主講人回答：一般而言，剛開始的 iteration 的週期會比較長，可能要三、四週。隨著開發工作的展開，到後期， iteration 的週期會愈來愈短，短到兩週甚至一週。
我個人倒是比較喜歡 Robert Martin 在《敏捷軟體開發: 原則、樣式及實務》中的說法，書中的內容也更詳細。一開始，我們還無法評估工作的大小，就算是經驗再豐富的團隊，也不能從經驗中正確評估新專案中各項工作的大小。已經有太多輕信經驗可以評估出工作大小的失敗案例了。隨著專案持續地進行，由於我們可以測量每一次反覆週期中所完成的事例點的數量，所以速度的量測就會愈來愈確準
。所以愈到後期，我們的 iteration 的週期就會愈來愈準確，也就得以維持一個強健而穩定的開發節奏。這將有助於客戶評估專案的開發時程以及成本。
延伸閱讀
- 軟體工程三大陣營, RUP, CMMI, Agile Method，與 2006 developerWorks 開發者大會相關。
- 運用訊息溝通網絡及軟體工程方法建立開放源碼專案之個人淺見
- IBM Jazz 專案開放申請使用
樂多舊回應