 |
| Source: Stuart Henson & Jon PriorUK, MOD Combat Identification Server Technology Demonstrator Programme, |
戰爭期間的傷亡，不見得都是敵人攻擊造成的。[1] 2009年1月14日，英國在阿富汗參與的反恐戰爭，發生自家人誤殺自家人的事件。英國皇家砲兵上尉Tom Sawyer和海軍陸戰隊下士Danny Winter，在掃蕩塔利班(Taliban)據點的任務中，因為視線不佳難分敵我，遭到聯軍的迫擊砲誤擊斃命。在此之前，英國皇家海軍陸戰隊中校Jonathan Wigley，在2006年12月間，也是在美國海軍軍機突襲任務中遭誤擊身亡。[2] 在軍事科技發達的今天，這種友軍砲火（friendly fire）意外發生的原因，不是武器打不準，而是武器發射之前，自家部隊之間，無法及時判斷情勢(situational awareness)，辨別戰場上哪些是自己人，哪些才是敵人。為了降低友軍砲火造成的傷害，英國國防部(Ministry of Defense, MoD)決定開發一套戰鬥識別系統(Combat Identification System, CIDS)，避免悲劇繼續發生。
CIDS專案在2009年1月發包，軍火大廠通用動力公司(General Dynamics, GD)英國分公司得標，GD找來美商洛克威爾柯林斯(Rockwell Collins)和英商QinetiQ，組成專案團隊，負責開發這套用來整合空中資源，自動即時追蹤部隊動態，避免砲火誤擊聯軍部隊的資訊系統。
CIDS專案的成果，在2010年7月就要上線，在短短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系統要在2010年6月實機展示，並在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
Haves、Should Haves、Could Haves和Won’t Haves這4類的需求，合稱為MoSCoW，其中：
PRL清單的4種需求優先順序
優先順序
|
意義
|
Must Haves
|
CIDS的核心特色，也就是根據契約規定，一定要完成的功能
|
Should Haves
|
沒做出來使用者會不舒服，但暫時有替代方案的功能
|
Could Haves
|
「加分」的功能，但沒有立即的需要
|
Won’t Haves
|
暫時不考慮開發的功能
|
不論是哪一類優先順序的需求，每一個需求上都有代表需求難易度的點數，稱為「故事點」(story point)，如果把最近一個開發周期中，所有完工需求上的故事點總加起來，得到的數字稱為「速度」(velocity)，代表的是開發團隊的最新產能，可以用來預估完成剩餘需求所需的工期。根據DSDM Framework的建議，每個開發周期中，Must Haves需求的點數最好不要超過當期總合的6成，要預留4成的Should Haves和Could 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 Haves或Could 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)，全球防衛誌249期，2005年5月。
[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] 1994年1月，來自英國航空(British Airways)、美國運通(American Express)和甲骨文(Oracle)等大廠的16位資訊業專家，在英國倫敦共同創立了DSDM Consortium，期望發展出一套快速應用程式開發框架(Rapid Application Development
)，DSDM後來幾經演進，內容越來越完整，2001年公布的軟體敏捷開發宣言(Manifesto for Agile Software
Development)中，來自DSDM Consortium的Arie 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.
