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.