2015年1月11日 星期日

我看見大象在跳舞,政府也敏捷了!

徐柏峰







        如果你認為政府機關就像大象一樣,推不動求快求變的敏捷方法,哪你就錯了!美國和英國政府,在經歷許多失敗教訓之後,決定在資訊科技(Information Technology, IT)類專案,向業界學習最佳實務,用敏捷方法推行政府專案。

政府是大咖的發包業主

        政府的IT專案中,發包委外(Acquisition)是很常見的作法。根據美國白宮「行政管理和預算局」(Office of Management and Budget, OBM)的統計,美國政府光在2011年間,就花了76億美元IT相關專案上。這些政府外包專案,向來是套用瀑布式開發方式,預算龐大,執行工期也常,不過失敗的案例卻是時有所聞。

美國政府資訊專案,經常不能善終


        以美國政府專案來說,「紐約市政府自動化薪資系統」(The New York City Automated Payroll System, NYCAP ),在1999年啟動時預計投入66百萬美元,後來一直拖到2011年才結案,光是追加的預算,就超過36千萬美元,相當於原先規畫的5.5倍;紐約市政府另一項名為CityTime的薪資系統,原本打算投入563百萬美元,但實際上耗費了1077千萬美元才收場;[1] 美國國稅局(Internal Revenue Service, IRS)19942005年間,投入185百萬美元開發電子舞弊偵測系統,後來IRS因故決定棄用系統,反而在1年內造成高達8億美元的損失。[2]

英國政府資訊專案,失敗案例時有所聞

        再以英國政府為例,19921026日,「倫敦救援服務電腦輔助派遣系統」(The London Ambulance Service Computed Aided Dispatch System, LASCAD)上線,原本預計針對每天平均2000~2500通的報案電話,提供自動派遣救護車的服務,不料,因為系統功能發生異常,某些民眾甚至在報案11個小時後才等到救護車,間接造成30人死亡,當時LAS的首長John Wilby因此引咎辭職,LASCAD系統因此遭到棄用。[3] 另外,英國政府原定投入187億美元,打造「全國衛生服務系統」 (National Health Service, NHS),建立中央化的醫療資料庫,NHS系統開發到第9年,也因為成效不彰,在2011年宣布終止,已經投入的44億美元付諸流水。[4]

美國政府機關的敏捷案例越來越多,國會立法要求國防部也要跟進

大型政府專案失敗案例層出不窮,美國和英國政府不約而同地向業界學習,決定採用敏捷方法。在美國政府方面,白宮行政管理和預算局(Office of Management and Budget, OBM),建議美國政府機關在推動資訊專案計畫時,應該使用敏捷方法,把資訊系統分割成模組化的小單位,循序漸進地交付。過去幾年以來,包括美國國家航空暨太空總署(National Aeronautics and Space Administration, NASA)、商務部(Department of Commerce)、退伍軍人事務部(Department of Veterans Affairs, VA)和國稅局(Internal Revenue Service, IRS)在內,都陸續傳出使用敏捷方法執行資訊專案計畫的案例。[5] 最具戲劇性的是,美國國會在《2010年國防授權法案》(The National Defense Authorization for Fisical Year 2010),立法要求一向擁護瀑布式開發的美國國防部(Department of Defense, DoD),未來辦理資訊委外( Acquisition of Information Technology)時,必須遵守4大原則,細看這4大原則,可以看到敏捷軟體開發宣言的影子:

  • Early and continual involvement of the user
  • Multiple, rapidly executed increments or releases of capability
  • Early, successive prototyping to support an evolutionary approach
  • A modular, open-systems approach



英國政府要求機關

        在英國方面,英國政府從20113月開始,要求機關要用敏捷方法辦理資通訊(Information and Communications Technology, ICT)專案,英國政府認為,軟體開發專案中,技術發展很快,需求輕重緩急變更非常頻繁,以往在初期鎖定需求的做法,把變更當例外的做法,有先天的重大缺陷。英國國家審計局(National Audit Office, NAO)建議,在資通訊類採購案,應該採用敏捷方法降低專案失敗的風險。英國內閣辦公室(Cabinet Office)早就2011年間設定目標,要求政府機關在在20134月以前,把一半的ICT專案改成使用敏捷方法,並且希望在2014年以前,能把ICT計畫的平均交付時間縮短20%[6]




[2] Robert D. Schneider, Tony Higgins and Keith Barrett, Requirements Definition & Management for Dummies(Mississauga: John Wiley & Sons Canada, Ltd, 2013), p.p. 24-25.
[3] 有關LASCAD系統失敗的分析,請參考ErichMusick網站,網址為http://erichmusick.com/writings/technology/1992-london-ambulance-cad-failure.html
[4] 有關NHS系統失敗案例的報導,請參考Neil Versel, U.K. Scrapping National Health IT Network. See http://www.informationweek.com/regulations/uk-scrapping-national-health-it-network/d/d-id/1099364?
[5] GAO, Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, July 2013, pp. 29-30.
[6] NAO, Governance for Agile Delivery, P 7.