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