政府機關敏捷案例：荷蘭鹿特丹港HaMIS系統

徐柏峰

資料來源：鹿特丹港官網

        歐洲第1大港-鹿特丹(Port of Rotterdam)，用敏捷方法開發出的HaMIS港務管理系統，獲得TÜViT的5顆星品質認證。

1. 專案背景

        位於萊茵河口的荷蘭鹿特丹港，從13世紀就開始發展，向來有歐洲門戶(Gate to Europe)的美譽。港區腹地超過100平方公里，貨物吞吐量達4.4億噸，每年造訪的海輪(Sea-going Ships)超過34,000艘、河輪(Inland Vessels)超過1萬艘，造就了鹿特丹穩坐歐洲第一大港的地位。

歐洲3大港吞吐量

資料來源：Port of Rotterdam, Port Statistics 2013

     

        鹿特丹港的最大特點，就是儲、運、銷一體化的流程。來自各地的貨物，在港區加值加工後，可以方便地透過陸、海、河、空等多種運輸路線，分銷到歐洲各地。根據荷蘭官方的統計，如果把交通業、工業和零售業全部算起來，在鹿特丹港就業的人數超過9萬2千人，經濟規模超過120億歐元，而且有逐年增加的趨勢。[1] 近年來，鹿特丹港擴建新港Maasvlakte的計畫進入第2期，打算利用1000公頃延伸空間，容納運載貨櫃、原油、礦石和煤炭的新一代的超級貨輪(Mega Ship)。為了保持鹿特丹港在全世界的競爭優勢，當局除了每年投入5億歐元，進行建設基礎設施以外，也邀請阿曼港當局(Port of Oman)對鹿特丹進行投資，並在巴西的新港設立辦事處，透過港口之間的合縱連橫，創造彼此的商機。

2. 導入過程

        經營港口就像是租賃業，對鹿特丹港來說，每年收益主要來源有二：一是船東支付的入港費(Harbor Dues)、二是港區基礎設施的出租費。要因應蒸蒸日上的業務量，需要跟得上時代的數位化流程。對此，鹿特丹港當局的資訊長Lourens Visser，提出了一系列改造鹿特丹港資訊計畫，當中最重要的，就是要開發出一套符合鹿特丹港營運流程的「港口管控資訊系統」(Harbor Master Management and Information System, HaMIS)。[2]

        鹿特丹港既有的資訊系統已經用了19年，功能早就不敷使用。在新系統中，需要讓港務同仁有效率地執行船隻交通管理、規劃、危險物品偵測、意外事件回應和派遣巡邏船隻等日常業務。[3] Lourens Visser參考市面上的20多個套裝軟體後發現，鹿特丹港的業務流程非常複雜，沒有現成的軟體可以應付，就算委外開發，廠商短期內也搞不懂港務的領域知識：「我們無法讓IBM或Capgemini聽懂需求，因此專案註定會失敗。」面臨這樣的難題，Lourens Visser決定，用敏捷方法開發鹿特丹港專屬的HaMIS系統，他的做法是：[4]

• 採用Scrum Framework

        一開始，HaMIS專案先導入IBM的「統一軟體開發流程」(Ration United Process, RUP)，後來因為RUP的流程比較複雜，決定改用Scrum Framework。[5]

•  成立跨職能的團隊

        從鹿特丹港的資訊部門中，挑出35個人編成跨職能的開發團隊，再根據開發範圍不同，編成3個小隊，各有各的需求窗口(Product Owner, PO)，但共用同一組程式庫(Code Base)。

•  採用集中辦公機制

        由於團隊成員本來就是自家人，對於港務工作已經有相當程度的了解。為了提升溝通品質，開發團隊和業務部門在同一個地方辦公(Co-Located)，團隊開發過程中只要遇到問題，隨時可以找到相關的同事討論。

•  持續執行程式審驗

        為了確保軟體品質，委託荷蘭知名的資訊顧問公司Software Improvement Group(簡稱SIG)，負責審驗程式碼的工作。在開發期間，團隊每周五把程式碼送往SIG檢查，審驗成果在下周二就會送回來，方便團隊在每個星期三進行討論和規劃。

