2014年12月31日 星期三

PM學越多賺越多,甘係金ㄟ?

徐柏峰
圖片來源:http://www.imdb.com/title/tt0119695/
中世紀的英國科學家法蘭西斯‧培根說:「知識就是力量」(Knowledge is power),後來有人把這句話改編成「知識就是財富」(Knowledge is wealth)。以「大中華地區」的幾個主要國家來說,在專案經理這個位子上,學歷越高的人,以及每年花越多時間受訓學習的人,是不是就能賺越多薪水呢?專案管理協會(Project Management Institute, PMI)的薪資統計,顯示出很有趣的結果。
先從學歷來說,可以發現:

  • 有碩士學位的PM,在台灣、新加坡和中國,確實比大學畢業的PM還吃得開
  • 擁有博士學位的PM,拿到的薪水又比碩士還要高
  • 不過有趣的是,在香港的碩士PM,薪水竟然還比學士PM還低一點

Source: Project Management Salary Survey, 8th


再從每年花多少時間受訓來觀察:

  • 在台灣和新加坡,越喜歡「充電」的PM,確實拿到比較高的年薪
  • 在香港和中國的職場上,每年投資59天受訓的PM,「薪情」比受訓時間較少的同事稍微好一點,不過,如果PM上課時間超過10天,薪水反而是會倒退嚕的喔!
Source: Project Management Salary Survey, 8th

2014年12月5日 星期五

用愛敏捷,擁抱變更

這幾年來,一群沒有真的上場輔導過企業的「管理顧問」,靠著填鴨量產的手法,製造了「PMP人數全球名列前茅,薪資水平幾乎敬陪末座」的台灣奇蹟。其實,補習班產能極大化的過程,就是一個專業認證邊際效用遞減的過程。這些補習班的輔考大隊教的,不是真正在職場上用得到的知識,而是進場考試時,可以選對答案的技巧。在補習班張貼榜單,炫耀產量的同時,有多少人回到工作崗位上真的升官發財,還提升了個人、企業、組織和國家的競爭力呢?拜託別再吹了!!!填鴨補習班補出來的「黃金證照」裡面如果有黃金,一兩就是補習班收走的報名費,另一兩就是學員交的考試費,醒醒吧!!!
身為敏捷教練,我想改變這個文化,我的方法就是「用愛敏捷」,一面推廣敏捷專案管理的實際做法,一面幫弱勢的朋友們募款。我承認,這裡沒有黃金,不過卻有滿滿的愛心。

第1話
2014年10月份,「叫我第一名」團隊的11成員,幫偏遠山區的老人、印度學童,還有世界展望會,募得10,200元,這群有志之士當中,來自香港的資深念佛人Jefferey大哥,在上課最後一天當天就考過PMI-ACP,接著就飛回去支持佔中,寫下無人能及的紀錄;又青、彥豪、毓婷和華佩等人,則是在政府資訊委外案中落實敏捷方法的第一批人;政育和明莉是篤信敏捷實務且熱心公益的夫妻檔;至於敏宏、志尤、逸群和珮泰,也都是準備在工作上實際用敏捷改變周遭的人。



第二話
2014年11月份,加入「人生但求一爽」隊的12名敏捷人,幫聖心幼稚園、家扶基金會和一位弱勢的單親媽媽,募到了7,500元。活動結束後1周內,Callie和Sten就陸續拿下PMI-ACP,以身作則示範敏捷的精神。
感謝Anna, 凱元、Callie、Gavin, Moody、Clause、阿中哥、Roman Tsai、Sten Feng、文昇哥、Alex Lin和Jiunchi和志尤哥的愛心,我們一起敏捷吧!







2014年10月14日 星期二

台灣政府敏捷首例

徐柏峰
2014年間,輔導國家災害防救科技中心導入敏捷方法,成就了台灣第一個機關敏捷的案例,以下是他們的故事...



「終」「始」卓越品質
資訊服務委外運用敏捷方法之經驗分享
國家災害防救科技中心 張志新博士、林又青助研究員

