怎麼跑敏捷式開發Scrum？91APP的軟體開發與組織管理歷程

91APP 運作 200 人以上的 SaaS 產品開發團隊，透過導入 Agile 的開發方法，用 Scrum 的方式有節奏推進交付，並大規模的不停地做組織重整，用 91APP Way 的三個層次來運作產品開發組織。

91APP 現在有一個 200 多人多大產品單位，包含 PO、RD、UX/UI、QA 等等都在這個單位，也是整個公司佔了一半以上人數的單位，負責 91APP 的 SaaS 產品的開發工作。

聽說我們跑的是 Agile（敏捷式開發），在台灣，很少聽到有一家軟體產品公司，如此大規模的運作 Agile。很多人問我們，這麼大規模的組織運作 Agile，要怎麼跑？

這篇文章主要就是嘗試說明這個問題，但其實真實的關鍵已經不是 Agile，是軟體開發組織運作方法。經過多年的演變，Agile 也已經不是原來以為的 Agile了，如果硬要說我們現在的開發方法的話，我會說是 91APP Way（91APP 的軟體開發之道）。

這個故事大概是截至目前為止，最長的一篇文章，足足有將近 6,000 字。但本來組織發展，就是一個公司能否長期成長的關鍵，千言萬語也無法道盡其中奧妙，所以就用一篇故事的形式，簡化了一些過程，提煉其中的關鍵轉折，串連起來變成起承轉合，或者你也可以把它當作一篇寓言故事，希望能給大家一些啟示。

第零階段：最美好的時光

跟大多數創業公司一樣，我們一開始也只不到 20 個人，而這個階段，是旅程中最美好的時光。

記得當時ㄧ開始的這群人，除了同事，更像是朋友，中午會一起吃飯，下班還會約唱歌，假日還會約出遊。然後邊玩邊討論工作，邊工作邊玩。

剛開始的這個階段，大家其實會非常有默契。工作目標決定之後，會一起想辦法達成，有麻煩就互相幫忙，有挑戰一起打怪，有經驗一起練功，有問題就快速溝通，有想法就快速討論。

或者更可以說像是革命夥伴。革命是很讓人亢奮的。創業初期雖然辛苦，但創業就是一起追求一個夢想，一起做夢，看起來未來無限可能，所以會莫名的型成一種很 High 的氛圍，感覺我們什麼都做得到。

通常這個階段，也沒什麼明確的組織，也沒有明確的分工，反正就是一起想辦法，貢獻自己可以做的事，看做什麼可以讓公司往夢想彼岸推進一步。

其實這個階段通常也不喜歡什麼組織分工、設立流程制度，都很點綴，想辦法讓公司可以活下去、找到成長的動能才是最重要的。

第零階段的創業團隊，是最美好的階段，如果你還在這個階段，請好好珍惜。

第一階段：瀑布來了

可是當團隊成長到 50 人以上，管理的問題就開始來了。

通常一定是公司做對了什麼，產品有了第一批的客戶，營收有了進展，團隊也才因此開始成長。這時候會開始有新成員加入，有了「新人」，原來的舊人就變「資深」了，資深就厲害了，就會開始對新加入的菜鳥有很多的指點。於是，某一種奇妙的「階層感」就開始發生了。

順理成章，「資深」就變成了「主管」，而有主管就會有部門、有部門就開始分工，有分工就開始要溝通，有溝通就開始分你我。

就我們來說，就開始分成有產品部門、設計部門、工程部門、測試部門等等。然後每一個產品專案，都會需要跨部門討論，落下各單位的工作項目，PM 就會畫出「甘特圖」，來追蹤整個專案的進度。

產品規劃完交給設計部門、設計畫完交給工程部門，一棒接一棒，很自然的就變成了知名的「瀑布式開發」的跑法，一個功能專案從開始規劃，到開發、測試後上線，通常至少要跑到 3 個月以上，然後也常常還超出預期。

第二階段：上帝之手

不過隨著團隊規模再跨大，也不可能是一個團隊，一起跑一個專案，一個瀑布跑到底，老闆是不會接受的。最好是整個產品團隊，能同時跑幾個專案，越多越好。

意思就是說，如果我們有 70 個人，而同一個時間，通常就會有 6~8 個專案一起跑，所以就得依據專案需求，想辦法分配人手，把人分別丟進不同的專案裡面。所以依據不同的專案的特性，指派一個 PM、UX、再指派幾個 RD、QA，組成一個臨時的專案團隊，然後專案結束就解散，大家各自又被「分配」到其他專案去努力了