•  追求符合品質標準

        除了成果審驗以外，HaMIS專案也向德國的第3方測試認證機構 TüVIT申請軟體品質認證，並委託SIG協助建立使用情境，並確保專案產出的文件和執行的成果，符合TüVIT的檢驗標準。[6]

• 鼓勵團隊追求創新

        專案難免會遇到技術瓶頸，必須不斷創新，才能突破障礙，而實際投入開發工作的開發人員，就是技術創新的原動力。因此，HaMIS專案每季舉辦1次ShipIt Day活動。允許開發同仁，在ShipIt Day的24小時當中，放下手邊的工作，自由決定要開發什麼程式，這個鼓勵創新的ShipIt Day，遊戲規則只有簡單的3句話：[7]

想到的點子或主題，多多少少要和進行中的專案有關.

同仁在開工前，至少要對2個同事推銷過想法

活動結束時，不管有沒有實際成果，都要向團隊所有同仁展示

HaMIS專案團隊ShipIt Day活動方式

時間	活動內容
2周前	向同仁說明開發的想法
當天前	寫下「出貨訂單」(Shipment Orders)，描述開發願景，組成團隊
當天下午2點	啟動ShipIt Day活動
當天下午6~7點	吃晚飯
熬夜時段	如果需要，可以繼續工作
隔天上午10點	主辦人提醒各組抓取成果畫面，或把成果拍成影片
隔天下午3點	停止開發，每組向同仁展示成果
隔天下午3點30分	全體同仁投票選出ShipIt活動冠軍
隔天下午4~5點	活動結束，同仁聊天喝飲料慶祝

資料來源：https://blog.codecentric.de/en/2014/05/organizing-shipit-day/#more-22799

3. 執行成效

        在Visser帶領下，鹿特丹港的HaMIS系統主要功能在2011年4月開始上線，開始針對港區的船隻動態，提供即時的視覺訊息。[8]

 HaMIS系統參考畫面

資料來源：http://www.portofrotterdam.com/en/News/pressreleases-news/Pages/stars-port-rotterdam.aspx

         2011年10月間，HaMIS專案得到TÜViT軟體產品認證最高的5顆星評價，成為史上第2個獲得這項殊榮的組織。到了2013年底，HaMIS又擴充了偵測船隻(Inspecting Ships)的功能，讓港務相關同仁可以在系統上，掌握危險性貨櫃(Dangerous Cargo)的位置以及載運內容。[9]

        針對這個成功的案例，Visser自己覺得，最重要的關鍵是用自己人開發(In-House)，來提升業務同仁和開發人員之間的溝通學習效能，而在鹿特丹港自己發表的新聞稿(Press Release)上，當局則是把功勞歸給敏捷開發，因為這種工作方式，「讓專案有機會應用先進的知識來開發，並同時交付比較好的軟體產品。」

---

[1] Port of Rotterdam, Port Statistics 2013, p 17.

[2] Ben Linders, “Agile Adoption in the Public Sector: FBI and Port of Rotterdam.” See http://www.infoq.com/news/2013/02/agile-public-sector

[3] 請參考http://www.xpday.net/Xpday2012/public_program/sessions/103/public.html

[4] Mark Chillingworth, “CIO Lourens Visser keeps Port of Rotterdam's systems ship-shape.” See http://www.cio.co.uk/profile/lourens-visser/28-11-2012/?page=1

[5] RUP是Rational Software提出的反覆式軟體開發流程，把專案生命週期分為Inception、Elaboration、Construction和Transition等4大階段。2003年Rational Software被IBM併入旗下。

[6] TüVIT的德文名是TÜV Informationstechnik GmbH，是非常具有公信力的資訊產品、系統、流程和基礎設設的授證單位。TüVIT網址請參考https://www.tuvit.de/en/index.htm

[7] 請參考Miel Donkers 的文章，https://blog.codecentric.de/en/2014/05/organizing-shipit-day/#more-22799

[8] Port of Rotterdam Authority, Five Stars for Port Rotterdam, see http://www.portofrotterdam.com/en/News/pressreleases-news/Pages/stars-port-rotterdam.aspx

[9] Please see http://www.amsterdamports.com/Eng/shipping/sea-shipping-and-sea-cruise/HaMIS,-one-information-system-for-Rotterdam-and-Amsterdam.html