對任何機關來說,開發資訊系統,就是要幫使用者解決問題或創造機會。執行專案的過程一定要投入成本、人力和時間,怎樣才能有效率的工作,又能產出高品質的成果呢? 2014年間,國家災害防救科技中心(簡稱NCDR),在行政院NICI小組成立之政府資訊委外服務團的協助下,率先在國內機關導入敏捷方法,執行資訊服務委外專案,堅持「以終為始」(To Begin with the End)的心態,獲致了豐碩的成果。本文以委外機關的觀點,分享這次成功的經驗。

災害事件調查,需要使用大量資料
    國家災害防救科技中心成立以來,執行多次重大天然災害事件調查,經歷2009莫拉克颱風全台災害調查、2010凡那比颱風高雄與屏東災害調查等,每次調查過程中,都需要大量的影像圖資、表單紀錄與填寫、影音記錄、座標紀錄等繁複的工作,每次調查過後,還需要投入大量的後續分析作業。

資料來源:Google街景圖、NCDR
災害事件調查範例
使用行動裝置,可以提升調查效率
2012年紐約遭受SANDY颶風侵襲,一周以後,網路上就陸續公布大量災後調查成果,效率之快,令人驚艷。原來,負責災害調查的美國聯邦緊急事務管理署(Federal Emergency Management Agency , FEMA),在Sandy颶風侵襲後立即派出勘災人員,攜帶行動裝置深入災區,進行災後調查與損失評估,利用網路無遠弗屆的特性,在最短的時間內就把災害資訊對外公開。
資料來源:FEMA
美國FEMA災後評估與災害認定
透過網路連結,整合勘災調查資料
NCDR受到FEMA作法的啟發,提出行動災害調查的構想,希望發揮行動裝置輕便的特性、儲存動態資訊的能力,整合精密電子設備,透過網路連結,提升災害調查的效率。NCDR內部經過一番討論,決定開發屬於國人的《行動災害調查APP》,提供以下功能:
  • 圖層資訊功能,含地圖(含離線地圖)、流域水系分布圖、衛星影像等有助於災害勘查的資訊;
  • 調查表單填寫功能,含坡地災害、土石流災害、水災與聚落環境調查等表格填寫;
  • 調查輔助工具,含影音記錄、異地座標定位、災害範圍圈繪計算、距離量測、圖畫影像筆記本註記功能等;
  • 離線作業與勘災資訊回傳功能;
  • 以及災害事件簿資料庫管理與網頁綜整及展示勘災資料等功能。
資料來源:NCDR
行動災害調查與災害事件簿
導入敏捷方法,整合了想法與做法
NCDR同仁,全部都是學有專精的領域專家,對於開發《行動災害調查APP》,提出非常專業的想法。不過,由於同仁多為研究人員,不見得有軟體開發專長,也不一定具備專案管理的經驗,而承包開發的資訊團隊,也不是來自災害調查的相關領域。因此,在這次的資訊委外開發專案中,要讓開發團隊了解業務單位的專業需求,掌握專案真正的進度,以及確保交付成品符合設計的構想,就成為執行專案的最大挑戰。
所幸,就在專案已經發包,即將啟動的時候,政府資訊委外服務團,前來NCDR推廣導入「敏捷式專案管理」,適時地解答了我們的疑惑。敏捷方法主張用「以終為始」的心態,先確定要解決的問題是什麼,然後把資訊團隊當成開發夥伴,定期透過面對面溝通,檢視實際的軟體產出,據以提出優化的新需求,一步一腳印地創造出真正解決問題的最終成品。這一套方法,和這幾年來NCDR力推的「設計思考」(Design Thinking)非常接近,也因此,我們一拍即合,決定導入敏捷方法,而承包廠商的主管和專案經理,在明知溝通量會增加的情況下,也非常配合,同意全力投入這個敏捷專案。就這樣,國內第一個政府機關導入敏捷方法的案例,跨出了成功的第一步。