而分配大家工作的管理階層，就像是決定大家命運的「上帝之手」。

這種跑法，非常講求「上帝之手」的資源調撥的功力。調撥資源的人要知道每個人的長項、每一個人當下的 loading 等等的，然後把對的人塞進專案裡面。一沒弄對，有的人就會過載，專案超多，命運坎坷，而有的人就像生在好人家， 涼的很，平常也沒什麼事。

「上帝之手」安排每個人的故事與角色，設法讓整個世界可以正常的運作。通常這種跑法一開始問題也不大，而調資源的主管層越強，這個跑法可以運作的很好，至少好一陣子。

然後問題就來了。

通常這種跑法所形成的「專案團隊」，「團隊」感是很弱的，甚至也根本不是一個團隊。因為終歸是一個瀑布型的跑法，每一個專案的時程都拉得很長。所以像是專案團隊內的 PM，通常專案啟動後，工程師還要寫一段時間，所以他已經被安排跑去寫另一個專案的規格了。

大家彼此都是生命中的過客，因為專案而短暫交集，專案結束就分開了，很難有什麼「團隊默契」。

第三階段：形成專業領域團隊

而且，隨著公司的發展，產品的複雜度也在變高，於是不同產品線功能之間的 「專業領域知識」，也開始越來越深。因此接下一個專案的人，從理解專案的「專業領域知識」 到真正可以上工的時間，也越來越長。

例如本來做金流的人，好不容易把金流搞懂，下一個專案被安排去做會員機制。所以常常一個專案成員，好不容易把一個產品線的專業領域弄熟了，團隊默契也熱起來了。但專案一結束，團隊就解散，各自去接下一個案子，而且可能還是自己完全陌生的案子。好像是你好不容易找到打棒球的感覺，就突然調你去打打籃球了。

隨著團隊成長到 100 人，這種跑法幾乎快要跑不去。大家工作都很不開心。

於是我們開始思考，是不是應該把團隊成員固定下來，讓做金流的這 20 個人，長期形成一個固定的「專業團隊」（而不是「專案」團隊」），就一直做金流相關的題目。做會員的那 20 個人也一樣。

也就是依據專業領域，畫分出一個一個的「專業領域團隊」，然後整個團隊固定成員，就一起在這個專業領域，長期發展。

也就是會打棒球的就一直打棒球，會打籃球的就打籃球。固定團隊成員在固定的專案領域裡面長期耕耘，理論上會越做越熟練，團隊默契越好，工作效率就會越好，生產力應該會更提升。

但，我們的軟體工程方法，一直以來還是瀑布式開發。不管怎麼切分人員成團隊，每個團隊裡面，還是瀑布式開發。整體專案從 PM 把規格寫完，到實際 RD 開發完成上線，產出工期還是很長，而且常常 PM 一直在寫案子，但工程師怎麼樣都來不及寫完。

於是，我們開始尋找有沒有更好的軟體工程方法，就在這個時候，我們開始嘗試開始導入「敏捷式開發」（Agile）。

第四階段：敏捷式開發

我們選擇採用的是 Agile 的思維下的 Scrum 的方法。

我們依照Scrum Guideline，讓每一個「專業領域團隊」，都設定成為一個 Agile Team，也剛好原來的「專業領域團隊」，就是跨功能組織的成員所組成，長期一起合作的固定團隊，內有各種角色：PO、UX、RD、QA 的等等，可以 End to End 的生產並交付產品功能。

我們再依據 Scrum Guideline，嘗試設定 3 週為一個「Sprint」，每一個 Sprint，跑 Agile 的四大會議，從每日的站立會議(Daily Stand)，到 Planning meeting、Review meeting、Retrospective meeting。透過每一個 Sprint 一個 release，不停循環 sprint，來推進產品功能交付。

我們再依據 Scrum Guideline，嘗試導入新的 Scrum Master 的角色，但因為一開始摸索 Scrum Master 在團隊內要怎麼做，實在花了很多的時間（吵了很多的架）。於是我們也從業界，找進了敏捷教練，跟專業的 Scrum Master。

但，Scrum Guideline 真的寫得很精巧，也就是說，他並不是像一本使用手冊一樣可以一步一步照著做，沒有什麼必然的作法與流程。所以常常是一個 Guideline，各自解讀。

導入 Scrum 之後，我們一天到晚遇到團隊成員之間在爭執，PO 應該要做什麼、Scurm Master 要做什麼，Planning Meeting 要怎麼開才對、Product Backlog 要怎麼列、甚至一個 Sprint 是三週、兩週、還是要改一週？

