日前為一家規模龐大的組織進行敏捷式專案管理課程，課前一天傍晚，副執行長熱情晚宴款待，席間提及，某個老舊資訊系統更新專案，執行兩年以來延誤不斷，掌握不了可靠的結案日期，令他相當頭疼，不過在他的話語之間，我倒是感受不到絲毫的怪罪之意！

副執行長雖然熟稔傳統式專案管理手法，但卻謙沖承認自己是敏捷方法門外漢，在我向他簡略介紹完敏捷方法之後，副執行長略顯無奈地提出了這樣的疑惑，「聽說敏捷方法可以把專案做得又快又好（客戶／用戶滿意），可是我們IT團隊已經用敏捷方法做專案好幾年了，這個專案還是延誤成這樣，不僅開發人力資源卡死在那兒，使用單位也抱怨連連，到底問題會是出在哪裡呢？」

我知道副執行長並無惡意，也非在挑戰我或敏捷方法，更非要我當下就給出靈丹妙藥，否則也不用大費周章，喬出相關單位人馬來上我這堂敏捷式專案管理課程了。如果真對敏捷方法失去了信心和信念，倒不如直接下令 IT 團隊改回傳統式專案管理方法，這樣要省事許多。

課程當天中午用餐時，IT 部門既專案管理主管談及該延誤專案，我便順勢探索了一下該專案的來龍去脈，真相終於大白，還了敏捷方法清白。其實，正是巧婦（敏捷方法）難為無米（適切角色與流程）之炊的寫照。

無米一：專案管理專家角色闕如或失能

一般來說，歷史愈悠久的資訊系統（以下簡稱系統），其功能與架構愈是錯綜複雜，背後累積愈多怪異的商業邏輯（Business logic）和臨時性補丁（Workarounds）。經過歲月的洗禮，龐大的系統健在依舊，可是人事卻往往早已全非，過去曾經參與打造或修補這系統的人們，來來去去，早已無法有人能清楚掌握整個系統的來龍去脈。

您也許會問，不是應該有文件，記錄著大大小小的變動歷史嗎？不幸的是，實務上，原本好好的理想系統架構，經常會被一些臨時又緊急的修補動作所破壞，且這些修補又常被遺忘而長期留置在系統當中，相關文件當然也沒被正確更新。

當系統如此演化，肥大到難以維護或技術老舊到跟不上時代之時，就有人會開始想全面重新打造這個系統。人是喜新厭舊的動物，這一點也不奇怪，不過也正因為如此，人類才能不斷地創新進步。

自己投身資訊電子產業二十餘年，我能充分體會了解，軟體開發人員對於新技術的躍躍欲試渴望之情，若有機會能不受限制地發揮創意，打造全新的東西，絕對會感到興奮無比。

不過，貿然全面拋棄舊系統，從頭打造新系統，卻是風險極高的行為，尤其是，當組織仍需仰賴舊系統進行大量業務活動之時。即便各行各業早有許多打掉重練的慘劇示警，可是大家似乎還是很難學乖，仍不斷上演著類似的劇情。

經驗老到的專案管理專家，絕不會同意「全面拋棄舊系統，從頭打造新系統」的決策。可是，在舊系統已不堪負荷，難以使用，業務又不可能為此停擺數個月的兩難之下，到底又該怎麼辦才好呢？

無米二：產品負責人與敏捷大師角色闕如或失能

要在翻新舊系統的同時，維持組織業務的順暢進行，的確不是件容易的事，就好像得邊開車邊換四個輪子趕路一樣。你絕對無法、也不該，在行進中同時更換四個輪子。

為了安全起見，我們頂多只能一次換一個輪子，而且還得先確認，司機有能力只用任何其他三個輪子，就維持住車子的平衡，持續前進。而有資格做這個決策的人，就是坐在這胎紋嚴重耗損的車上（老舊系統），還需趕時間去遠方（業務進行）的車主（產品負責人），他不但是車的 Owner，也是對業務負全責的人，既要安全，也要業務，缺一不可。

此嚴重延誤的老舊資訊系統更新專案，使用單位用戶眾多又強勢，意見廣泛卻常相互牴觸，但卻不見產品負責人（Product Owner）出來仲裁與決策，以致 IT 團隊只能先服務那些大聲又強硬的用戶，可是事後卻又常遭到其他用戶的抱怨和抵制，系統需求因此反覆難定，IT 團隊經常陷入「順了姑意，逆了嫂意」的窘境。

此例中，產品負責人嚴重失能，並非敏捷方法之罪。此外，頻繁出現這樣的狀況，亦不見敏捷大師（Scrum Master）出來協調，為 IT 這個開發團隊（Development Team）的效能把關、排除障礙，任由團隊資源被恣意濫用浪費，敏捷大師也嚴重失能，此亦非敏捷方法之罪。

無米三：關鍵開發團隊專家角色闕如或失能

換輪子的技師和司機就如同敏捷開發團隊成員，司機需要隨時關注車內技師的行動和車外的動態，以機動調整方向盤、油門和煞車，維持車輛平穩和速度；而技師們也需要聽司機的指示，什麼時候該暫停，什麼時候可以繼續。這就是團隊成員間的協同作業，整個團隊是集體行動的、有紀律的、榮辱與共的生命共同體。

然而，在此之前，還有一件更重要的事，那就是，得請原始車輛設計者告訴大家，四個輪胎的更換順序和時機，以及當下的適當安全車速，司機和技師們才能照表安全操完課。

這位原始車輛設計者，就像一個資訊系統的架構分析師（Architect），沒有他/她的妥善設計規劃，團隊很容易就會陷入沒有章法、各自為政的亂象，系統結構也很容易就被輕易破壞。此嚴重延誤專案，正好就缺乏這樣的關鍵開發團隊專家角色，此亦非敏捷方法之罪。

於此同時，敏捷大師事實上還必需隨時密切觀察、監控、協助團隊的協作（例如，防止有技師偷偷同時更換兩個輪子來炫技，影響全員安全抵達目的地），而此嚴重延誤專案的敏捷大師卻身兼開發團隊成員的角色，其花在開發工作的心力遠多過執行敏捷大師職責所花的心力，此為敏捷大師的失能，亦非敏捷方法之罪。

敏捷方法是巧婦，仍需好米與好灶

敏捷方法的確是巧婦，但你也得先給她米和灶才行，不論是白米、糙米，還是紫米，只要不是壞掉發霉的米，巧婦總是能炊出軟硬適中的香Q米飯。

話說回來，其實無論是傳統式還是敏捷式方法，都需要組織各級主管的全力支持，讓涉入流程方法的各種角色都能到位，都能發揮其應有的職能，否則，不論導入什麼方法，可能都難以讓專案做得又快又好，您說是嗎？

本文轉貼自：威廉網紙（原文連結）