敏捷專案管理,核心就是做事態度
軟體開發專案,本質上就是集合團隊的專長,共同創作出成品的過程。90年代以來,業界先進逐漸體認到,在不確定性高卻要快速產出結果的專案中,要增加成功的機會,就要摒棄70年代以來,「先寫大量計畫文件才進行開發,最後才做測試」的瀑布式作法。在軟體專案中,客戶一開始往往只能講出需求的大方向,唯有透過不斷操作實際的產出,才會逐步淬煉出符合使用者需求的最終成品,因此可以說,軟體開發本身就是一個不斷變動的過程,透過詳細計畫驅動開發,其實是本末倒置的做法。基於這個體認,2001年間,17位資訊界大老齊聚一堂,用短短的4句話,道出敏捷方法的核心理念:
資料來源:Manifesto for Agile Software Development
敏捷軟體開發宣言與知名敏捷方法
活用敏捷精神,制定協同合作規則
NCDR這次領風氣之先,引入敏捷開發的精神,將原本專案RFP內所列構想進行拆解,由開發團隊估算各項工作的複雜程度,排定開發期程並透過雲端看板追蹤需求執行情況,過程中「敏捷式專案管理」,協助我們釐清專案需求,確認如何驗收每一項需求,使得與廠商溝通更順暢。執行專案期間勢必調整APP需求開發排序,在不違背大原則情況下,調整工作優先順序,在敏捷專案導入後,重新排程。至於實際運作方面,我們在專案初期,就決定採取以下的開發模式:
  • 將期中和期末,各視為1個里程碑,稱為Release
  • 每個Release開始前,先進行Roadmap Planning NCDR承辦人先逐一說明待開發需求,交由開發團隊溝通並評估複雜度,再交由NCDR需求窗口決定每個需求的優先順序;
  • 為了避免遺漏,使用雲端看板,登錄相關的需求內容,以及需要討論的議題;
  • 以每2周為開發周期(Iteration),每期的期初都透過面對面溝通,規劃當期需求,每個需求都有明確的過關條件(Acceptance Criteria或稱為How to Demo),讓團隊有所依循;
  • 每期期末由需求窗口實機操作,根據過關條件,逐一驗證需求是否達到可以接受的標準;
  • 需求窗口根據實機操作的結果,評估是否需要提出新需求,如果有新需求,就儘量在尚未開發的功能中,淘汰不再需要的需求來交換新需求;
  • 專案執行的過程中,只要有需求要釐清,或是有議題要反應,不論是NCDR對開發團隊,還是開發團隊對NCDR,都儘量在第一時間內,直接透過電話,或是面對面溝通。
Roadmap Planning
R
以實機操作驗證需求

提出新需求,汰換舊需求


        秉持以終為始,成就優質委外專案
在導入敏捷的過程中,NCDR、開發廠商和政府資訊委外服務團這3方,都投入了不少的人力與工時,我們堅持以終為始的信念,交出了傲人的成績:
l   在專案啟動後第3周,就開始交付出實際成果,並適時進行現地驗證;
l   2周都依據實機操作結果,調整需求;
l   啟動後3個月,執行期中驗收,功能已經完成80%
l   專案進行中,定期進行回顧討論,並根據團隊意見,修改工作流程;
l   專案尚未結束,已經有實際《行動災害調查APP》,用在進行災害調查;
l   高雄氣爆事件後2天,就因應需求擴充出勘災相關功能

後記
本專案是在RFP公告後才開始導入敏捷方法,對所有參與的夥伴來說,除了原本規劃給專案的時間以外,還要額外預留學習新方法的時間,以及衍生的溝通時間。這次參與專案的所有夥伴,在導入的整個過程中,都非常積極主動參與付出,我們很高興,透過NCDR同仁、開發團隊和政府資訊委外服務團三方的協同合作,過程中團隊的每一個人都有參與感,雖然這樣的工作模式並不會減輕工作量,但是整個過程都是學習與成長,無形中團隊在成長、團隊在調整工作模式、提升協調溝通技巧、享受開發成果的展現與獲得肯定。以上過程的無形的效益與未來可能的發展,遠勝於本專案提升20%30%的績效,或是壓縮多少工作期程!

感謝
政府資訊委外服務團吳仁傑主任、林祖馨顧問、邱淑敏顧問、徐柏峰教練
本中心同仁林又青、傅鏸漩、王俞婷、吳啟瑞、黃俊宏
凌網科技賴彥豪、朱毓婷、林宜明、蔡孟玹


