(1)客戶介紹

“旅游之前，先上馬蜂窩。”已經(jīng)成為許多人習慣性的選擇。

 

2019年5月，馬蜂窩完成了新一輪融資，金額達2.5億美元。這也標志著通過集內容、社區(qū)、交易為一體的消費決策場景構建，從攻略社區(qū)起家的馬蜂窩開始邁入在線旅游行業(yè)頭部陣營。

 

決定出門旅游，交通方式是用戶首先要考慮的事情，為了幫助用戶從行程起點開始，高效完成旅游消費決策的全鏈路閉環(huán)，馬蜂窩上線了“大交通”業(yè)務，主要提供機票、火車票及租車自駕游等服務，讓用戶從出行方式開始，享受旅游的樂趣。

(2)項目背景

一年多的時間里，馬蜂窩大交通研發(fā)既要滿足業(yè)務的需求，提升研發(fā)的效能；更要保證服務的質量，降低線上故障率。這支從零組建的團隊經(jīng)歷了不小的挑戰(zhàn)。

(3)解決方案

 

第一階段 成立初期

 

填補業(yè)務空白是首要目標

 

 

在成立初期，團隊的首要目標是快速支撐起業(yè)務，填補業(yè)務空白。

 

業(yè)務從無到有，功能開發(fā)需要具有快速迭代和交付的能力。我們采用的是 雙周迭代模式 ，挑戰(zhàn)性比較強。從初期開始，我們就對項目研發(fā)全流程管理就非常重視，盡力使每一個環(huán)節(jié)都能做到規(guī)范、高效、透明。

 

1.分類需求，明確迭代周期

初期團隊只有十幾人，但是每周并行的需求也不少。為了在項目快速上線的同時保證質量，我們按照需求的不同類型和等級梳理了交付的核心時間節(jié)點，大致分為3類：

• 日常： 開發(fā)工期較短，1個迭代（雙周）內完成。

• 項目： 開發(fā)工期3天以上， 盡量在2個迭代（四周）內完成。

• 線上事件： 計劃外的突發(fā)狀況，通常來說緊急程度高，可能會直接影響線上業(yè)務，需要及時響應。

 

 

為了合理安排開發(fā)資源，除線上事件外，所有需求每雙周進行一次PK，根據(jù) 項目價值、優(yōu)先級、資源情況 等確認后續(xù)2周的需求范圍。

 

日常、項目需求主要流程如下圖所示：

 

 

2.借助TAPD，實現(xiàn)可視化管理

工欲善其事，必先利其器。

 

為了實現(xiàn)研發(fā)流程的高效、透明，團隊初期就決定用工具來管理研發(fā)項目全周期。經(jīng)過對比后，我們最終選擇了TAPD，主要是因為 TAPD 具有 靈活配置、操作簡便以及支持移動辦公、項目間隔離性強 等優(yōu)勢。

 

在團隊初期，我們主要用到的是 TAPD 的 “看板”功能進行需求管理、迭代管理和項目管理。

 

使用看板標簽區(qū)分以下字段——

• 需求優(yōu)先級： P0、P1、P2、P3

• 需求類型： 項目、日常

• 需求來源： 技術、產(chǎn)品和線上

 

共創(chuàng)建了4種通用看板——

• 待PK項目/日常看板

• 日常進度看板

• 項目進度看板

• 線上問題轉需求看板

 

以及針對每個項目的單獨看板。

 

 

這一階段的需求流轉流程如下圖：

 

 

通過使用“看板”功能，待處理的業(yè)務需求優(yōu)先級，拆解后各獨立項目的任務清單，研發(fā)、測試和上線各環(huán)節(jié)的進度都一目了然，使研發(fā)流程的各個環(huán)節(jié)實現(xiàn)打通，為團隊高效的協(xié)作帶來了很好的氛圍和基礎。

 

第二階段 快速發(fā)展期

 

保證交付效率和服務質量是關鍵

 

 

在業(yè)務快速發(fā)展期，開發(fā)聯(lián)調和自測效果不佳，提測質量較差，測試階段Bug較多，一個項目可能就有100多個Bug，導致項目工期不可控和線上質量不可控。 因此縮短線下項目工期、減少測試階段 Bug 以及線上問題數(shù)量、保證服務穩(wěn)定是我們的核心目標。

 

這個階段，我們主要使用了TAPD的“缺陷”功能進行線上問題跟進，以及“測試用例”和“測試計劃”提升研發(fā)自測效率。

 

1.構建線上問題處理閉環(huán)

從前，大交通業(yè)務線上問題反饋的落地點主要是各種微信群，每天大約有將近10個問題，一出現(xiàn)問題相關人員就要在群里討論回復，正常的開發(fā)節(jié)奏總是被打斷，值班人員也要隨時盯著反饋群。

 

隨著時間長了、業(yè)務復雜了、人員多了，這種方式帶來了一系列問題：

• 反饋渠道分散，問題不聚焦，并容易漏掉問題；

