實戰規模化敏捷：從8人到百人的敏捷之路

內容來源：孫敬雲

作者：孫敬雲

擴充閱讀：【研發管理101軍規001】 兩週迭代，形成團隊持續習慣 | IDCF

【研發管理101軍規002】特種部隊——更符合不確定業務的組織架構設計 | IDCF

如果用一句話概述本篇的主題，那就是：關注8人團隊的自組織性，構建百人團隊的研發工作流。

Worktile是在15年的時候引入的Scrum。在那之前我們並沒有採用標準的敏捷實踐框架，一是研發團隊並不大；二是我們自己的協作工具有足夠的視覺化能力。

但當我們對外推出了第二款產品Lesschat（後來Worktile企業版/協作版，綠色Logo）以後，Worktile（這裡指Worktile基礎版，紅色Logo）需要持續更新，Lesschat也需要持續更新，我們該如何處理工作的優先順序呢？

基於實際的問題，公司決定把參與Lesschat開發的工程師獨立出來，配備上獨立的產品負責人，組建了一個8人的Scrum團隊。我們落地Scrum的過程大概是這樣的：

第一步：Scrum團隊啟動會

首先，確定Terry大神為我們的PO，確定Shaun Xu大神為我們的Scrum Master。然後我們共同制定了Scrum團隊的工作協議：

由PO維護產品待辦列表 Sprint週期為2周 Scrum各個會議的時間、地點、內容程式碼提交方式故事點的標準 ……

第二步：先跑一個Sprint

我們在第一週週一的早上10點，開計劃會議。由PO進行產品講解，說明使用者故事的優先順序，由開發團隊預估故事規模、拆分開發任務，以及最後承諾Sprint目標。

每天早上10點，我們在工位附近的走廊裡開站立會議。每人花兩分鐘的時間同步工作進展。

我們在第二週週五下午4點，開驗收會議。由開發任務的負責人演示其完成的工作，然後由PO決定未完成的任務或新增的Bug要不要放在這個版本中。

在第二週週五下午5點，開回顧會議。每個人都說一說團隊做的好的和不好的地方，我們一起確定改進方案。

第三週週二的晚上，我們部署了第一個Sprint完成的產品增量。避開週末上線是擔心除了問題沒人處理，多預留兩天是為改Bug。

第三步：兩週一次，不斷改進

這個習慣我們堅持到現在。

和很多團隊一樣，我們在早期也遇到了很多問題，比如：

• 前後端共同完成的使用者故事預估起來往往偏差較大 
• 移動端小夥伴想要的API經常排不上號 
• 突發的緊急任務（來自老闆）打亂Sprint的計劃 
• 每天的站立會議階段性的流於形式 ……數不勝數

我們不斷的發現自己的問題，不斷的改進。隨著一個又一個的Sprint，們發現可以應用一些優秀的工程實踐提升研發效率，比如簡單設計、測試驅動開發、持續整合、持續部署等等。我總結我們的實踐如下圖：

我們在變，市場也在變，市場變了，我們也要跟著變。大概在16年的時候，公司決定在Lesschat的基礎上開發Worktile 5.0，也就是企業版，面向的是企業場景，方向轉變很大，對我們研發來說又是一次考驗。

忘了用了多久完成基礎架構的調整，但是一定很快，快到我已經忘了遇到了什麼困難。

我們在16年年底基本完成Worktile 5.0，17年年初對外發布。

5.0上線後，Worktile提供了一種新的企業服務方式，簡單概述為：Worktile平臺+Worktile的各個子產品（訊息、任務、日曆、網盤、審批等等）。

對於我們研發來說，這裡的挑戰有兩個：一是把各個子產品拆分出來，改為微服務的架構方式；二是研發團隊的規模化敏捷。第一個問題解決起來很簡單，第二個問題確實考驗了我們。

開始的時候，我們應對各個子產品的需求，採取的方式是打一槍換一個地方。通俗的解釋就是，一個Sprint我們投入到“日曆”這個產品中，一個Sprint我們投入到“網盤”這個產品中。

很明顯，這樣的方式不足以應對快速變化的市場，因為來自“網盤”這個產品的需求往往要等好幾個Sprint才能實現，對於客戶來說這樣的速度太慢了。

雖然從研發的角度，我們是嚴格按照產品待辦列表的優先順序安排Sprint工作的，但是這絕非是一個理想的安排。另一方面，開發人數在增長，但是大家都在一個Scrum團隊中，這樣的團隊開會效率越來越差，嚴重影響了開發時間。

如何把團隊級別的敏捷上升到業務級別，這個問題越發重要，隨著Worktile 6.0、7.0的開發，我們慢慢的找到了感覺，下圖是我總結的經驗：

• 團隊級別的敏捷關注的是構建一個高效的自組織團隊。這樣的團隊能夠很好的完成開發工作，也能夠應用優秀的工程實踐提升自我的效率。
• 業務級別的敏捷更加關注的是透過規模化管理研發團隊，提升研發效能，從而持續穩定的實現業務價值。
• 組織級別的敏捷更加關注的是透過充足的市場調查確定方向，然後透過產品的真實資料驗證方向，為下一步決策提供依據。

具體實施起來的過程是這樣的： 

1）市場調查和需求評估 

• 調研包括但不限於：行業動態、競品分析、客戶反饋等 
• 需求評估由市場、產品、技術等相關方的負責人參與

2）業務線的敏捷 

• 按季度或月確定研發目標 
• 由技術負責人、架構師評估，由產品總負責人拆分為產品特性 
• 由產品總負責人和各個產品負責人拆分特性 
• 由技術、架構師、產品確定各個特性的規模和完成周期 
• 將拆分後的使用者故事放入各個Scrum團隊的PBI中，設定優先順序 
• 各個Scrum團隊計劃各自的Sprint工作 
• 各個Scrum團隊代表每週同步各自的工作進展 
• 按期進行各個模組、子產品的整合，部署到UAT環境 
• 按期完成目標 

3）驗證需求和後續行動 

• 進行必要的資料收集，例如重要頁面的QPS，轉化率等等 
• 進行資料分析 
• 確定後續的產品改動方向

隨著敏捷實踐深入，我們發現研發的效能問題是個全行業的問題。同時，透過資料分析，我們發現自家客戶50%以上是研發場景，那為什麼不打造一個專業的研發管理工具賦能給我們的客戶呢？

於是18年，公司正式決定打造Worktile 8.0（Worktile研發版，現已獨立品牌為PingCode），19年8.0上線。

在這個過程中，為了保證我們的交付效率，我們自研了一套持續交付平臺，它可以為各個Scrum團隊賦能，透過少量的配置化即可接入平臺，輕鬆實現CICD。

到目前為止，我們的敏捷已經涉及100人以上，有管理層、市場人員、產品、技術、運維，甚至還有HR。

為什麼我說HR也敏捷呢？因為我們的考核和晉級制度，也從硬指標變為以驅動自主性為主，這不就是文化敏捷的標誌嗎？

2020年，為了給Worktile客戶提供更好的服務，Worktile 8.0正式更名為PingCode，專注於服務研發場景的企業客戶，而Worktile則繼續服務於協作領域的企業客戶。

這對於我們研發來說又是一個新的考驗，但是這樣的考驗已經不算什麼難題了。

未來的市場還會變，但是我們有足夠的信心應對。