2014年8月1日 星期五

政府機關敏捷案例:澳洲昆士蘭州政府HNA系統

徐柏峰


昆士蘭州政府公共住宅申請網頁
    
        澳洲政府導入敏捷的案例,可以追溯到2005年。有陽光之州(Sunshine State)美稱的昆士蘭(Queensland),為了照顧中低收入戶,提供社會住宅(Social Housing)服務,補貼租屋開支,全昆士蘭470萬人口中,大約有24萬人,住在政府補貼的社會住宅裡。  不過,澳洲近年來房價水漲船高,申請社會住宅的戶數越來越多,排隊等待的名單(Wait List)超過35,000戶,這龐大的業務壓力,就落在昆士蘭各地10大城市的70名承辦人員身上,造成申請的家庭急得跳腳,承辦人員也莫可奈何的窘境。為了改善這個情況,昆士蘭州住房與公共工程部(Department of Housing and Public Works)2005年宣布,投入235百萬澳幣,以4年為期,為昆士蘭人(Queenslanders)重新打造適用的社會住宅申請機制。

1. 專案背景

    既有的申請機制,採用的先進先出的原則,每當空的社會住宅釋出,承辦人員就從等待名單中,挑出等最久的出來審核,很多家庭不管是不是真的需要,就先搶著提出申請「占位子」,造成等待名單越來越長。為了讓政策更公平,並讓申請程序更有效率,昆士蘭當局制訂了「單一社會住宅政策」(One Social Housing Policy),打算建立一套有效的評估標準,把等待名單分為4級,方便承辦人員判定誰才最需要住進社會住宅。

澳洲昆士蘭州公共住宅等待名單等級
等級
說明
極度需要
Very High Need
無家可歸或現住所不適合居住,且租賃或繼續租賃私有住宅遭遇很多問題(issue)
高度需要
High Need
現住所不適合居住,且租賃或繼續租賃私有住宅遭遇一些問題
中度需要
Moderate Need
現住所不適合居住,且租賃或繼續租賃私有住宅遭遇少許問題
低度需要
Lower Need
現住所適合居住,雖遭遇問題,仍能負擔租賃私有住宅
資料來源:昆士蘭州政府公共住宅官網

        經過規劃,住房與公共工程部決定,昆士蘭需要的是一個評估申請案的線上平台,專案名稱就叫做「住宅需要評估專案」(The Housing Needs Assessment Project, HNA)。不過,新法規還沒定出來,執行細節也還在變動,高層卻已經一聲令下,要求資訊部門自行開發,而且馬上就要啟動。一直以來,昆士蘭州政府就是非常重視「程序」的機關,資訊開發專案走的是瀑布式流程,專案要經過詳細的需求分析確認,才能進行開發。可是當前的HNA專案,使用需求孔急,如果按照以往的做法,一定趕不上時程。

2. 導入過程

        在這樣的兩難情況下,當時在資訊部門任職的資深工程師Adrian Royce建議,因為政策還在討論中,系統開發必須採取漸進(Incremental)的方式,一面和政策制定者討論想法,一面和實際要操作系統的承辦人討論作法。當時已經接觸敏捷開發的Adrian Royce提議,在這個專案導入Scrum方法,獲得同事之間大力支持。澳洲政府導入敏捷方法的第一個專案,就此開始。

2.1 透過Scrum of Scrums,協調3組開發團隊

HNA專案啟動之初,團隊人數只有13人,隨著系統需求陸續浮現,團隊人數逐漸成長到68人,這當中,軟體工程師有23人,包括使用者在內的其他成員有45人,是不折不扣的「跨領域」(Multi-Disciplinary)團隊。這68個人組成的大開發團隊,分成3個小開發團隊,小隊成員間每天舉行站立會議(Stand-up Meetings),先同步彼此工作進度,再派員參加跨團隊的Scrum of Scrums會議,溝通團隊之間的進度。[1] 為了方便責任分工,HNA專案功能區分成「等待名單管理」、「申請戶資格評分」和「整合既有系統」3大模組,由每個小開發團隊個別負責。
以每個月為1個衝刺期(Sprint),開發團隊在每期期末交付出實際的成品,交由使用者實際操作,並根據實際操作的回饋意見,作為進一步修改的依據。