時間

活動內容

2周前

向同仁說明開發的想法

當天前

寫下「出貨訂單」(Shipment Orders)，描述開發願景，組成團隊

當天下午2點

啟動ShipIt Day活動

當天下午6~7點

吃晚飯

熬夜時段

如果需要，可以繼續工作

隔天上午10點

主辦人提醒各組抓取成果畫面，或把成果拍成影片

隔天下午3點

停止開發，每組向同仁展示成果

隔天下午3點30分

全體同仁投票選出ShipIt活動冠軍

隔天下午4~5點

活動結束，同仁聊天喝飲料慶祝

政府機關敏捷案例：英國國防部CIDS系統

   這是一個攸關人命的專案，在充滿不確定性的情況下，英國國防部決定放棄傳統「先寫作文再做事」的計畫驅動作法，改用可以直接看到成果的敏捷式作法，以下是他們的故事。

Source: Stuart Henson & Jon PriorUK, MOD Combat Identification Server Technology Demonstrator Programme,

    戰爭期間的傷亡，不見得都是敵人攻擊造成的。[1] 2009年1月14日，英國在阿富汗參與的反恐戰爭，發生自家人誤殺自家人的事件。英國皇家砲兵上尉Tom Sawyer和海軍陸戰隊下士Danny Winter，在掃蕩塔利班(Taliban)據點的任務中，因為視線不佳難分敵我，遭到聯軍的迫擊砲誤擊斃命。在此之前，英國皇家海軍陸戰隊中校Jonathan Wigley，在2006年12月間，也是在美國海軍軍機突襲任務中遭誤擊身亡。[2] 在軍事科技發達的今天，這種友軍砲火（friendly fire）意外發生的原因，不是武器打不準，而是武器發射之前，自家部隊之間，無法及時判斷情勢(situational awareness)，辨別戰場上哪些是自己人，哪些才是敵人。為了降低友軍砲火造成的傷害，英國國防部(Ministry of Defense, MoD)決定開發一套戰鬥識別系統(Combat Identification System, CIDS)，避免悲劇繼續發生。

        CIDS專案在2009年1月發包，軍火大廠通用動力公司(General Dynamics, GD)英國分公司得標，GD找來美商洛克威爾柯林斯(Rockwell Collins)和英商QinetiQ，組成專案團隊，負責開發這套用來整合空中資源，自動即時追蹤部隊動態，避免砲火誤擊聯軍部隊的資訊系統。

1. 專案背景

        CIDS專案的成果，在2010年7月就要上線，在短短18個月內，不但要進行功能開發、整合測試，還要根據事先議定的通訊介面，測試英國的CIDS系統，是不是能和美國等「友軍」的CIDS系統，在戰場上即時互動溝通(interoperability)。為了達到這些目標，英國國防部首開先例，決定採用可以快速看到實際成果的敏捷方法，推動這個人命關天的專案。英國國防部選擇的敏捷方法，是在英國盛行的DSDM Framework，其中DSDM是「動態系統開發法」(Dynamic Systems Development Method)的簡稱。[3]  

    按照DSDM Framework，英國CIDS系統發包後的第1個階段稱為Foundations，此時的工作重點是制定高階的需求基準(baseline)，作為後續開發和付款的依據，這個階段相當於傳統專案管理的規劃階段。由於英國的CIDS系統預計在2010年夏天，就和美國等其他北約國家組織的聯軍CIDS系統，進行演習測試，英國國防部和GD經過協商，雙方同意在時程不能跳票的大前提下，根據團隊能夠實際交付的產能，動態調整需求的範圍。

2. 導入過程

    為了爭取時效，英國CIDS專案揚棄了以往先做詳細規劃再進行開發的作法(Big Design Up-Front, BDUP)，只花了「剛剛好」的時間在前期規劃(Enough Design Up-Front, EDUF)上。在Foundations階段，英國國防部釐清需求方向、開發團隊制定開發架構，雙方據以共同決定可以接受的最低成效標準(minimum acceptable performance levels)。例如，CIDS系統至少要在戰場上同時追蹤15個動態，而且要保留彈性，除了能追蹤砲兵的即時位置以外，附近航空器的動向，也要能整合進來。

