2014 IBM 開發者大會高雄場記事

9月2日，我參加了 2014 IBM 開發者大會，高雄場。副標題「開發速戰，行動速決!」。Innovate 2014 <Innovate@SPEED>。

我連續幾年都參加了 IBM 開發者大會，這幾年的內容趨勢大概都了解，於是今年本來想偷懶，不去了。但八月中收到郵件通知竟然開了高雄場。難得在地辦了一場，就又報名了。今年就不用去台北了。不過比起台北場，高雄場的議程有所簡化，只有一間會議室，一組議程。不像台北還分成A,B組。人數也少許多。我目測現場大約有五十人左右吧。我以往到台北參加時的人數大約有三百多人。

持續軟體交付 - 行動、嵌入式系統、敏捷開發

Mobile is everywhere. 物聯網的發展，受可攜式設備普及而加速。

目前公司的軟體交付使用狀況: 70%的人力，都用在系統維護，而不是軟體創新(創造價值)。 一個小小的軟體功能改變，要花上4~6週。 一半以上的外包項目失敗。

協同合作的軟體開發流程，實際上是企業諸多核心業務流程之一，類似的核心業務流程還有 ERP CRM HRM 等等。 CIO 代表 CEO 做的最重要的事，就是「改善業務流程」。

RUP 重現江湖。這議程又複習 RUP (developWorks 2006)，V 模型 (Innovate 2011)，Agile 等流程一次。

DEV OPS is a verb.

• Lifecycle Management
• Continuous Delivery
• Repeatable Processes

企業行動平台: App開發測試到行動裝置管理一次OK!

IBM Worklight 加速移動APP開發。

1. 移動互聯是世界與產業的潮流。
2. 移動為先。(Mobile is ths first)。
3. 如何處理 BYOD 的難題。員工自帶的移動設備流傳了公司資料。例如員工用LINE傳工作訊息。
4. 重視使用者經驗。

計算機正邁向一個全新的世紀: Tabulating systems > Programmable systems > Cognitive systems 感知系統。

移動互聯的浪潮成指數型的成長，帶動計算機系統往感知世紀邁步。

敏捷管理，克服開發流程的不確定性

複習時間

• 敏捷是一種自適應(adaptive)的發展方法，專注於創造價值與迅速。 它不是僵化死板的步驟規範，而是跟隨各公司內部的獨特流程自我調整適應的開發方法論。
• 敏捷充分利用了利害關係人(stakeholders)，，持續地、有紀律地、整體團隊(whole team)的做法。

敏捷的好處: 92% 認為改善了優先順序管理的能力。其他還有:

• accelerated time to market
• easily manage changing priorities
• better align IT & Business. 消除IT與業務部門的溝通落差。

Scrum Master 是保證 Scrum 成功的牧羊犬。其實不只是 Scrum ，幾乎每種敏捷方法都需要一個類似的導師角色才能有效執行 (COSCUP 2014)。 Scrum 是目前敏捷方法的主流作法(55%)。因為它易於理解。只是在我看來，大部份的公司其實都是混合各派內容，這正是敏捷方法具有適應彈性的表面象徵。

Product Backlog : 由 user story 組成。user story 的記述格式要項: 角色、能力、目標。 3C: Card (故事卡), Conversation (細節), Confirmation (完成條件)。 好的故事要具下列特性:

• 獨立性 independent
• 可協商性 negotiable
• 有價值 valuable
• 可估算 estimable
• 大小適當 - 不應跨週期。跨越週期表示太大，應再細分。
• 可測試 testable

敏捷開發的最佳利器，加速企業軟體交付 (Rational Team Concert)

說明 RTC 提供的 Scrum 模版介面，和企業開發軟體的步驟。

但我覺得， Scrum 面對政府標案時往往難以實踐。因為於政府方面有很多關係人，每個關係人都有需求、都有意見，但幾乎沒有人願意對他提出的需求和優先順序負責。 當一項需求在週期內不及完成時，沒有關係人願意決定這項需求可不可以移到下一個週期，或者根本可以取消。當多項需求面臨釋出週期的時限壓力而應該區分優先順序時，沒有關係人願意把自己的需求排低優先。

「Everybody」都被要求參與，「Anybody」都有權力提需求，大家都認為「Somebody」會去做，結果卻是「Nobody」負責。

我並不單指 Scrum 不適合台灣的政府資訊系統標案。而是面對政府資訊部門缺乏獨立專業性，僵化的採購規定，及各層權責長官不具有效管理心態的環境下，任何科學管理的軟體工程方法都不能有效貫徹執行。你可不能讓一個標案廠商，從策略面協調整合政府相關單位的需求竟見。通常你只能執行敏捷方法的戰術層面內容，確保軟體開發品質保持在可以控制的情況。

