如果用一句話概述本篇的主題昼蛀，那就是：關注8人團隊的自組織性，構建百人團隊的研發(fā)工作流酣藻。
Worktile是在15年的時候引入的Scrum曹洽。在那之前我們并沒有采用標準的敏捷實踐框架，一是研發(fā)團隊并不大辽剧，二是我們自己的協(xié)作工具有足夠的可視化能力送淆。
但當我們對外推出了第二款產(chǎn)品Lesschat（后來Worktile企業(yè)版/協(xié)作版，綠色Logo）以后怕轿，Worktile（這里指Worktile基礎版偷崩，紅色Logo）需要持續(xù)更新，Lesschat也需要持續(xù)更新撞羽，我們該如何處理工作的優(yōu)先級呢阐斜？
基于實際的問題，公司決定把參與Lesschat開發(fā)的工程師獨立出來诀紊，配備上獨立的產(chǎn)品負責人谒出，組建了一個8人的Scrum團隊。我們落地Scrum的過程大概是這樣的：
第一步：Scrum團隊啟動會
首先，確定Terry大神為我們的PO笤喳，確定Shaun Xu大神為我們的Scrum Master为居。然后我們共同制定了Scrum團隊的工作協(xié)議：
由PO維護產(chǎn)品待辦列表 Sprint周期為2周 Scrum各個會議的時間、地點杀狡、內(nèi)容代碼提交方式故事點的標準 ……
第二步：先跑一個Sprint
我們在第一周周一的早上10點蒙畴，開計劃會議。由PO進行產(chǎn)品講解呜象，說明用戶故事的優(yōu)先級膳凝，由開發(fā)團隊預估故事規(guī)模、拆分開發(fā)任務恭陡，以及最后承諾Sprint目標蹬音。
每天早上10點，我們在工位附近的走廊里開站立會議子姜。每人花兩分鐘的時間同步工作進展祟绊。
我們在第二周周五下午4點楼入，開驗收會議哥捕。由開發(fā)任務的負責人演示其完成的工作，然后由PO決定未完成的任務或新增的Bug要不要放在這個版本中嘉熊。
在第二周周五下午5點遥赚，開回顧會議。每個人都說一說團隊做的好的和不好的地方阐肤，我們一起確定改進方案凫佛。
第三周周二的晚上，我們部署了第一個Sprint完成的產(chǎn)品增量孕惜。避開周末上線是擔心除了問題沒人處理愧薛，多預留兩天是為改Bug。
第三步：兩周一次衫画，不斷的改進
這個習慣我們堅持到現(xiàn)在毫炉。
和很多團隊一樣，我們在早期也遇到了很多問題削罩，比如：
前后端共同完成的用戶故事預估起來往往偏差較大?
移動端小伙伴想要的API經(jīng)常排不上號?
突發(fā)的緊急任務（來自老板）打亂Sprint的計劃?
每天的站立會議階段性的流于形式 ……數(shù)不勝數(shù)
我們不斷的發(fā)現(xiàn)自己的問題瞄勾，不斷的改進。隨著一個又一個的Sprint弥激，們發(fā)現(xiàn)可以應用一些優(yōu)秀的工程實踐提升研發(fā)效率进陡，比如簡單設計、測試驅(qū)動開發(fā)微服、持續(xù)集成趾疚、持續(xù)部署等等。我總結我們的實踐如下圖：
我們在變，市場也在變糙麦，市場變了戈二，我們也要跟著變。大概在16年的時候喳资，公司決定在Lesschat的基礎上開發(fā)Worktile 5.0觉吭，也就是企業(yè)版，面向的是企業(yè)場景仆邓，方向轉(zhuǎn)變很大鲜滩，對我們研發(fā)來說又是一次考驗。
忘了用了多久完成基礎架構的調(diào)整节值，但是一定很快徙硅，快到我已經(jīng)忘了遇到了什么困難。
我們在16年年底基本完成Worktile 5.0搞疗，17年年初對外發(fā)布嗓蘑。
5.0上線后，Worktile提供了一種新的企業(yè)服務方式匿乃，簡單概述為：Worktile平臺+Worktile的各個子產(chǎn)品（消息桩皿、任務、日歷幢炸、網(wǎng)盤泄隔、審批等等）。
對于我們研發(fā)來說宛徊，這里的挑戰(zhàn)有兩個：一是把各個子產(chǎn)品拆分出來佛嬉，改為微服務的架構方式；二是研發(fā)團隊的規(guī)恼⑻欤化敏捷暖呕。第一個問題解決起來很簡單，第二個問題確實考驗了我們苞氮。
開始的時候湾揽，我們應對各個子產(chǎn)品的需求，采取的方式是打一槍換一個地方葱淳。通俗的解釋就是钝腺，一個Sprint我們投入到“日歷”這個產(chǎn)品中，一個Sprint我們投入到“網(wǎng)盤”這個產(chǎn)品中赞厕。
很明顯艳狐，這樣的方式不足以應對快速變化的市場，因為來自“網(wǎng)盤”這個產(chǎn)品的需求往往要等好幾個Sprint才能實現(xiàn)皿桑，對于客戶來說這樣的速度太慢了毫目。
雖然從研發(fā)的角度蔬啡，我們是嚴格按照產(chǎn)品待辦列表的優(yōu)先級安排Sprint工作的，但是這絕非是一個理想的安排镀虐。另一方面箱蟆，開發(fā)人數(shù)在增長，但是大家都在一個Scrum團隊中刮便，這樣的團隊開會效率越來越差空猜，嚴重影響了開發(fā)時間。
如何把團隊級別的敏捷上升到業(yè)務級別恨旱，這個問題越發(fā)重要辈毯，隨著Worktile 6.0、7.0的開發(fā)搜贤，我們慢慢的找到了感覺谆沃，下圖是我總結的經(jīng)驗：
團隊級別的敏捷關注的是構建一個高效的自組織團隊。這樣的團隊能夠很好的完成開發(fā)工作仪芒，也能夠應用優(yōu)秀的工程實踐提升自我的效率唁影。
而業(yè)務級別的敏捷更加關注的是通過規(guī)模化管理研發(fā)團隊掂名，提升研發(fā)效能据沈，從而持續(xù)穩(wěn)定的實現(xiàn)業(yè)務價值。
組織級別的敏捷更加關注的是通過充足的市場調(diào)研確定方向铆隘，然后通過產(chǎn)品的真實數(shù)據(jù)驗證方向卓舵，為下一步?jīng)Q策提供依據(jù)南用。
具體實施起來的過程是這樣的：
1膀钠、市場調(diào)研和需求評估
a.調(diào)研包括但不限于：行業(yè)動態(tài)、競品分析裹虫、客戶反饋等?
b.需求評估由市場肿嘲、產(chǎn)品、技術等相關方的負責人參與
2筑公、業(yè)務線的敏捷
按季度或月確定研發(fā)目標?
由技術負責人雳窟、架構師評估，由產(chǎn)品總負責人拆分為產(chǎn)品特性?
由產(chǎn)品總負責人和各個產(chǎn)品負責人拆分特性?
由技術匣屡、架構師封救、產(chǎn)品確定各個特性的規(guī)模和完成周期?
將拆分后的用戶故事放入各個Scrum團隊的PBI中，設置優(yōu)先級
各個Scrum團隊計劃各自的Sprint工作?
各個Scrum團隊代表每周同步各自的工作進展?
按期進行各個模塊捣作、子產(chǎn)品的集成誉结，部署到UAT環(huán)境?
按期完成目標
3、驗證需求和后續(xù)行動
進行必要的數(shù)據(jù)收集券躁，例如重要頁面的QPS惩坑，轉(zhuǎn)化率等等
進行數(shù)據(jù)分析?
確定后續(xù)的產(chǎn)品改動方向
隨著敏捷實踐深入掉盅，我們發(fā)現(xiàn)研發(fā)的效能問題是個全行業(yè)的問題。同時以舒，通過數(shù)據(jù)分析趾痘，我們發(fā)現(xiàn)自家客戶50%以上是研發(fā)場景，那為什么不打造一個專業(yè)的研發(fā)管理工具賦能給我們的客戶呢蔓钟？
于是18年永票，公司正式?jīng)Q定打造Worktile 8.0（Worktile研發(fā)版，現(xiàn)已獨立品牌為PingCode）滥沫，19年8.0上線瓦侮。
在這個過程中，為了保證我們的交付效率佣谐，我們自研了一套持續(xù)交付平臺肚吏，它可以為各個Scrum團隊賦能，通過少量的配置化即可接入平臺狭魂，輕松實現(xiàn)CICD罚攀。
到目前為止，我們的敏捷已經(jīng)涉及100人以上雌澄，有管理層斋泄、市場人員、產(chǎn)品镐牺、技術炫掐、運維，甚至還有HR睬涧。
為什么我說HR也敏捷呢募胃？因為我們的考核和晉級制度，也從硬指標變?yōu)橐则?qū)動自主性為主畦浓，這不就是文化敏捷的標志嗎痹束？
2020年，為了給Worktile客戶提供更好的服務讶请，Worktile 8.0正式更名為PingCode祷嘶，專注于服務研發(fā)場景的企業(yè)客戶，而Worktile則繼續(xù)服務于協(xié)作領域的企業(yè)客戶夺溢。
這對于我們研發(fā)來說又是一個新的考驗论巍，但是這樣的考驗已經(jīng)不算什么難題了。
未來的市場還會變风响，但是我們有足夠的信心應對嘉汰。我們也非常歡迎有研發(fā)管理需求的客戶加入我們，敏捷沒有終點钞诡，我們一起成長郑现。
研發(fā)管理101軍規(guī)系列導讀：