1.1 根據專案實際需求，訂定階段過關條件

        Foundations階段進行了3個月之後，專案循序漸進地進行了3個開發周期 (Iteration)，每期的長度從3個月到6個月不等，根據英國國防部的規劃，做完3個開發期之後，英國的CIDS系統要在2010年6月實機展示，並在7月份就布署上線。其中每個階段的過關條件是：[4]

英國CIDS專案期程目標

期程	階段目標
第1期	建立1個簡單的版本，做到1次可以追蹤1組友軍的位置
第2期	擴充第1期的成果，做到1次追蹤多組位置
第3期	提升系統的穩健度和處理速度，並和友軍的CIDS系統界接

1.2 捨棄計畫驅動作法，改採價值驅動思維

    不論用什麼開發方法，需求管理機制是專案成敗的關鍵因素。以往，軟體開發專案採用瀑布式開發流程，把專案切割成規劃、需求、分析、設計、實作和測試等階段，每一個階段的產出品，經過正式的簽認，才能成為下一個階段的輸入項目，這種開發思維源自營建業，適合用在客戶一開始就能完整且精確描述需求的專案上。如果從專案需求、成本和時程這3個核心限制(triple constraint)的先後順序來觀察，瀑布式開發是先確定需求，再據以推估出為了要交付出全部需求，在每個階段各要投入多少的成本、多長的工期，由於推估的成果就是專案執行計畫的基準(baseline)，因此這種方法的特色就是「計畫驅動」(plan driven)。

從計畫驅動轉變到價值驅動

        CIDS專案採用的DSDM Framework，顛覆了以往計畫驅動的做法。在專案初期，英國國防部和GD團隊，沒有多花時間撰寫詳細的需求和設計文件。取而代之的是，英國國防部只在期初列出大致的核心需求，並按照優先順序，建立了一份需求清單 (Prioritized Requirements List, PRL)。如果從專案的3個核心限制來說，CIDS專案中先確定是成本和時程，也就是契約的總價，以及官方對外公布的上線時間，至於PRL裡面的需求，全部加起來就是專案的範圍，在使用敏捷方法的專案中，需求方可以根據團隊實際交付的成果，調整專案剩餘的需求，如果團隊產能落後，需求方會移除非必要的功能，讓團隊能夠集中力量做重要的事，如果團隊產能許可，需求方也可能提出一些新需求，讓最終成品更能發揮價值。團隊開發的依據，不再是一本厚重的規格文件，而是一份與時俱進的需求清單。

1.3 依照需求輕重緩急，排列工作優先順序

        CIDS專案的PRL清單上，分為Must Haves、Should Haves、Could Haves和Won’t Haves這4類的需求，合稱為MoSCoW，其中：

PRL清單的4種需求優先順序

優先順序	意義
Must Haves	CIDS的核心特色，也就是根據契約規定，一定要完成的功能
Should Haves	沒做出來使用者會不舒服，但暫時有替代方案的功能
Could Haves	「加分」的功能，但沒有立即的需要
Won’t Haves	暫時不考慮開發的功能

    不論是哪一類優先順序的需求，每一個需求上都有代表需求難易度的點數，稱為「故事點」(story point)，如果把最近一個開發周期中，所有完工需求上的故事點總加起來，得到的數字稱為「速度」(velocity)，代表的是開發團隊的最新產能，可以用來預估完成剩餘需求所需的工期。根據DSDM Framework的建議，每個開發周期中，Must Haves需求的點數最好不要超過當期總合的6成，要預留4成的Should Haves和Could Haves需求，讓開發團隊在實踐Must Haves需求遭遇瓶頸時，還能夠調度執行次要需求的人力來支援。[5]

DSDM建議的優先順序比率

        DSDM需求管理機制的背後，有3個重要的運作原則：

第一、為了確保在開發周期如期交付最重要的Must Haves需求，團隊成員有權作出可以縮短交付時間的決策。

第二、PRL清單上的優先順序，會隨著專案進展而改變，例如，前一期列為Should Haves的某項需求，可能在下一期變成Must Haves的需求。

