從0到1，馬蜂窩大交通團隊如何構建高效研發流程體系？

“旅遊之前，先上馬蜂窩” 已經成為許多人習慣性的選擇。

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

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

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

業務從無到有，功能開發需要具有快速迭代和交付的能力。我們採用的是雙週迭代模式，挑戰性比較強。從初期開始，我們就對專案研發全流程管理就非常重視，盡力使每一個環節都能做到規範、高效、透明。

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

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

圖1：需求交付核心時間節點

為了合理安排開發資源，除線上事件外，所有需求每雙週進行一次PK，根據專案價值、優先順序、資源情況等確認後續2周的需求範圍。

日常、專案需求主要流程如下圖所示：

圖2：專案流程示意

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

為了實現研發流程的高效、透明，團隊初期就決定用工具來管理研發專案全週期。經過對比後，我們最終選擇了TAPD，主要是因為 TAPD 具有靈活配置、操作簡便以及支援移動辦公、專案間隔離性強等優勢。

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

用看板標籤區分以下欄位——

共建立了4種通用看板——

圖3: TAPD 看板示例

圖4：成立初期需求流轉流程示意

通過使用“看板”功能，待處理的業務需求優先順序，拆解後各獨立專案的任務清單，研發、測試和上線各環節的進度都一目瞭然，使研發流程的各個環節實現打通，為團隊高效的協作帶來了很好的氛圍和基礎。

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

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

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

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

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

圖5：線上問題反饋流程

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

圖6：線上問題處理流程

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

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

大交通線上測試團隊對可能出現的線上問題進行統一梳理，並將問題型別及其產生的影響進行了相應的評級，不同級別的問題要求解決的時效性不同。

圖7：事件等級和解決時效性要求

對於線上故障級別比較高的，問題排除後會緊急進行故障線下 Review， 復現問題發生的時間線，明確問題產生的原因，並制定可執行的 Actions。

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

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

之前的問題記錄在文件中，格式比較鬆散，所以回溯問題時，如果想進行資料的統計和分析是很困難的。

圖8：問題分類

圖9：TAPD 缺陷模組使用示例

對於已經解決的問題，通過 TAPD“報表”結合規定時間內釋出資料和線上問題資料的綜合資料分析，得出相關結論，制定有針對性的改進措施，生成 TAPD“專案報告”同步專案組成員，避免再次發生。

軟體的質量是在整個研發過程中逐步形成的，離不開 QA 團隊，但只靠 QA 團隊關注肯定是不夠的，開發也要增強自測的意識。另外，為了縮短研發交付週期，對於一些簡單的日常和專案需求，我們採用了開發自測+產品驗收後直接上線的模式。

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

圖10：TAPD 測試計劃示例

從今年1月份開始，部分重點專案加入了提測時show case、上線前統一開會驗收的環節，有效地降低了測試階段bug個數，現在我們在測試階段發現的 Bug 相較從前減少了約 35%。

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

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

因此，我們將看板的使用方式調整為對團隊事務的管理，對整體研發流程和專案質量的管理轉為使用“迭代”，團隊人員之間的工作安排和進度管理使用“甘特圖”，這樣不同的專案和團隊都可以靈活地根據自己的場景和需求新增欄位滿足自己的管理需求，比如業務線、需求來源、價值模型、優先順序、專案角色、關鍵時間節點、線上故障級別、人均有效 bug 數、需求變更次數等等。

圖11：需求狀態流轉

圖12：需求實施流程

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

改用“迭代”後我們的月平均產出專案比“看板”階段提升了約25%。

圖13：TAPD 專案迭代使用示例

圖14：TAPD 甘特圖使用示例

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

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

制定規範的專案流程並落地、每個環節負責人都高質量地交付給下一個環節的負責人，是實現專案持續整合和持續交付的基礎。

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

圖15：不同階段對 TAPD 的使用方式

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

圖16: 專案資料統計

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

最後，感謝 TAPD 這款工具及官方團隊給予我們的支援，希望在未來更加深度的合作中，馬蜂窩和 TAPD 都能為更多團隊的研發效率和專案質量提供更多更好的經驗。