物聯網創新進行式－嵌入式即時開發系統實戰分享

IBM輔導實際案例，町洋企業現身說法。町洋原本是一間純硬體零件(端子台)的製造公司，沒有軟體開發人員。轉型物聯網資訊系統廠商的輔導案例。

町洋企業利用 IBM SysML 設計 C-Gate 雲通道。C-Gate 雲通道是微細物聯網的連接器。 打破傳統 IO 與 PLC 的限制，提供分散式、推播式、智慧萬用的網格IO。

• 一、電源問題。獨家設計的電源供應器，提供高達90%的電力轉換率，組成網格電源。 可以有效地為物聯網上的每個設備、端點，提供運作電力。
• 二、可靠度與速度問題。突破 RS485 的侷限，創新 Modbus 高速網路晶片。資料傳輸率可達 12 Mbps (傳統 modbus 的一百倍)。
• 三、為 embedded system 提供及時測試(Real-time test) 。

我要說說關於資料傳輸率的事。傳統上 modbus 受限於其微小的傳輸量，在匯流排上傳送的資料，與其說是訊息，不如說是訊號，是零、一、開、關的訊號。這些訊號的代表意義還要程式開發人員自己參照規格書才能理解。一但資料傳輸量提高到乙太網路的水準時，那麼在這條資料匯流排上就可以直接傳送具有自我描述特徵的資料，像是 XML 或 JSON 這一類內容，為程式開發人員或最終冊戶提供更豐富的設備資訊。

嵌入式系統需求管理與投資評估，有效掌控專案品質 (Doors, RTC, Focal Point)

延續上個議程，講師是輔導町洋科技開發 C-Gate 的技術顧問。從技術顧問的觀點，說明嵌入式系統廠商町洋科技導入 RTC 時的實務經驗。 嵌入式系統廠商愈來愈重視需求管理 (ideas)。

全開發雲端PaaS平台: IBM Bluemix強勢來襲

IBM 改變策略，不是直接賣開發軟體給客戶，而是賣開發服務 Bluemix (www.bluemix.net)。 Bluemix 簡單說是雲端版 Rational Team Concert ，還整合一大堆後端資料服務。

去年開發者大會的物聯網議程中，講師就有提到 IBM 正把 Eclipse 搬到網路上，變成一套 Web IDE (Orion) (Innovate 2013)。既然 Eclipse 都要線上化了，那麼把 Rational Team Concert 搬到 Web 上也是很合理的，也就有了 Bluemix 這套雲端上的整合開發工具環境。

講師利用 Bluemix 很快地產生了一個具有內容管理能力的網站應用。這個剛建立的網站應用因為還沒有設定管理權設，我第一時間就連了上線，並順手在網頁內容上加了 123 三個字，證明這確實可以讓多人在線上共同作業 XD

基本上，Bluemix 是 IBM 推出的有價服務，它針對不同的用途提出了許多不同的計價方案。不同的服務會用不同的計費原則，例如服務連線次數、運算單元使用時間、資料庫儲存用量等等。在會中就有人詢問講師計價上的問題。講師特別指出 IBM 為了鼓勵新創公司投入使用，實際上提供了很優惠的計價門檻。只要你的使用量低於計價門檻就不會產生任何費用。我估算了一下，大多數一人工作室的使用量都低於計價門檻。

講師舉 Runtimes 服務用量為例。這以應用軟體每小時使用 1GB 記憶體量計價，每個月提供 375 GB 免費時數。如果你設定記憶體用量上限為 512MB ，則你一個月將有 750 小時免費時數。而一個月也才只有744小時，也就是整個月都免費的意思。

本人結論

本次的趨勢重點為：移動設備的普及化，加速了物聯網的發展，並推動計算機世代往「感知系統世代」(Cognitive Systems) 的演進腳步。移動設備不只是讓使用者戴在身上，更要感知使用者的環境，收集使用者本身和其身邊的各種資訊，將這些環境資訊上傳到雲端。利用雲端上的大數據分析，即時回饋使用者有用的訊息。

軟體開發趨勢：軟體交付處於尖端技術趨勢的心臟地位。 DevOps 就是要改善企業核心業務流程，讓企業能投入更多資源在創造價值的工作，而不是系統維護工作。

我過去參加開發者大會的記錄:

• RUP, CMMI, Agile Method
• 2008 IBM developerWorks開發者大會記要
• Innovate 2010 IBM 開發者大會記事
• Innovate 2011 IBM 開發者大會記事
• Innovate 2012 IBM 開發者大會記事
• Innovate 2013 IBM 開發者大會記事