敏捷開發的重點不在「快速」！一個真實案例，給我們的管理啟示

SCRUM 是近年來相當熱門的產品敏捷開發方式，不同於過往瀑布式開發法，要求將所有能想到的產品規格與使用細節定義清楚以後才能進入開發流程，最終推出一個完整性高功能豐富的產品。

SCRUM 則較重視靈活與彈性，推出 MVP（最小可行產品）以後，視市場與用戶需求靈活調整產品走向，一句話來說就是「先求有，再根據反饋求好」。

而在當你加入公司沒幾個月，也還在熟悉網路科技業更迭快速的產品開發流程時，老闆突然決定為一個新的產品專案建立 SCRUM 團隊，並要求你擔任團隊的負責人，會發生什麼事而又該如何面對呢？

開始負責該產品專案短短半年以後，現在回想起來，實在是讓我在作為產品經理這條路上的經驗值飆升許多，也很值得記錄下來並分享我的親身經歷。

一顆名為 SCRUM 專案的隕石

我現在的公司主要產品為開店平台，管理平台內有包含一個數據分析功能，於頁面上呈現不同的商店營運數據，不過這個數據分析頁面似乎一直達不到內部與客戶的期望與要求。

就我的觀察是過去的團隊內並沒有真正對電商數據分析有所精通的成員，或是分身乏術，無法有多餘的時間針對這塊有更透徹的研究。

也因此，在加入現在公司的幾個月後，老闆決定要開發一套新的電商數據分析產品，並希望我作為 SCRUM Master（SCRUM 大師），新進的數據分析師作為 Product Owner（產品負責人），一位較資深的架構師作為 Technical Consultant（技術顧問），再加上當時只有3人的開發團隊，合作成立獨立的 SCRUM 團隊。

有了新進的數據分析師以後，我們便將過去較困難的營運數據指標的定義與規劃交由他來負責。不過也因為分析師過去其實較沒有產品開發的經驗，我需要協助他處理並了解許多 Product Owner 負責的事，像是如何定義用戶故事、寫 spec … 等等。

而我在接到這項任務時面臨到最大的挑戰便是，我們的團隊成員中除了技術顧問以外，全都是剛加入公司不到半年的菜鳥，而且過去負責數據分析系統結構的工程師再過一個禮拜就要離職了！

因此我只能在他離職前的短短幾天內去了解我們數據分析的技術架構，並與 Dev Team 討論出如果要做到 PO 定義出的新指標所需要做的架構調整，以及新的獨立產品前期所需要建置的環境。

嘗試錯誤與突破

在實際運行 SCRUM 以後，我在前期遇到的最大問題便是估時與實際執行時的落差過大，導致預計時程持續延後。產品遲遲推不出去讓團隊成員逐漸疲乏喪失動力，有段時間團隊士氣不是很好。

當時我在面對這樣的狀況，採取了以下幾種方式來試圖解決時程延誤的狀況：

1. 檢討流程

在剛開始運行 SCRUM 時，我們的開發流程是以公司核心產品訂定的開發流程來執行。

不過我在重新檢視工作流程以後，發現以我們的產品來說可能不適用原先訂定好的開發流程，與其死守，倒不如大膽嘗試。

因此我便與團隊成員提出修改流程的方案，並解釋這個修改方案為了解決的問題，與我預期可達到的效果，並與技術顧問討論加入技術工具協助開發。

2. 任務拆細

我們初期在開發上遇到的一個很大的問題便是卡在測試環節，工程師的開發一直過不了 QA 那關。

由於我們的產品為數據分析工具，即便用戶最終看到的是很簡單明瞭的圖表，但背後的數據所需要處理與運算的情況卻是非常複雜的。

即便我們的目標可能只是要完成某個看似很單純的營運指標，但實際開發後，發現這個營運指標的範疇超乎想像，可能一個例外狀況，像是微小的訂單狀態修改，就能導致我們的指標偏誤。

因此我便與 Product Owner 和開發團隊溝通，每次在規劃目標與任務時，盡力將工程師與 QA 的任務拆到最細，讓開發與測試所需要涵蓋的處理範圍降至最低。

3. 向上溝通

時程一再的延誤也讓各團隊成員在面對外界時備感壓力，除了與更資深的 PM 主管請教以外，我也定期主動與老闆約會議。

在與老闆的會議中，除了最基本的進度更新，讓老闆看看我們近期達成的成果，我也會主動告知老闆我們遇到了什麼困難，我預計採取什麼樣的行動解決困難，預期可以得到什麼樣的效果。

老闆在會議中會針對專案狀況提出建議，同時也會對於產品未來走向給予想法。

在進行了以上3種方式以後開發越來越穩定，我們也漸漸將修改過後的流程訂定為標準規則，而隨著團隊的任務達成率的提高，士氣也越來越高昂。

而我認為我們 SCRUM 團隊如今能夠很順利地獨立運行的其中一大原因，便是老闆的支持與態度。

透過前述的定期會議中，我希望能讓老闆了解到團隊遇到的困難，與我們預計如何做出調整，甚至讓他了解到前一次調整過後我們的成效如何。

而我的老闆心臟也夠大顆也很支持我們團隊，一直抱持著耐心，也給予我們相當大的自由與發揮空間，讓團隊能有充分的時間從經驗中學習，也才會有後續的進步與突破。

「敏捷」就是「快速」嗎？正確的觀念決定 SCRUM 成敗

敏捷式開發看重的是迅速「適應」，「快速」是在導入敏捷後可能帶來的附加價值。

SCRUM 團隊作為一個獨立營運、自我管理的團隊，相較起訂下重重規章，更講求的是團隊面對挑戰時能不能迅速作出反應，能不能自動自發從成功與失敗經驗中學習，並從中做出調整。

也因此每個 SCRUM 團隊的運作模式與風格可能都不盡相同，速度與步調也沒有絕對標準。

如果企業有意導入如 SCRUM 的敏捷式開發，公司的領導人對於敏捷式開發不能夠有錯誤期待，相對的，團隊也有責任要讓老闆清楚進度與狀況。只要能正確地了解敏捷的概念，SCRUM 能達到的境界絕對是超乎想像。

責任編輯：黃楸晴
核稿編輯：陳慶徽