从0到1,马蜂窝大交通团队如何构建高效研发流程体系?
“旅游之前,先上馬蜂窩” 已經(jīng)成為許多人習(xí)慣性的選擇。
2019年5月,馬蜂窩完成了新一輪融資,金額達2.5億美元。這也標(biāo)志著通過集內(nèi)容、社區(qū)、交易為一體的消費決策場景構(gòu)建,從攻略社區(qū)起家的馬蜂窩開始邁入在線旅游行業(yè)頭部陣營。
決定出門旅游,交通方式是用戶首先要考慮的事情,為了幫助用戶從行程起點開始,高效完成旅游消費決策的全鏈路閉環(huán),馬蜂窩上線了“大交通”業(yè)務(wù),主要提供機票、火車票及租車自駕游等服務(wù),讓用戶從出行方式開始,享受旅游的樂趣。
一年多的時間里,馬蜂窩大交通研發(fā)既要滿足業(yè)務(wù)的需求,提升研發(fā)的效能;更要保證服務(wù)的質(zhì)量,降低線上故障率。這支從零組建的團隊經(jīng)歷了不小的挑戰(zhàn)。第一階段? 成立初期填補業(yè)務(wù)空白是首要目標(biāo)
在成立初期,團隊的首要目標(biāo)是快速支撐起業(yè)務(wù),填補業(yè)務(wù)空白。
業(yè)務(wù)從無到有,功能開發(fā)需要具有快速迭代和交付的能力。我們采用的是雙周迭代模式,挑戰(zhàn)性比較強。從初期開始,我們就對項目研發(fā)全流程管理就非常重視,盡力使每一個環(huán)節(jié)都能做到規(guī)范、高效、透明。
1.?分類需求,明確迭代周期
初期團隊只有十幾人,但是每周并行的需求也不少。為了在項目快速上線的同時保證質(zhì)量,我們按照需求的不同類型和等級梳理了交付的核心時間節(jié)點,大致分為3類:
? 日常:開發(fā)工期較短,1個迭代(雙周)內(nèi)完成。? 項目:開發(fā)工期3天以上, 盡量在2個迭代(四周)內(nèi)完成。? 線上事件:計劃外的突發(fā)狀況,通常來說緊急程度高,可能會直接影響線上業(yè)務(wù),需要及時響應(yīng)。
圖1:需求交付核心時間節(jié)點
為了合理安排開發(fā)資源,除線上事件外,所有需求每雙周進行一次PK,根據(jù)項目價值、優(yōu)先級、資源情況等確認后續(xù)2周的需求范圍。
日常、項目需求主要流程如下圖所示:
圖2:項目流程示意
2.?借助TAPD,實現(xiàn)可視化管理
工欲善其事,必先利其器。
為了實現(xiàn)研發(fā)流程的高效、透明,團隊初期就決定用工具來管理研發(fā)項目全周期。經(jīng)過對比后,我們最終選擇了TAPD,主要是因為 TAPD 具有靈活配置、操作簡便以及支持移動辦公、項目間隔離性強等優(yōu)勢。
在團隊初期,我們主要用到的是 TAPD 的 “看板”功能進行需求管理、迭代管理和項目管理。
使用看板標(biāo)簽區(qū)分以下字段——
? 需求優(yōu)先級:P0、P1、P2、P3? 需求類型:項目、日常? 需求來源:技術(shù)、產(chǎn)品和線上共創(chuàng)建了4種通用看板——
??待PK項目/日常看板??日常進度看板??項目進度看板??線上問題轉(zhuǎn)需求看板以及針對每個項目的單獨看板。圖3: TAPD 看板示例
這一階段的需求流轉(zhuǎn)流程如下圖:圖4:成立初期需求流轉(zhuǎn)流程示意
通過使用“看板”功能,待處理的業(yè)務(wù)需求優(yōu)先級,拆解后各獨立項目的任務(wù)清單,研發(fā)、測試和上線各環(huán)節(jié)的進度都一目了然,使研發(fā)流程的各個環(huán)節(jié)實現(xiàn)打通,為團隊高效的協(xié)作帶來了很好的氛圍和基礎(chǔ)。
第二階段 快速發(fā)展期保證交付效率和服務(wù)質(zhì)量是關(guān)鍵
在業(yè)務(wù)快速發(fā)展期,開發(fā)聯(lián)調(diào)和自測效果不佳,提測質(zhì)量較差,測試階段Bug較多,一個項目可能就有100多個Bug,導(dǎo)致項目工期不可控和線上質(zhì)量不可控。因此縮短線下項目工期、減少測試階段 Bug 以及線上問題數(shù)量、保證服務(wù)穩(wěn)定是我們的核心目標(biāo)。
這個階段,我們主要使用了TAPD的“缺陷”功能進行線上問題跟進,以及“測試用例”和“測試計劃”提升研發(fā)自測效率。
1.?構(gòu)建線上問題處理閉環(huán)
從前,大交通業(yè)務(wù)線上問題反饋的落地點主要是各種微信群,每天大約有將近10個問題,一出現(xiàn)問題相關(guān)人員就要在群里討論回復(fù),正常的開發(fā)節(jié)奏總是被打斷,值班人員也要隨時盯著反饋群。
隨著時間長了、業(yè)務(wù)復(fù)雜了、人員多了,這種方式帶來了一系列問題:
? 反饋渠道分散,問題不聚焦,并容易漏掉問題;? 問題定位難,無效 Bug 多,影響修復(fù)效率;? 無法及時監(jiān)控解決過程,存在同樣問題反復(fù)出現(xiàn)的風(fēng)險針對這些,大交通由測試團隊先行,優(yōu)化并完善了「線上問題反饋和處理機制」,并通過 TAPD 落地,提升問題解決的效率和質(zhì)量。??
1)標(biāo)準(zhǔn)化反饋流程
線上問題反饋的具體流程為:圖5:線上問題反饋流程
內(nèi)部用戶和外部客服人員反饋問題后,由運營、產(chǎn)品統(tǒng)一記錄到 TAPD 中, 由值班的技術(shù)支持人員過濾問題,復(fù)現(xiàn)并確認是否為有效 Bug。如經(jīng)確認是有效Bug,則直接提交負責(zé)的開發(fā)人員排查修復(fù)并評估影響面,遇重大問題則通知 Team Leader 關(guān)注;如初步確認為無效 Bug,與問題反饋人進行核實驗證。無論何種類型的 Bug,都會統(tǒng)一錄入 TAPD 記錄, 直到問題關(guān)閉。最終,處理結(jié)果將反饋至產(chǎn)品、運營和值班人員。
每周,責(zé)任技術(shù)人員以周報的形式向上級同步線上問題處理情況。圖6:線上問題處理流程
如此一來,問題記錄分布在了不同人員身上,專職記錄同學(xué)不用再全職盯微信群的聊天記錄,開發(fā)同學(xué)也可以根據(jù)自己的時間安排來處理問題和在TAPD中回復(fù)解決方案,不用即時回復(fù)群消息,化同步為異步。
這不僅大大解放了之前專職記錄同學(xué)的時間,使其投入到更多工作中去釋放價值,也有效提升了團隊的協(xié)同,保證每一條問題都能及時得到記錄、處理和反饋,提升問題解決的效率。
2)問題評級,影響范圍大的先處理
大交通線上測試團隊對可能出現(xiàn)的線上問題進行統(tǒng)一梳理,并將問題類型及其產(chǎn)生的影響進行了相應(yīng)的評級,不同級別的問題要求解決的時效性不同。
一旦發(fā)現(xiàn)問題,按照優(yōu)先級由高到低快速處理,最大程度縮小問題影響的范圍,降低業(yè)務(wù)損失,同時使技術(shù)人員在解決線上問題的過程中更加合理地規(guī)劃時間,提升問題解決效率。圖7:事件等級和解決時效性要求
3)重大故障Review后,創(chuàng)建任務(wù)跟進
對于線上故障級別比較高的,問題排除后會緊急進行故障線下 Review, 復(fù)現(xiàn)問題發(fā)生的時間線,明確問題產(chǎn)生的原因,并制定可執(zhí)行的 Actions。
之前,在故障線下 Review 結(jié)束后,這些 Actions 不能得到有效監(jiān)督,有時超過5-6天都沒有往下落實。
現(xiàn)在,每個 Action 都會通過 TAPD 建立任務(wù),根據(jù)不同等級設(shè)置 Deadline,分配給專人執(zhí)行。Team Leader 會定期跟進各行動項的執(zhí)行,提醒執(zhí)行人及時處理,有效提升處理效率,避免類似故障再次發(fā)生。
4)問題分類,提供改進方向參考數(shù)據(jù)
之前的問題記錄在文檔中,格式比較松散,所以回溯問題時,如果想進行數(shù)據(jù)的統(tǒng)計和分析是很困難的。
通過TAPD,問題記錄的格式和字段被設(shè)置為固定的格式和規(guī)范,就可以從不同角度,對問題進行統(tǒng)計和分析。圖8:問題分類
圖9:TAPD 缺陷模塊使用示例
對于已經(jīng)解決的問題,通過 TAPD“報表”結(jié)合規(guī)定時間內(nèi)發(fā)布數(shù)據(jù)和線上問題數(shù)據(jù)的綜合數(shù)據(jù)分析,得出相關(guān)結(jié)論,制定有針對性的改進措施,生成 TAPD“項目報告”同步項目組成員,避免再次發(fā)生。
2.研發(fā)自測質(zhì)量提升
軟件的質(zhì)量是在整個研發(fā)過程中逐步形成的,離不開 QA 團隊,但只靠 QA 團隊關(guān)注肯定是不夠的,開發(fā)也要增強自測的意識。另外,為了縮短研發(fā)交付周期,對于一些簡單的日常和項目需求,我們采用了開發(fā)自測+產(chǎn)品驗收后直接上線的模式。
“測試左移”、“發(fā)現(xiàn)問題漏斗模型”等概念大家可能都聽說過,但真正讓“測試左移”落地并不容易。特別是開始的時候,測試團隊經(jīng)常碰到經(jīng)過自開發(fā)測后的提測需求,連冒煙用例都不會通過的狀況,只能把程序打回。這樣既影響交付,還造成了開發(fā)和測試同學(xué)之間的關(guān)系緊張。
后來,測試同學(xué)把研發(fā)自測用例都導(dǎo)入到TAPD用例中,創(chuàng)建研發(fā)自測執(zhí)行計劃,研發(fā)同學(xué)聯(lián)調(diào)后運行自測用例并在TAPD上標(biāo)注結(jié)果,提測時測試同學(xué)會首先在TAPD上檢查自測用例執(zhí)行情況,全部通過后再接收測試。圖10:TAPD 測試計劃示例
從今年1月份開始,部分重點項目加入了提測時show case、上線前統(tǒng)一開會驗收的環(huán)節(jié),有效地降低了測試階段bug個數(shù),現(xiàn)在我們在測試階段發(fā)現(xiàn)的 Bug 相較從前減少了約 35%。
第三階段 業(yè)務(wù)擴張期需要更精細化的管理
經(jīng)過一段時間的探索,對于未來一段時間內(nèi)的業(yè)務(wù)模式和技術(shù)方向,我們有了比較清晰的定位,隊伍人數(shù)也比最開始增長了幾倍。
上文提到,之前我們一直是用 TAPD 的“看板”功能進行需求、任務(wù)和項目的迭代管理。隨著使用的逐漸深入,我們發(fā)現(xiàn) TAPD 看板主要是針對團隊輕量級協(xié)作。但隨著團隊的壯大和職責(zé)細化,清晰地看到團隊里每個成員當(dāng)前的工作進度也變得很重要,不僅要管理需求也要管理人員,而且管理的方式也需要更加場景化、精細化。
因此,我們將看板的使用方式調(diào)整為對團隊事務(wù)的管理,對整體研發(fā)流程和項目質(zhì)量的管理轉(zhuǎn)為使用“迭代”,團隊人員之間的工作安排和進度管理使用“甘特圖”,這樣不同的項目和團隊都可以靈活地根據(jù)自己的場景和需求添加字段滿足自己的管理需求,比如業(yè)務(wù)線、需求來源、價值模型、優(yōu)先級、項目角色、關(guān)鍵時間節(jié)點、線上故障級別、人均有效 bug 數(shù)、需求變更次數(shù)等等。
日常和項目需求的狀態(tài)均有以下幾種:圖11:需求狀態(tài)流轉(zhuǎn)
這一階段需求實施具體流程如下圖所示:圖12:需求實施流程
每次需求PK前都會新建兩個迭代,雙周的日常迭代和四周的項目迭代,PK通過的需求進行相應(yīng)迭代,項目需求還會拆解成任務(wù),全部任務(wù)完成更新狀態(tài)為已上線。
改用“迭代”后我們的月平均產(chǎn)出項目比“看板”階段提升了約25%。
下圖截取了某一個項目迭代,迭代中的需求全部完成后我們就把迭代關(guān)閉:圖13:TAPD 項目迭代使用示例
改進后使用TAPD“甘特圖”在需求PK時可以查看個人名下的需求,Team Leader也可以隨時查看下屬的任務(wù)和任務(wù)完成情況。圖14:TAPD 甘特圖使用示例
此外,隨著跨團隊、跨部門的工作越來越多,我們也非常重視對全員項目流程管理意識的培養(yǎng)。
大交通技術(shù)團隊目前沒有專職 PM,所有項目的 PM 均為產(chǎn)品或技術(shù)兼職。為了保障所有日常和項目均能如期甚至提前完成、更好地讓項目流程落地以及優(yōu)化項目流程,由兩名技術(shù)人員兼任 PMO,針對項目流程中的問題對研發(fā)和產(chǎn)品同學(xué)進行分享和培訓(xùn),提升研發(fā)人員的項目管理能力和產(chǎn)品同學(xué)的流程意識。
制定規(guī)范的項目流程并落地、每個環(huán)節(jié)負責(zé)人都高質(zhì)量地交付給下一個環(huán)節(jié)的負責(zé)人,是實現(xiàn)項目持續(xù)集成和持續(xù)交付的基礎(chǔ)。
第四階段 未來展望持續(xù)探索敏捷+DevOps 的整合之道
大交通團隊經(jīng)過一年多的摸索,在研發(fā)質(zhì)量管理上積累了一定的實踐經(jīng)驗,但我們才剛剛啟程。
在這個過程中,我們的研發(fā)流程和項目質(zhì)量管理方面的很多理念和方法都借助于 TAPD 實現(xiàn)落地。小結(jié)一下我們在不同階段使用 TAPD 的功能如下圖所示:圖15:不同階段對 TAPD 的使用方式
隨著業(yè)務(wù)系統(tǒng)越來越復(fù)雜,對測試人員和質(zhì)量體系的要求也會越來越高,我們需要持續(xù)探索研發(fā)效能的統(tǒng)計度量以及敏捷研發(fā)和 DevOps 的整合之道,使開發(fā)、運維、質(zhì)量管理實現(xiàn)真正的一體化。相信這個過程也不會缺少與 TAPD 的密切合作。
近期,我們的 PMO 團隊設(shè)計了基于 TAPD ?API 的初版PMO系統(tǒng),目前主要統(tǒng)計產(chǎn)出和延期率,期望給各Team Leader提供一些數(shù)據(jù)展示和數(shù)據(jù)分析。比如一個迭代究竟接多少項目需求、多少日常需求才是合理的?我們會計算已完成項目和日常的平均人日,和每個迭代的項目和日常個數(shù)以及到期完成情況供各Team Leader作為參考。此系統(tǒng)目前還不完善,我們也在逐步優(yōu)化中。圖16: 項目數(shù)據(jù)統(tǒng)計
另外,我們還會將 TAPD 和大交通內(nèi)部 DevOps 平臺打通,實現(xiàn)業(yè)務(wù)、開發(fā)、運維、質(zhì)保的全流程自動化。
最后,感謝 TAPD 這款工具及官方團隊給予我們的支持,希望在未來更加深度的合作中,馬蜂窩和 TAPD 都能為更多團隊的研發(fā)效率和項目質(zhì)量提供更多更好的經(jīng)驗。
總結(jié)
以上是生活随笔為你收集整理的从0到1,马蜂窝大交通团队如何构建高效研发流程体系?的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 大牛书单 | 人工智能方向好书分享(第二
- 下一篇: 「递归」第2集 | 变得了魔术,解得了高