瀑布式開發法特別適用於需求明確的情境。在 ETC 系統建置階段，大部分的需求都在合約中有定義，屬於電子收費系統的必要功能。當遠通走入 ETC 系統迭代優化階段，甚至運用「營運骨架」思維不斷進軍新的業務領域，要為系統優化或打造的功能，往往沒有合約做為規格依據，也缺乏明確的市場需求定義。怎麼辦？

這個問題，其實是所有系統軟體開發者的困擾。近年來，軟體界提出答案：

「即然沒人明說，就發問。問誰？問市場。怎麼問？實際測試。測試完，就立刻修改。逐步逼近市場需求。」

遠通從 2017 年引進此一見解。當看到市場上的潛在需求，就一邊開發系統，一邊調整優化，打造最小可行方案。在推出服務後，再依據客戶需求快速調整。這樣的做法，就是近年非常受到推崇的：敏捷式開發（Agile） 。

「若沿用瀑布式的開發方式，開發時間至少是敏捷式的兩倍。」 向德成協理指出：「瀑布式開發會花費很多時間規劃與研發，將系統做得很完整才驗收。但是當驗收成果不如預期，又必須花費大量時間重新修改調整，效率太低。」

「如果遠通在發現客戶新需求後，需要花一年時間開發，才能推出服務，這樣太久了。 現在不是大勝小、強勝弱的時代，而是快勝慢，一切講求速度。 」張永昌總經理認為敏捷式開發更能因應當代的商業環境。因應導入敏捷式開發，遠通內部打造一系列新的組織與管理模式。

跨領域敏捷團隊：持續改善、持續交付

一般企業內部，都以部門為運作單位：A 部門員工完成工作，交由 A部 門主管核可後，轉移到 B 部門接續進行；B 部門員工完成後，由 B 部門主管核可，轉移到 C 部門......。這種部門式工作方式，有四項缺點：

• 各部門只需要負責分內工作，別的部門做得好不好，專案是否完成，都不需要在意。
• 若最後發現專案出錯，部門之間容易相互推諉責任。
• 部門主管負責管理、指導員工，卻不見得深入了解專案，也不對專案負全責。
• 工作流程中，各部門主管指導效益不高，其檢核環節反而拖慢工作效率。

在訴求「敏捷式開發」的工作模式下，不能再依賴部門為運作單位。為了改善效率，遠通建立敏捷開發小組（Scrum Team），以開發維運的方式快速迭代，密集協作、快速優化產品，以滿足敏捷式開發的需求。

敏捷開發小組實際上如何協作？

具體而言，敏捷開發小組會怎麼做？以遠通實際團隊作業為例，共有五個步驟：

1. 確認需求

首先，從貼合市場需求的角度提出需要打造的新功能，例如智慧停車、點數兌換、uTagGO 易付、多元支付等。當確認一個功能需要打造，就進入下一步驟。

2. 組成敏捷開發小組

以多元支付功能為例，遠通會建立一個新的敏捷開發小組，團隊中包含不同專業背景的人才，包含多元支付所需要的帳務、支付、資訊、應用程式等專業。

若有相關專業的員工，對這項多元支付專案有興趣，可以主動報名加入小組，或由專案負責人指派。在敏捷小組內部沒有部門之別，大家都是帶著各自專業加入。

3. 短期待辦清單

在專案開始前，專案負責人會和小組成員開會，一同討論客戶旅程，集思廣益思考客戶需求，例如應用程式嵌入、非會員支付等功能。最後，負責人會訂出使用者需求與短期工作待辦清單，準備執行。

4. 開發衝刺（Sprint）

團隊訂下待辦事項後，就會開始二到四週的每日開發衝刺。

每天早上，團隊會有站立會議，快速討論昨天、今天、明天的工作事項，例如串接金流系統、應用程式開發的進度等。團隊成員遇到瓶頸阻礙，也可在會議中一起討論克服方法，並找尋協助資源。

團隊透過看板軟體管控工作進度，以在短時間內得到最小可執行的成果為目標。

5. 釋出測試，快速迭代修正

最小可執行的成果不必是最終的完美版本；放上系統後，團隊會觀察客戶的使用情況，例如出現操作錯誤，或是與其他系統功能衝突……。得到這些反饋資料，團隊就針對問題快速修正產品，再將新版本放上系統測試。如此往復循環，直到成果符合使用者需求，且能穩定運行。

（本文出自《修煉》，商周出版）