• 問題定位難，無效 Bug 多，影響修復效率；

• 無法及時監(jiān)控解決過程，存在同樣問題反復出現(xiàn)的風險

 

針對這些，大交通由測試團隊先行， 優(yōu)化并完善了「線上問題反饋和處理機制」，并通過 TAPD 落地，提升問題解決的效率和質量。

 

1)標準化反饋流程

線上問題反饋的具體流程為：

 

 

內部用戶和外部客服人員反饋問題后，由運營、產(chǎn)品統(tǒng)一記錄到 TAPD 中， 由值班的技術支持人員過濾問題，復現(xiàn)并確認是否為有效 Bug。如經(jīng)確認是有效Bug，則直接提交負責的開發(fā)人員排查修復并評估影響面，遇重大問題則通知 Team Leader 關注；如初步確認為無效 Bug，與問題反饋人進行核實驗證。無論何種類型的 Bug，都會統(tǒng)一錄入 TAPD 記錄， 直到問題關閉。最終，處理結果將反饋至產(chǎn)品、運營和值班人員。

 

每周，責任技術人員以周報的形式向上級同步線上問題處理情況。

 

 

如此一來，問題記錄分布在了不同人員身上，專職記錄同學不用再全職盯微信群的聊天記錄，開發(fā)同學也可以根據(jù)自己的時間安排來處理問題和在TAPD中回復解決方案，不用即時回復群消息，化同步為異步。

 

這不僅大大解放了之前專職記錄同學的時間，使其投入到更多工作中去釋放價值，也有效提升了團隊的協(xié)同， 保證每一條問題都能及時得到記錄、處理和反饋，提升問題解決的效率。

 

2)問題評級，影響范圍大的先處理

大交通線上測試團隊對可能出現(xiàn)的線上問題進行統(tǒng)一梳理，并將問題類型及其產(chǎn)生的影響進行了相應的評級，不同級別的問題要求解決的時效性不同。

 

一旦發(fā)現(xiàn)問題，按照優(yōu)先級由高到低快速處理，最大程度縮小問題影響的范圍，降低業(yè)務損失，同時使技術人員在解決線上問題的過程中更加合理地規(guī)劃時間，提升問題解決效率。

 

 

3)重大故障Review后，創(chuàng)建任務跟進

對于線上故障級別比較高的，問題排除后會緊急進行故障線下 Review， 復現(xiàn)問題發(fā)生的時間線，明確問題產(chǎn)生的原因，并制定可執(zhí)行的 Actions。

 

之前，在故障線下 Review 結束后，這些 Actions 不能得到有效監(jiān)督，有時超過5-6天都沒有往下落實。

 

現(xiàn)在，每個 Action 都會通過 TAPD 建立任務，根據(jù)不同等級設置 Deadline，分配給專人執(zhí)行。Team Leader 會定期跟進各行動項的執(zhí)行，提醒執(zhí)行人及時處理，有效提升處理效率，避免類似故障再次發(fā)生。

 

4)問題分類，提供改進方向參考數(shù)據(jù)

之前的問題記錄在文檔中，格式比較松散，所以回溯問題時，如果想進行數(shù)據(jù)的統(tǒng)計和分析是很困難的。

 

通過TAPD，問題記錄的格式和字段被設置為固定的格式和規(guī)范，就可以從不同角度，對問題進行統(tǒng)計和分析。

 

 

 

對于已經(jīng)解決的問題，通過 TAPD“報表”結合規(guī)定時間內發(fā)布數(shù)據(jù)和線上問題數(shù)據(jù)的綜合數(shù)據(jù)分析，得出相關結論，制定有針對性的改進措施，生成 TAPD“項目報告”同步項目組成員，避免再次發(fā)生。

 

2.研發(fā)自測質量提升

軟件的質量是在整個研發(fā)過程中逐步形成的，離不開 QA 團隊，但只靠 QA 團隊關注肯定是不夠的，開發(fā)也要增強自測的意識。 另外，為了縮短研發(fā)交付周期，對于一些簡單的日常和項目需求，我們采用了開發(fā)自測+產(chǎn)品驗收后直接上線的模式。

 

“測試左移”、“發(fā)現(xiàn)問題漏斗模型”等概念大家可能都聽說過，但真正讓“測試左移”落地并不容易。特別是開始的時候，測試團隊經(jīng)常碰到經(jīng)過自開發(fā)測后的提測需求，連冒煙用例都不會通過的狀況，只能把程序打回。這樣既影響交付，還造成了開發(fā)和測試同學之間的關系緊張。

 

后來，測試同學把研發(fā)自測用例都導入到TAPD用例中，創(chuàng)建研發(fā)自測執(zhí)行計劃，研發(fā)同學聯(lián)調后運行自測用例并在TAPD上標注結果，提測時測試同學會首先在TAPD上檢查自測用例執(zhí)行情況，全部通過后再接收測試。

 

 

