徐柏峰
 |
| 昆士蘭州政府公共住宅申請網頁 |
澳洲政府導入敏捷的案例，可以追溯到2005年。有陽光之州(Sunshine
State)美稱的昆士蘭(Queensland)，為了照顧中低收入戶，提供社會住宅(Social Housing)服務，補貼租屋開支，全昆士蘭470萬人口中，大約有24萬人，住在政府補貼的社會住宅裡。 不過，澳洲近年來房價水漲船高，申請社會住宅的戶數越來越多，排隊等待的名單(Wait List)超過35,000戶，這龐大的業務壓力，就落在昆士蘭各地10大城市的70名承辦人員身上，造成申請的家庭急得跳腳，承辦人員也莫可奈何的窘境。為了改善這個情況，昆士蘭州住房與公共工程部(Department of Housing and Public Works)在2005年宣布，投入2億3千5百萬澳幣，以4年為期，為昆士蘭人(Queenslanders)重新打造適用的社會住宅申請機制。
既有的申請機制，採用的先進先出的原則，每當空的社會住宅釋出，承辦人員就從等待名單中，挑出等最久的出來審核，很多家庭不管是不是真的需要，就先搶著提出申請「占位子」，造成等待名單越來越長。為了讓政策更公平，並讓申請程序更有效率，昆士蘭當局制訂了「單一社會住宅政策」(One Social Housing Policy)，打算建立一套有效的評估標準，把等待名單分為4級，方便承辦人員判定誰才最需要住進社會住宅。
澳洲昆士蘭州公共住宅等待名單等級
|
等級
|
說明
|
|
極度需要
Very High Need
|
無家可歸或現住所不適合居住，且租賃或繼續租賃私有住宅遭遇很多問題(issue)
|
|
高度需要
High Need
|
現住所不適合居住，且租賃或繼續租賃私有住宅遭遇一些問題
|
|
中度需要
Moderate Need
|
現住所不適合居住，且租賃或繼續租賃私有住宅遭遇少許問題
|
|
低度需要
Lower Need
|
現住所適合居住，雖遭遇問題，仍能負擔租賃私有住宅
|
資料來源：昆士蘭州政府公共住宅官網
經過規劃，住房與公共工程部決定，昆士蘭需要的是一個評估申請案的線上平台，專案名稱就叫做「住宅需要評估專案」(The Housing Needs Assessment Project, HNA)。不過，新法規還沒定出來，執行細節也還在變動，高層卻已經一聲令下，要求資訊部門自行開發，而且馬上就要啟動。一直以來，昆士蘭州政府就是非常重視「程序」的機關，資訊開發專案走的是瀑布式流程，專案要經過詳細的需求分析確認，才能進行開發。可是當前的HNA專案，使用需求孔急，如果按照以往的做法，一定趕不上時程。
在這樣的兩難情況下，當時在資訊部門任職的資深工程師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會議，溝通團隊之間的進度。 為了方便責任分工，HNA專案功能區分成「等待名單管理」、「申請戶資格評分」和「整合既有系統」3大模組，由每個小開發團隊個別負責。
以每個月為1個衝刺期(Sprint)，開發團隊在每期期末交付出實際的成品，交由使用者實際操作，並根據實際操作的回饋意見，作為進一步修改的依據。
2.2 瀑布式的流程框架，敏捷式的實務做法
HNA專案雖然使用敏捷開發，還是要兼顧機關既有的稽核和品保流程。管理當局要求，HNA專案必須按照PRINCE2的流程規範，定期回報進度。 對此，HNA專案團隊不但沒有排斥，還想出在瀑布式大環境下使用敏捷開發的做法。
PRINCE2的專案管理流程
HNA團隊根據PRINCE2的規範，在專案啟動文件中(Project Initiation Document, PID)，使用產品分解結構(Product
Breakdown Structure, PBS)，描述專案預期產出的成品。 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規定的流程，尋求高層的決策。
HNA專案的執行成果非常成功，獲得昆士蘭當局大力讚揚：「政府認為這個牽涉到設計、開發和實作的專案非常複雜，而且充滿挑戰……。專案產出的流程，以及讓服務功能上線的動作，進行地非常好。」另外，在把Scrum導入昆士蘭州住房與公共工程部的期間，資訊部門的士氣大漲，創下期間留職率(Retention
Rate)百分百的紀錄。到了2009年，住房與公共工程部已經在30個專案上，使用敏捷方法，而當初引進Scrum的Adrian Royce，不但獲頒創新改善卓越獎的殊榮，還被挖角到昆士蘭的環境和資源管理部(Department
of Environment and Resource Management, DERM)，繼續推動敏捷專案管理。
