2014年7月23日 星期三

政府機關敏捷案例:荷蘭鹿特丹港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
     
        鹿特丹港的最大特點,就是儲、運、銷一體化的流程。來自各地的貨物,在港區加值加工後,可以方便地透過陸、海、河、空等多種運輸路線,分銷到歐洲各地。根據荷蘭官方的統計,如果把交通業、工業和零售業全部算起來,在鹿特丹港就業的人數超過92千人,經濟規模超過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多個套裝軟體後發現,鹿特丹港的業務流程非常複雜,沒有現成的軟體可以應付,就算委外開發,廠商短期內也搞不懂港務的領域知識:「我們無法讓IBMCapgemini聽懂需求,因此專案註定會失敗。」面臨這樣的難題,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專案每季舉辦1ShipIt Day活動。允許開發同仁,在ShipIt Day24小時當中,放下手邊的工作,自由決定要開發什麼程式,這個鼓勵創新的ShipIt Day,遊戲規則只有簡單的3句話:[7]

想到的點子或主題,多多少少要和進行中的專案有關.
同仁在開工前,至少要對2個同事推銷過想法
活動結束時,不管有沒有實際成果,都要向團隊所有同仁展示


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

3. 執行成效
        在Visser帶領下,鹿特丹港的HaMIS系統主要功能在20114月開始上線,開始針對港區的船隻動態,提供即時的視覺訊息。[8]

 HaMIS系統參考畫面

         201110月間,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
[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] RUPRational Software提出的反覆式軟體開發流程,把專案生命週期分為InceptionElaborationConstructionTransition4大階段。2003Rational SoftwareIBM併入旗下。
[6] TüVIT的德文名是TÜV Informationstechnik GmbH,是非常具有公信力的資訊產品、系統、流程和基礎設設的授證單位。TüVIT網址請參考https://www.tuvit.de/en/index.htm
[8] Port of Rotterdam Authority, Five Stars for Port Rotterdam, see http://www.portofrotterdam.com/en/News/pressreleases-news/Pages/stars-port-rotterdam.aspx

2014年7月2日 星期三

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

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


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


    戰爭期間的傷亡,不見得都是敵人攻擊造成的。[1] 2009114日,英國在阿富汗參與的反恐戰爭,發生自家人誤殺自家人的事件。英國皇家砲兵上尉Tom Sawyer和海軍陸戰隊下士Danny Winter,在掃蕩塔利班(Taliban)據點的任務中,因為視線不佳難分敵我,遭到聯軍的迫擊砲誤擊斃命。在此之前,英國皇家海軍陸戰隊中校Jonathan Wigley,在200612月間,也是在美國海軍軍機突襲任務中遭誤擊身亡。[2] 在軍事科技發達的今天,這種友軍砲火(friendly fire)意外發生的原因,不是武器打不準,而是武器發射之前,自家部隊之間,無法及時判斷情勢(situational awareness),辨別戰場上哪些是自己人,哪些才是敵人。為了降低友軍砲火造成的傷害,英國國防部(Ministry of Defense, MoD)決定開發一套戰鬥識別系統(Combat Identification System, CIDS),避免悲劇繼續發生。
        CIDS專案在20091月發包,軍火大廠通用動力公司(General Dynamics, GD)英國分公司得標,GD找來美商洛克威爾柯林斯(Rockwell Collins)和英商QinetiQ,組成專案團隊,負責開發這套用來整合空中資源,自動即時追蹤部隊動態,避免砲火誤擊聯軍部隊的資訊系統。
        CIDS專案的成果,在20107月就要上線,在短短18個月內,不但要進行功能開發、整合測試,還要根據事先議定的通訊介面,測試英國的CIDS系統,是不是能和美國等「友軍」的CIDS系統,在戰場上即時互動溝通(interoperability)。為了達到這些目標,英國國防部首開先例,決定採用可以快速看到實際成果的敏捷方法,推動這個人命關天的專案。英國國防部選擇的敏捷方法,是在英國盛行的DSDM Framework,其中DSDM是「動態系統開發法」(Dynamic Systems Development Method)的簡稱。[3]  
    按照DSDM Framework,英國CIDS系統發包後的第1個階段稱為Foundations,此時的工作重點是制定高階的需求基準(baseline),作為後續開發和付款的依據,這個階段相當於傳統專案管理的規劃階段。由於英國的CIDS系統預計在2010年夏天,就和美國等其他北約國家組織的聯軍CIDS系統,進行演習測試,英國國防部和GD經過協商,雙方同意在時程不能跳票的大前提下,根據團隊能夠實際交付的產能,動態調整需求的範圍。
    為了爭取時效,英國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系統要在20106月實機展示,並在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 HavesShould HavesCould HavesWon’t Haves4類的需求,合稱為MoSCoW,其中:
PRL清單的4種需求優先順序
優先順序
意義
Must Haves
CIDS的核心特色,也就是根據契約規定,一定要完成的功能
Should Haves
沒做出來使用者會不舒服,但暫時有替代方案的功能
Could Haves
「加分」的功能,但沒有立即的需要
Won’t Haves
暫時不考慮開發的功能

    不論是哪一類優先順序的需求,每一個需求上都有代表需求難易度的點數,稱為「故事點」(story point),如果把最近一個開發周期中,所有完工需求上的故事點總加起來,得到的數字稱為「速度」(velocity),代表的是開發團隊的最新產能,可以用來預估完成剩餘需求所需的工期。根據DSDM Framework的建議,每個開發周期中,Must Haves需求的點數最好不要超過當期總合的6成,要預留4成的Should HavesCould 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 HavesCould Haves需求的人力,調撥來支援更重要的需求。[6]
另外,CIDS專案鼓勵開發團隊,針對目標、需求或功能的未盡之處,儘早提出建言,開發過程中若是發現做不出來的功能,要在第一時間就告知需求方,才能儘早安排解決或替代方案。英國國防部同意,如果開發團隊按照需求團隊開發的功能,後來證明不可行,團隊已經投入的時間,可以用來抵銷PRL清單中的一些還沒開發的次要功能,這就是CIDS專案的需求交換機制。
1.5 指派專責需求窗口,快速做出重要決策
    在GD專案經理的帶領下,2家下包商的的工程人員,和英國國防部的職員和技術顧問,共同組成了一支跨職能的專案團隊。英國國防部指派了一名承辦官員(Business Sponsor),負責整個CIDS專案的成敗,並指派另一人擔任Business Visionary,負責針對日常發生的議題,做出快速的決策。為了在專案中避免不確定的事情發生,專案團隊建立了一套風險登記冊(risk register),並把風險應對措施,也列入PRL清單中當成待辦項目。
    英國國防部採購部門原本提出的契約條款,是基於範圍固定(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)全球防衛誌24920055月。
[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] 19941月,來自英國航空(British Airways)、美國運通(American Express)和甲骨文(Oracle)等大廠的16位資訊業專家,在英國倫敦共同創立了DSDM Consortium,期望發展出一套快速應用程式開發框架(Rapid Application Development )DSDM後來幾經演進,內容越來越完整,2001年公布的軟體敏捷開發宣言(Manifesto for Agile Software Development)中,來自DSDM ConsortiumArie 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.