從今年1月份開始，部分重點項目加入了提測時show case、上線前統(tǒng)一開會驗收的環(huán)節(jié)，有效地降低了測試階段bug個數(shù) ，現(xiàn)在我們在測試階段發(fā)現(xiàn)的 Bug 相較從前減少了約 35%。

 

第三階段 業(yè)務擴張期

 

需要更精細化的管理

 

 

經(jīng)過一段時間的探索，對于未來一段時間內的業(yè)務模式和技術方向，我們有了比較清晰的定位，隊伍人數(shù)也比最開始增長了幾倍。

 

上文提到，之前我們一直是用 TAPD 的“看板”功能進行需求、任務和項目的迭代管理。隨著使用的逐漸深入，我們發(fā)現(xiàn) TAPD 看板主要是針對團隊輕量級協(xié)作。但隨著團隊的壯大和職責細化，清晰地看到團隊里每個成員當前的工作進度也變得很重要，不僅要管理需求也要管理人員，而且管理的方式也需要更加 場景化、精細化 。

 

因此，我們將看板的使用方式調整為對團隊事務的管理，對整體研發(fā)流程和項目質量的管理轉為使用 “迭代” ，團隊人員之間的工作安排和進度管理使用 “甘特圖” ，這樣不同的項目和團隊都可以靈活地根據(jù)自己的場景和需求添加字段滿足自己的管理需求， 比如業(yè)務線、需求來源、價值模型、優(yōu)先級、項目角色、關鍵時間節(jié)點、線上故障級別、人均有效 bug 數(shù)、需求變更次數(shù)等等。

 

日常和項目需求的狀態(tài)均有以下幾種：

 

 

這一階段需求實施具體流程如下圖所示：

 

 

每次需求PK前都會新建兩個迭代，雙周的日常迭代和四周的項目迭代，PK通過的需求進行相應迭代，項目需求還會拆解成任務，全部任務完成更新狀態(tài)為已上線。

 

改用“迭代”后我們的月平均產(chǎn)出項目比“看板”階段提升了約25%。

 

下圖截取了某一個項目迭代，迭代中的需求全部完成后我們就把迭代關閉：

 

 

改進后使用TAPD“甘特圖”在需求PK時可以查看個人名下的需求，Team Leader也可以隨時查看下屬的任務和任務完成情況。

 

 

此外，隨著跨團隊、跨部門的工作越來越多， 我們也非常重視對全員項目流程管理意識的培養(yǎng)。

 

大交通技術團隊目前沒有專職 PM，所有項目的 PM 均為產(chǎn)品或技術兼職。為了保障所有日常和項目均能如期甚至提前完成、更好地讓項目流程落地以及優(yōu)化項目流程，由兩名技術人員兼任 PMO，針對項目流程中的問題對研發(fā)和產(chǎn)品同學進行分享和培訓，提升研發(fā)人員的項目管理能力和產(chǎn)品同學的流程意識。

 

制定規(guī)范的項目流程并落地、每個環(huán)節(jié)負責人都高質量地交付給下一個環(huán)節(jié)的負責人，是實現(xiàn)項目持續(xù)集成和持續(xù)交付的基礎。

 

第四階段 未來展望

 

持續(xù)探索敏捷+DevOps 的整合之道

 

 

大交通團隊經(jīng)過一年多的摸索，在研發(fā)質量管理上積累了一定的實踐經(jīng)驗，但我們才剛剛啟程。

 

在這個過程中，我們的研發(fā)流程和項目質量管理方面的很多理念和方法都借助于 TAPD 實現(xiàn)落地。小結一下我們在不同階段使用 TAPD 的功能如下圖所示：

 

 

隨著業(yè)務系統(tǒng)越來越復雜，對測試人員和質量體系的要求也會越來越高，我們需要持續(xù) 探索研發(fā)效能的統(tǒng)計度量以及敏捷研發(fā)和 DevOps 的整合之道，使開發(fā)、運維、質量管理實現(xiàn)真正的一體化。 相信這個過程也不會缺少與 TAPD 的密切合作。

(4)價值體現(xiàn)

近期，我們的 PMO 團隊設計了基于 TAPD API 的初版PMO系統(tǒng)，目前主要統(tǒng)計產(chǎn)出和延期率，期望給各Team Leader提供一些數(shù)據(jù)展示和數(shù)據(jù)分析。比如一個迭代究竟接多少項目需求、多少日常需求才是合理的？我們會計算已完成項目和日常的平均人日，和每個迭代的項目和日常個數(shù)以及到期完成情況供各Team Leader作為參考。此系統(tǒng)目前還不完善，我們也在逐步優(yōu)化中。

 

 

另外，我們還會將 TAPD 和大交通內部 DevOps 平臺打通，實現(xiàn)業(yè)務、開發(fā)、運維、質保的全流程自動化。

 

最后，感謝 TAPD 這款工具及官方團隊給予我們的支持，希望在未來更加深度的合作中，馬蜂窩和 TAPD 都能為更多團隊的研發(fā)效率和項目質量提供更多更好的經(jīng)驗。