第三、開發出來的需求，如果在功能、效能或穩定度上無法達到品質標準，需求方可以在當期拒絕收受(descope)。

1.4 鼓勵儘早發現錯誤，落實需求交換機制

    CIDS專案的3個開發周期，長度從3個月到6個月不等。每個開發周期內，以每個月為1個時限(timebox)，期間包括領域專家在內的開發團隊成員，可以不受外界打擾地進行開發工作，如果在團隊成員時限執行期間，感受到有Must Haves需求無法如期交付的風險，開發團隊有權把原本執行Should Haves或Could Haves需求的人力，調撥來支援更重要的需求。[6]

另外，CIDS專案鼓勵開發團隊，針對目標、需求或功能的未盡之處，儘早提出建言，開發過程中若是發現做不出來的功能，要在第一時間就告知需求方，才能儘早安排解決或替代方案。英國國防部同意，如果開發團隊按照需求團隊開發的功能，後來證明不可行，團隊已經投入的時間，可以用來抵銷PRL清單中的一些還沒開發的次要功能，這就是CIDS專案的需求交換機制。

1.5 指派專責需求窗口，快速做出重要決策

    在GD專案經理的帶領下，2家下包商的的工程人員，和英國國防部的職員和技術顧問，共同組成了一支跨職能的專案團隊。英國國防部指派了一名承辦官員(Business Sponsor)，負責整個CIDS專案的成敗，並指派另一人擔任Business Visionary，負責針對日常發生的議題，做出快速的決策。為了在專案中避免不確定的事情發生，專案團隊建立了一套風險登記冊(risk register)，並把風險應對措施，也列入PRL清單中當成待辦項目。

3. 執行成效

    英國國防部採購部門原本提出的契約條款，是基於範圍固定(fixed scope)的原則，承商如果有任何「沒做到的事」，不論需求的重要度有多低，都得面臨嚴厲的罰則。CIDS專案引入DSDM Framework的敏捷方法之後，英國國防部和承商之間，逐漸建立起一種協同合作的關係，有關需求的議題，都透過交換機制獲得解決。後來，英國CIDS系統，如期在2009年夏天就開始在Battlespace實驗室展開整合測試，並在2010年夏天，透過參與北約在挪威的演習，和美國的CIDS系統交換資訊。演習期間，英國CIDS系統，不但針對7種不同的陸空系統，提供超過90種動態的友軍識別資訊，而且還做到平均識別時間在3秒以內，精確度少於5公尺的程度。

    CIDS專案導入敏捷方法的成效，受到英國政府的重視。英國國家審計局(National Audit Office, NAO)的一項報告指出，英國政府在資訊和通訊科技類採購案(information and communications technology, ICT)，希望採用敏捷方法降低專案失敗的風險。英國內閣辦公室(Cabinet Office)也在2011年間設定目標，要透過敏捷方法，在2014年以前把ICT計畫的平均交付時間縮短20%。[7]

---

[1] 寧博，脫離友軍砲火利器-戰鬥辨識系統(Reducing Fratricide: Combat Identification System)，全球防衛誌249期，2005年5月。

[2] Rachel Williams and Martin Hodgson, MoD launches friendly fire investigation into deaths of two British soldiers in Afghanistan, The Guardian, 17 January 2009. See http://www.theguardian.com/politics/2009/jan/17/mod-friendly-fire

[3] 1994年1月，來自英國航空(British Airways)、美國運通(American Express)和甲骨文(Oracle)等大廠的16位資訊業專家，在英國倫敦共同創立了DSDM Consortium，期望發展出一套快速應用程式開發框架(Rapid Application Development )，DSDM後來幾經演進，內容越來越完整，2001年公布的軟體敏捷開發宣言(Manifesto for Agile Software Development)中，來自DSDM Consortium的Arie van Bennekum也是起草人之一。請參考DSDM官網：http://www.dsdm.org/content/history-dsdm

[4] CIDS專案所稱的Iteration，相當於軟體開發的Release。

[5] 有關MoSCow應用，請見DSDM官網：http://www.dsdm.org/content/10-moscow-prioritisation

[6] 時限(timebox)，相當於Scrum Framework裡面的Sprint。

[7] NAO, Governance for Agile Delivery, P 7.