2.2 瀑布式的流程框架,敏捷式的實務做法

        HNA專案雖然使用敏捷開發,還是要兼顧機關既有的稽核和品保流程。管理當局要求,HNA專案必須按照PRINCE2的流程規範,定期回報進度。[2] 對此,HNA專案團隊不但沒有排斥,還想出在瀑布式大環境下使用敏捷開發的做法。
PRINCE2的專案管理流程

        HNA團隊根據PRINCE2的規範,在專案啟動文件中(Project Initiation Document, PID),使用產品分解結構(Product Breakdown Structure, PBS),描述專案預期產出的成品。[3] PBS上的每一個節點,就是專案的交付項目(Deliverables),可以是軟體、硬體、文件或是整合勞務等等,每個交付項目,按照「互不包含,毫無遺漏」(Mutually Exclusive, Collectively Exhaustive) 的原則,向下分解成更小、更明確、更容易管理的交付項目。把最下層的交付項目往上累加,就是專案的整個範圍,也就是專案的所有需求。在使用Scrum開發的HNA團隊眼裡,PBS就是產品需求清單(Product Backlog)


 HNA專案的PBS示意

2.3 專責的需求委員會,排定功能優先順序

        有了PBS版的Product Backlog,團隊分工就變得很簡單。HNA系統規劃的3大模組,就是3個小開發團隊各自負責的範圍。專案主要決策人員組成的需求委員會(Project Board),除了對PBS上面的需求排序,也會在每月一期的衝刺期開始之前,為各個小隊決定接著需要開發的功能,小隊成員接著就針對這些使用者需求,進行技術討論,規劃出實際的作法(Activities)
根據PRINCE2的專案管理機制,專案必須在各個階段交付文件,才能符合程序規定。對此,HNA團隊就把要交付的文件,登錄到PBS裡面當成使用者需求,由團隊成員負責編寫,確保在每個衝刺期期末的時候,專案文件都不缺漏。另外,為了避免一般專案在上線前才做整合測試的通病,HNA團隊在衝刺期間,就持續把已完成的功能送交整合測試,因此,在每個衝刺期期末的時候,團隊通過測試簽認的功能,也就越累積越多。

2.4 團隊解不了的爭議,才會尋求高層處理

        專案執行過程中,常會有需要解決的問題,一般來說,使用敏捷開發的團隊,絕大多數的問題都會在每日站立會議和Scrum of Scrums會議上,透過面對面溝通獲得解決。在HNA專案中,如果還有不能解決的問題,團隊成員才會透過「正統」的方式,把問題升高,透過PRINCE2規定的流程,尋求高層的決策。

3. 執行成效

        HNA專案的執行成果非常成功,獲得昆士蘭當局大力讚揚:「政府認為這個牽涉到設計、開發和實作的專案非常複雜,而且充滿挑戰……。專案產出的流程,以及讓服務功能上線的動作,進行地非常好。另外,在把Scrum導入昆士蘭州住房與公共工程部的期間,資訊部門的士氣大漲,創下期間留職率(Retention Rate)百分百的紀錄。到了2009年,住房與公共工程部已經在30個專案上,使用敏捷方法,而當初引進ScrumAdrian Royce,不但獲頒創新改善卓越獎的殊榮,還被挖角到昆士蘭的環境和資源管理部(Department of Environment and Resource Management, DERM),繼續推動敏捷專案管理。[4]




[1] HNA專案中,代表團隊參加Scrum of Scrums會議的是使用者專案經理(User Project Manger)Scrum Master
[2] PRINCE2PRojects IN Controlled Environments Version2的縮寫,是一套專案管理的方法論,在歐洲和大英國協的國家頗為風行。
[3] 專案管理協會(Project Management Institute, PMI)PBS稱為工作分解結構(Work Breakdown Structure, WBS)
[4] 截至20146月底為止,Adrian Royce是環境和資源管理部的開發部門經理。請參考Adrian RoyceLinkedin資料http://www.linkedin.com/in/adrianroyce

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