我們花了非常非常多的時間，在解讀 guideline，在辯論「什麼才是正統的 Scrum」，甚至還互相批評「你這樣的作法不是 Agile」，「你這個會議不是 Scrum 的開法」。

結果，好一段時間，我們太過於計較跑步的姿勢，而忘記了跑步的速度，甚至就算跑步姿勢一百了，一抬頭才發現跑錯了方向。

我們開始思考，為什麼當初要導入敏捷式開發？

第五階段：團隊的自主管理

我們後來發現，身為主管層的我們，還是用傳統管理的腦袋，來嘗試「管理」Agile 團隊的 Scrum 跑法。即使團隊已經導入的敏捷開發方法，但主管層仍然不是很敏捷。事事都想干涉，一直嘗試想安排每一件事（上帝之手一直收不回來），而忽視了「團隊自主」是敏捷裡面很重要的精神。

於是我們開始嘗試，讓「團隊自主管理」，團隊可以依據自己的狀態，可以摸索出自己 Scurm 的跑法，無論 3 周一個 sprint、2 周一個 sprint，或者站立會議的開法、Planning Meeting 的開法。每個團隊可以跑出了自己的樣子。而不是讓管理層事事要求所有團隊，有一套「標準」的 Scrum 跑法。

我們開始不去計較團隊跑步的姿勢，不管姿勢如何，有跑步的速度就是好團隊。

我們也讓團隊有自主的權利，團隊可以安排自己的年度計畫（在公司的年度目標的前提下），可以安排每個 Sprint 的工作內容，團隊成員也會在 Planning meeting，一起討論每個 sprint 的工作項目，設法一起努力、互相幫忙，讓團隊可以一起達成團隊目標。

團隊有自己自主的權利，相對就有責任。團隊要為自己的決定負責，團隊有團隊的責任感，對自己的責任範圍的產品的成敗負責。

這樣子權責相符的跑法，讓其中幾個團隊，慢慢跑出了很高的生產力，也跑出了速度。就像是回到了當時創業的「第零階段」一樣，團隊成員互相 Cover，一起工作、一起為團隊而努力。團隊成員對團隊的認同感強，向心力也強，團隊內會形成很亢奮的工作氛圍。而如果我們有好幾個這樣子的團隊，那就真的太美妙了。

然後，就出現了新的問題。事情終歸沒那麼簡單。

第六階段：團隊的團隊 - One Team

讓團隊自主管理之後，逐漸形成了超強向心力的專業領域團隊，對團隊而言，向心力很好，但對團隊「之間」而言，就形成了很強的「silo」-穀倉效應，也就是「團隊 v.s. 團隊」之間就出現問題了。

因為團隊還是在同一個產品平台上工作，於是團隊之間就需要「協作」；團隊開發的功能之間也有很強的相依性，所以團隊之間就需要「溝通」；因為我們也以團隊的表現做為績效的參考，於是團隊之間也隱含了「競爭」。團隊自主的結果，也讓某些團隊開始跑錯了方向，各團隊各唱各的調，往不同的方向加速奔跑，結果整個大產品，差一點就被五馬分屍了。

於是我們嘗試在團隊之上 ，成立「團隊的團隊」，我們自己把他叫做「One Team」（缺什麼補什麼的概念）。

所謂「團隊的團隊」，意思就是所有 One Team 的成員，都是原各團隊裡面的主管階層，做為代表，聚集在一起，在所有團隊之上，形成一個團隊的上層團隊。因為當團隊跑出了了跑步的速度，團隊的團隊就負責拉好跑步的方向。

One Team 形成之後，我們做了幾個重要的調整：

1. 對齊每一個團隊的 sprint 週期。所有的團隊一律改成兩個禮拜一個 Sprint，並且統一 Release 的時間。

2. 拉齊所有團隊的方向。所有團隊的 product backlog 都會集中到 One Team，One Team 會有一份大產品的 One Product backlog，做團隊開發相依性的「協調」與「溝通」，做完 backlog 優先順序的調整，再讓 One Team 的成員回到自己的原團隊去做討論。

對齊 Sprint 週期，為了所有的團隊的「節奏」一致；拉齊團隊方向，為了所有團隊是演奏的「樂譜」是同一首歌。整個大產品團隊就像一個交響樂團一樣，雖然各團隊因為自己負責的不同，樂譜有所不同，但大家終歸是演出同一首歌，「節奏」一定要一致，「樂譜」合起來要是同一首曲。

