【研發(fā)管理101軍規(guī)003】實(shí)戰(zhàn)規(guī)?；艚荩簭?人到百人的敏捷之路 | IDCF

內(nèi)容來源：孫敬云

作者：孫敬云

拓展閱讀：【研發(fā)管理101軍規(guī)001】 兩周迭代，形成團(tuán)隊(duì)持續(xù)習(xí)慣 | IDCF

【研發(fā)管理101軍規(guī)002】特種部隊(duì)——更符合不確定業(yè)務(wù)的組織架構(gòu)設(shè)計(jì) | IDCF

如果用一句話概述本篇的主題，那就是：關(guān)注8人團(tuán)隊(duì)的自組織性，構(gòu)建百人團(tuán)隊(duì)的研發(fā)工作流。

Worktile是在15年的時(shí)候引入的Scrum。在那之前我們并沒有采用標(biāo)準(zhǔn)的敏捷實(shí)踐框架，一是研發(fā)團(tuán)隊(duì)并不大；二是我們自己的協(xié)作工具有足夠的可視化能力。

但當(dāng)我們對(duì)外推出了第二款產(chǎn)品Lesschat（后來Worktile企業(yè)版/協(xié)作版，綠色Logo）以后，Worktile（這里指Worktile基礎(chǔ)版，紅色Logo）需要持續(xù)更新，Lesschat也需要持續(xù)更新，我們?cè)?/span>如何處理工作的優(yōu)先級(jí)呢？

基于實(shí)際的問題，公司決定把參與Lesschat開發(fā)的工程師獨(dú)立出來，配備上獨(dú)立的產(chǎn)品負(fù)責(zé)人，組建了一個(gè)8人的Scrum團(tuán)隊(duì)。我們落地Scrum的過程大概是這樣的：

第一步：Scrum團(tuán)隊(duì)啟動(dòng)會(huì)

首先，確定Terry大神為我們的PO，確定Shaun Xu大神為我們的Scrum Master。然后我們共同制定了Scrum團(tuán)隊(duì)的工作協(xié)議：

由PO維護(hù)產(chǎn)品待辦列表 Sprint周期為2周 Scrum各個(gè)會(huì)議的時(shí)間、地點(diǎn)、內(nèi)容代碼提交方式故事點(diǎn)的標(biāo)準(zhǔn) ……

第二步：先跑一個(gè)Sprint

我們?cè)诘谝恢苤芤坏脑缟?0點(diǎn)，開計(jì)劃會(huì)議。由PO進(jìn)行產(chǎn)品講解，說明用戶故事的優(yōu)先級(jí)，由開發(fā)團(tuán)隊(duì)預(yù)估故事規(guī)模、拆分開發(fā)任務(wù)，以及最后承諾Sprint目標(biāo)。

每天早上10點(diǎn)，我們?cè)诠の桓浇淖呃壤镩_站立會(huì)議。每人花兩分鐘的時(shí)間同步工作進(jìn)展。

我們?cè)诘诙苤芪逑挛?點(diǎn)，開驗(yàn)收會(huì)議。由開發(fā)任務(wù)的負(fù)責(zé)人演示其完成的工作，然后由PO決定未完成的任務(wù)或新增的Bug要不要放在這個(gè)版本中。

在第二周周五下午5點(diǎn)，開回顧會(huì)議。每個(gè)人都說一說團(tuán)隊(duì)做的好的和不好的地方，我們一起確定改進(jìn)方案。

第三周周二的晚上，我們部署了第一個(gè)Sprint完成的產(chǎn)品增量。避開周末上線是擔(dān)心除了問題沒人處理，多預(yù)留兩天是為改Bug。

第三步：兩周一次，不斷改進(jìn)

這個(gè)習(xí)慣我們堅(jiān)持到現(xiàn)在。

和很多團(tuán)隊(duì)一樣，我們?cè)谠缙谝灿龅搅撕芏鄦栴}，比如：

• 前后端共同完成的用戶故事預(yù)估起來往往偏差較大 
• 移動(dòng)端小伙伴想要的API經(jīng)常排不上號(hào) 
• 突發(fā)的緊急任務(wù)（來自老板）打亂Sprint的計(jì)劃 
• 每天的站立會(huì)議階段性的流于形式 ……數(shù)不勝數(shù)

