Agile 方式項目管理名不符實？

面對新一代的技術發展，各行各業都在經歷不同程度的轉型變化。不少公司在進行數字化轉型的過程中，均會嘗試引入各種更為敏捷的方法，代替傳統 waterfall 的項目管理，希望讓項目執行變得更快捷。但在不少的實踐上，也預到不少難題。

例如在早些年不少公司嘗試引入Agile，就有不少意見認為，Agile 的理論只適合完成能自成一角，沒有與周邊系統有太多關連的系統開發項目，當中較多人認為可行的包括前端應用，或是最後端的報表，但一談到中層的product system，尤其是以前在mainframe 上建的那些legacy，就很少人認同可透過agile 方式推動項目。

Agile 在前端系統或末端報表較容易成功，在中層legacy system 則很難推動，有人把這歸咎於系統技術的分別，尤其是legacy system 很多時由較為年長的一輩維護，未必容易接受新思維。有人則認為是中層系統對接大量周邊系統，難以推動Agile。個人對前者說法甚有保留，並認為真正的原因肯定不在於技術人員或歸類為前端後端。是否能推動Agile，更多的是在於團隊是否具有產品思維，以及團隊有多大程度做到self-sufficient。

對於近年不少公司加大投入資源開發網上電子平台，項目就是從零到一把電子平台這個「產品」建立起來。在這個初始階段，項目管理和產品管理表面上看似沒有很大不同，都是希望用最短的時間，把產品最必要的功能在第一階段做出來，只不過用waterfall 的人會開宗明義把這個叫Project Phase 1，而有些公司聲稱自己在用agile 的，就稱這個是MVP。

很多初次試驗Agile的團隊容易在這裏踏入誤區，以為只要把一個項目分開成幾個phase，第一個叫MVP，試着做些stand-up meeting，或兩個星期做一次review進度，定義下兩個星期工作範圍，就等於是在用Agile。有些機構甚至以為這樣就已具備Agile 的能力，準備廣泛推廣，結果大多都以失敗告終。箇中的原因，正是這種所謂行Agile 的模式，只不過是waterfall 的一次重新包裝，把一個大瀑布變成了很多個小瀑布。這樣不但毋助解決waterfall 的問題，反而讓問題變得更糾結複雜。

要知道，Agile 的核心理念，肯定不是那些儀式上的事，或限制團隊會議多少人參加，最重要是adaptive，不要求一次性投產所有features，也不着重第一次做出來就完全正確，反而是透過小規模形式的持續投產，對產品進行持續優化。而這裏的投產是必要的，如果只是把元件開發了出來，或放在UAT等待測試，實際上是難以有效獲取生產環境的真實數據。

透過持續投產及建立持續反饋改錯的機制，團隊可以在產品發展過程中不斷優化改進，這種模式的運作，背後正正需要較為長遠的產品管理思維，一方面整體規劃產品的長遠發展路徑，另一方面在實際操作上不斷改進適應市場需求。更重要是，應用產品思維，定位產品目標和量度成效的標準，並按客戶價值訂立項目開發項的優先序，把資源聚焦在產品最有價值的發展上。

對於用Agile 思維做開發的團隊，如果能夠明白Adaptive 的意思，就能了解定義MVP 範圍其實是一個偽命題。真正要關注的，應該是thin slicing 做的有多充份，是否已真正界定出最逼切做的feature，團隊是否保持專注於最有價值的事項上。MVP 並不一定要在一開始就落實確定，更重要是在過程中，團隊透過不斷學習，定義出達致什麼標準才將產品第一版推出市場。

（註：讓筆者記起的是，數年前見過有團隊在行Agile 的時候弄了個MMVP 出來（即mini-MVP），也可謂相當創新。團隊一方面為了盡快上線，訂立了MVP的範圍，但在過程中亦發現，部份原先定義為MVP的features，也不是必須的，故此MMVP 才是後來判斷為真正必須的範圍。）

本着背靠產品思維的Agile 運作，即使是在出名監管嚴厲的金融業，在風險可控的情況下，例如是過程中加入適當程度的過程檢測，以上描述的方式亦都適用。產品團隊站於一致的目光思路，就能具體分辨出產品哪些元素屬於重要，哪些屬於相對不重要，哪些是真正投產必要，並且按統一價值定位進行有效排序，優先實現最有價值的backlog 並進行持續優化。

不過話雖如此，Agile 即使在真正具產品思維的團隊上實際操作，也還是預到不少困難，尤其是在現今世界，大多傳統企業都以功能對齊 (functional align)，部門各自管理，並且各自有自己的專業所長。在這種按功能對齊的企業，團隊除核心成員外還有大量利益相關者，各自站於自身功能立場上出發，這樣的設定下要去對齊產品目標願景，行動力一定大打折扣。

就以金融業為例，行內就經常有說法指金融業難以推行Agile。箇中原因，是對不少產品團隊而言，監管合規要求就是屬於合規部門的工作，也是一個並非自己本業的專業知識（當然筆者並不認為是這樣）。這種傳統上的思維模式，導致產品團隊對監管合規要求缺少基礎知識，亦未能在項目初段已能基本評估產品必要配合的合規安全要求，並定義出優先序。結果很多時是要等到項目大致完成UAT後，才通過內部或外部第三方審計獲知相關要求，導致大失預算，或最終要走回waterfall 的老路，即透過項目形式集齊項目的利益相關者，然後在既定時間內完成項目，並且一整批投產。

只是，多年的實驗基本上已可證明，在waterfall的世界，強調的是一次性做好，認為犯錯會造成re-work 浪費，但卻花費長時間進行計劃，最終在大量假設不符的時候，跌入不斷重覆的re-plan 上，最終不斷出現無限delay，產品即使最後成功投產，也沒有實現預期的value。

故此，筆者認為Agile在新世代仍是一個必要的轉型思路，關鍵是在於團隊的產品思維，持續交付價值，及在過程中不斷試錯改錯。對產品團隊而言，self-sufficient 也絕對是一個重要的指標，這還很視乎管理層是否相信這種模式，企業整體是否能下大決心重組轉型。

當然，要想一步到位轉型成為Agile，對很多企業而言都是難以踏出第一步的，或者只會是個別項目團隊在形式上進行一些小規模的轉變，難以廣泛推廣。對於一些正在踏出轉型的企業，傳統waterfall 式的項目管理辦法，還是有其重要地位，至少可在機構內未完全轉型的過程中發揮作用。而且，即使是對於產品團隊而言，真正落地做的時候還是需要以項目形式推出各個已排序的features的，分別只是把項目變得更少更容易管理，可預測性更高而已，所以傳統項目經理也確實不應擔心傳統waterfall 會因此沒有出路。

而對很多企業而言，進行Agile 轉型本身也是一件很Adaptive 的事情，甚至乎我們是應該可以把產品思維的轉型看成它本身就是一種產品，不是一步到位，而是需要按企業內部用戶實際情況而調整策略，選擇最大價值的優先推廣，這也是很多企業除了選擇某些項目行Agile，還會建立所謂Agile CoE 的原因。