而身為主管層的我們，也終於體會到了 Agile 的奧妙。透過 Agile 的落實，團隊會形成自主管理的完整有機體，會自己管理，自我負責，每一天有速度的推進工作，交付產品。而主管層就可以有足夠的心思，討論產品策略、拉齊團隊的腳步，整合團隊的產生。

這個時候，大概有 8 個左右的 Agile Team，我們終於能個感覺到，8 個團隊一起往同一個大產品目標跑，而且跑出了推進的節奏感。但，總覺得哪裡還是卡卡的～～。

第七階段：組織重整

一直到了這個階段，大概也走過了五年以上。所謂的「團隊」，已經從「專案團隊」變成「專業領域團隊」，開發方法也從「瀑布」，變成了「敏捷」。雖然團隊的跑法已經演變了好幾代，但回頭過來，其實整個大產品的組織架構，卻仍停留在第一階段，依然還是功能性組織。

也就是說，每一個同仁，等於都有兩個老闆，也會有兩個目標。每個同仁在團隊裡面，要為團隊的目標努力；但每個同仁同時也隸屬於某個部，該部的主管也會要求他另外的目標。

而當兩個工作目標內容完全不同時，同仁就等於要用加倍的時間來完成兩個工作。而當兩個老闆的目標衝突的時候，同仁就常在中間兩邊不是人。

這都是「矩陣式組織」(Matrix）標準常遇到的管理挑戰與議題。

但其實跑到這個階段，團隊已經成為主要的生產單位，本來的功能組織的「功能」也變成不事生產。於是我們開始思考，是不是要整個大規模的做組織重整。

我們決定把整個大產品組織，全部打掉重練。我們把原有的功能組織打散，重新把所有的專業領域團隊部門化。也就是負責生產的團隊，直接轉變成為一個「產品線部門」，從虛擬團隊組織變成一個真正有管理實權的部門。

我們等於直接把一個一個的 agile team 部門化了。這些團隊(agile team)，原本都是跨個功能組織所組成，所組成的團隊（虛擬團隊）。我們等於把這些團隊，直接轉變一個部門組織，形成一個產品線部門（實體部門）。

而這個部門的主管，則有的是原有的 PO 升任、也可能是原有的 RD 的技術主管。而部門的主管，自然就是 One Team 的成員之一，同時 One Team 就變成大產品的重要的決策單位，管理整個大產品組織。

專業領域團隊變成產品線部門後，原有團隊內的 PO、UX、RD、QA 等同仁，在這些新的產品線部門裡面，變成分別的功能性組織。再反過來在產品線部門裡面，跨功能組出 2~3 個「團隊」(agile team)，每個團隊一樣跨職能（PO、UX、RD、QA）組成，用 Scrum 的方法，一個一個 sprint 推進產品功能交付。

我們等於把原有的功能性組織，打散進去三大產品線部門。然後把整個大產品組織的 Matrix，也落進去這三大產品線部門裡面。看起來，一樣還是有功能性組織，一樣還是有 Matrix 的存在，但整個大產品的跑法的層次就出來了。

• One Team - 負責產品的方向，形成大產品的政策。

• 產品線部門 - 負責實際「團隊的管理」，並落實One Team的策略。

• 「團隊」- 主力的生產團隊，有節奏的推進產品功能。

這個時候，我們大約有 12 支左右的「團隊」，每個團隊大約有 7 到 15 個左右的成員。這些團隊，也就是實際跑 Agile 的 Agile Team。這些團隊是依然是主力的生產部隊。而產品線部門有三個大部，每一個部分別管理 3~5 個「團隊」，這些產品線部門是大產品裡面，實際負責「組織運作的管理單位」。而 One Team 就變成大產品主要的策略單位，負責產品的長期發展，訂立大產品的政策。

而無論是產品線部門，還是 One Team，最終的目的都是為了讓所有的「團隊」，可以放心的全力衝刺開發工作，用每一個一個的 Sprint，有節奏的穩定推進產品。而其他的議題，就由另外兩個層次的組織架構來解決。產品線部門解決管理與資源問題，one team 解決策略與政策問題。

很多人問我們，我們怎麼跑大規模的 Scrum，怎麼讓整個 200 人的產品團隊，一起跑 Agile。而這幾個「層次」的開展與佈置，就是我們到目前為止體悟出來的方法，也許我們可以把它叫做「91APP Way」（91APP 的軟體開發之道）。

本文授權轉載自零售的科學