我們不斷的發(fā)現(xiàn)自己的問題，不斷的改進(jìn)。隨著一個(gè)又一個(gè)的Sprint，們發(fā)現(xiàn)可以應(yīng)用一些優(yōu)秀的工程實(shí)踐提升研發(fā)效率，比如簡(jiǎn)單設(shè)計(jì)、測(cè)試驅(qū)動(dòng)開發(fā)、持續(xù)集成、持續(xù)部署等等。我總結(jié)我們的實(shí)踐如下圖：

我們?cè)谧?，市?chǎng)也在變，市場(chǎng)變了，我們也要跟著變。大概在16年的時(shí)候，公司決定在Lesschat的基礎(chǔ)上開發(fā)Worktile 5.0，也就是企業(yè)版，面向的是企業(yè)場(chǎng)景，方向轉(zhuǎn)變很大，對(duì)我們研發(fā)來說又是一次考驗(yàn)。

忘了用了多久完成基礎(chǔ)架構(gòu)的調(diào)整，但是一定很快，快到我已經(jīng)忘了遇到了什么困難。

我們?cè)?6年年底基本完成Worktile 5.0，17年年初對(duì)外發(fā)布。

5.0上線后，Worktile提供了一種新的企業(yè)服務(wù)方式，簡(jiǎn)單概述為：Worktile平臺(tái)+Worktile的各個(gè)子產(chǎn)品（消息、任務(wù)、日歷、網(wǎng)盤、審批等等）。

對(duì)于我們研發(fā)來說，這里的挑戰(zhàn)有兩個(gè)：一是把各個(gè)子產(chǎn)品拆分出來，改為微服務(wù)的架構(gòu)方式；二是研發(fā)團(tuán)隊(duì)的規(guī)?；艚荨?/span>第一個(gè)問題解決起來很簡(jiǎn)單，第二個(gè)問題確實(shí)考驗(yàn)了我們。

開始的時(shí)候，我們應(yīng)對(duì)各個(gè)子產(chǎn)品的需求，采取的方式是打一槍換一個(gè)地方。通俗的解釋就是，一個(gè)Sprint我們投入到“日歷”這個(gè)產(chǎn)品中，一個(gè)Sprint我們投入到“網(wǎng)盤”這個(gè)產(chǎn)品中。

很明顯，這樣的方式不足以應(yīng)對(duì)快速變化的市場(chǎng)，因?yàn)閬碜浴熬W(wǎng)盤”這個(gè)產(chǎn)品的需求往往要等好幾個(gè)Sprint才能實(shí)現(xiàn)，對(duì)于客戶來說這樣的速度太慢了。

雖然從研發(fā)的角度，我們是嚴(yán)格按照產(chǎn)品待辦列表的優(yōu)先級(jí)安排Sprint工作的，但是這絕非是一個(gè)理想的安排。另一方面，開發(fā)人數(shù)在增長(zhǎng)，但是大家都在一個(gè)Scrum團(tuán)隊(duì)中，這樣的團(tuán)隊(duì)開會(huì)效率越來越差，嚴(yán)重影響了開發(fā)時(shí)間。

如何把團(tuán)隊(duì)級(jí)別的敏捷上升到業(yè)務(wù)級(jí)別，這個(gè)問題越發(fā)重要，隨著Worktile 6.0、7.0的開發(fā)，我們慢慢的找到了感覺，下圖是我總結(jié)的經(jīng)驗(yàn)：

• 團(tuán)隊(duì)級(jí)別的敏捷關(guān)注的是構(gòu)建一個(gè)高效的自組織團(tuán)隊(duì)。這樣的團(tuán)隊(duì)能夠很好的完成開發(fā)工作，也能夠應(yīng)用優(yōu)秀的工程實(shí)踐提升自我的效率。
• 業(yè)務(wù)級(jí)別的敏捷更加關(guān)注的是通過規(guī)?；芾硌邪l(fā)團(tuán)隊(duì)，提升研發(fā)效能，從而持續(xù)穩(wěn)定的實(shí)現(xiàn)業(yè)務(wù)價(jià)值。
• 組織級(jí)別的敏捷更加關(guān)注的是通過充足的市場(chǎng)調(diào)研確定方向，然后通過產(chǎn)品的真實(shí)數(shù)據(jù)驗(yàn)證方向，為下一步?jīng)Q策提供依據(jù)。

具體實(shí)施起來的過程是這樣的： 

1）市場(chǎng)調(diào)研和需求評(píng)估 

• 調(diào)研包括但不限于：行業(yè)動(dòng)態(tài)、競(jìng)品分析、客戶反饋等 
• 需求評(píng)估由市場(chǎng)、產(chǎn)品、技術(shù)等相關(guān)方的負(fù)責(zé)人參與

2）業(yè)務(wù)線的敏捷 

• 按季度或月確定研發(fā)目標(biāo) 
• 由技術(shù)負(fù)責(zé)人、架構(gòu)師評(píng)估，由產(chǎn)品總負(fù)責(zé)人拆分為產(chǎn)品特性 
• 由產(chǎn)品總負(fù)責(zé)人和各個(gè)產(chǎn)品負(fù)責(zé)人拆分特性 
• 由技術(shù)、架構(gòu)師、產(chǎn)品確定各個(gè)特性的規(guī)模和完成周期 
• 將拆分后的用戶故事放入各個(gè)Scrum團(tuán)隊(duì)的PBI中，設(shè)置優(yōu)先級(jí) 
• 各個(gè)Scrum團(tuán)隊(duì)計(jì)劃各自的Sprint工作 
• 各個(gè)Scrum團(tuán)隊(duì)代表每周同步各自的工作進(jìn)展 
• 按期進(jìn)行各個(gè)模塊、子產(chǎn)品的集成，部署到UAT環(huán)境 
• 按期完成目標(biāo) 

3）驗(yàn)證需求和后續(xù)行動(dòng) 

• 進(jìn)行必要的數(shù)據(jù)收集，例如重要頁(yè)面的QPS，轉(zhuǎn)化率等等 
• 進(jìn)行數(shù)據(jù)分析 
• 確定后續(xù)的產(chǎn)品改動(dòng)方向

隨著敏捷實(shí)踐深入，我們發(fā)現(xiàn)研發(fā)的效能問題是個(gè)全行業(yè)的問題。同時(shí)，通過數(shù)據(jù)分析，我們發(fā)現(xiàn)自家客戶50%以上是研發(fā)場(chǎng)景，那為什么不打造一個(gè)專業(yè)的研發(fā)管理工具賦能給我們的客戶呢？

于是18年，公司正式?jīng)Q定打造Worktile 8.0（Worktile研發(fā)版，現(xiàn)已獨(dú)立品牌為PingCode），19年8.0上線。

在這個(gè)過程中，為了保證我們的交付效率，我們自研了一套持續(xù)交付平臺(tái)，它可以為各個(gè)Scrum團(tuán)隊(duì)賦能，通過少量的配置化即可接入平臺(tái)，輕松實(shí)現(xiàn)CICD。

到目前為止，我們的敏捷已經(jīng)涉及100人以上，有管理層、市場(chǎng)人員、產(chǎn)品、技術(shù)、運(yùn)維，甚至還有HR。

為什么我說HR也敏捷呢？因?yàn)槲覀兊目己撕蜁x級(jí)制度，也從硬指標(biāo)變?yōu)橐则?qū)動(dòng)自主性為主，這不就是文化敏捷的標(biāo)志嗎？

2020年，為了給Worktile客戶提供更好的服務(wù)，Worktile 8.0正式更名為PingCode，專注于服務(wù)研發(fā)場(chǎng)景的企業(yè)客戶，而Worktile則繼續(xù)服務(wù)于協(xié)作領(lǐng)域的企業(yè)客戶。

這對(duì)于我們研發(fā)來說又是一個(gè)新的考驗(yàn)，但是這樣的考驗(yàn)已經(jīng)不算什么難題了。

未來的市場(chǎng)還會(huì)變，但是我們有足夠的信心應(yīng)對(duì)。

想要提升敏捷DevOps技能，來場(chǎng)DevOps黑客馬拉松！

想要尋找第二增長(zhǎng)曲線實(shí)現(xiàn)創(chuàng)新增速，來場(chǎng)DevOps黑客馬拉松！

2021年4月24-25日，IDCF DevOps黑客馬拉松走進(jìn)天府之國(guó)-成都

趕緊報(bào)名參加吧~可自己報(bào)名，也可公司組團(tuán)參加哦！