08　从0到1，马蜂窝大交通团队如何构建高效研发流程体系

作者介绍

孙海燕　马蜂窝大交通测试团队负责人，兼任大交通PMO。现就职于马蜂窝，曾就职于阿里巴巴、蘑菇街。主要负责业务测试、质量体系打造、流程改进、工具建设等工作。

案例综述

本案例将从四个部分讲述马蜂窝大交通团队在不同阶段，如何通过建立项目进程和问题反馈流程、建设平台及工具链、团队培养等方式，提升研发效能，减少线上故障，保证服务质量。四个部分及其目标如下所示。

1）成立初期的目标：填补业务空白。

2）快速发展期的目标：保证交付效率和服务质量。

3）业务扩张期的目标：精细化、场景化。

4）未来展望的目标：探索敏捷与DevOps的整合。

案例背景

2019年5月，瞄准年轻群体旅游市场的马蜂窝完成了由腾讯领投的新一轮融资，融资金额达2.5亿美元。官方数据显示，马蜂窝已连续四年实现GMV超100%增长。新一轮融资的完成，也标志着通过集内容、社区、交易为一体的消费决策场景的构建，从攻略社区起家的马蜂窝开始迈入在线旅游行业头部阵营。

决定出门旅游，交通方式是用户首先要考虑的事情，为了帮助用户从行程起点开始，高效完成旅游消费决策的全链路闭环，2018年马蜂窝上线了“大交通”业务，主要提供机票、火车票及更受年轻人青睐的租车自驾游等服务，让用户从选择出行方式开始，享受旅游的乐趣。

一年多的时间里，马蜂窝大交通研发既要满足业务的需求，提升研发的效能，也要保证服务的质量，降低线上故障率。这支从零组建的团队经历了不小的挑战。

案例实施

1.团队初始，填补业务空白是首要目标

在成立初期，团队的目标是快速支撑起业务，因此填补业务空白是第一目标。

业务从无到有，功能开发需要具有快速迭代和交付的能力。我们采用的是双周迭代模式，比较有挑战性。从初期开始，我们就对项目研发的全流程管理非常重视，尽力使每一个环节都能做到规范、高效、透明。

（1）需求分类，明确项目周期

初期团队只有十几人，但是每周并行的需求也不少。为了在项目快速上线的同时保证质量，我们按照需求的不同类型和等级梳理了交付的核心时间节点，需求大致分为以下3类。

1）日常需求：开发工期较短，1个迭代（双周）内完成。

2）项目需求：开发工期3天以上，尽量在2个迭代（四周）内完成。

3）线上事件：计划外的突发状况，通常来说紧急程度高，可能会直接影响线上业务，需要及时响应。

为了合理安排开发资源，除线上事件外，所有需求每两周进行一次PK，并根据项目价值、优先级、资源情况等确认后续两周的需求范围。

（2）借助工具，实现项目可视化管理

“工欲善其事，必先利其器”，为了助力高效、透明的研发流程，团队初期就确立了使用工具来进行研发项目全周期管理的方式。经过对比后，我们最终选择了TAPD，因为TAPD具有配置和操作简便、支持移动办公、项目间隔离性强等优势。

在初期，我们主要用TAPD的看板功能进行需求管理、迭代管理和项目管理，如图8-1所示。并使用标签来区分需求优先级（P0～P3）、需求类型项目、日常和需求来源技术、产品和线上等。共创建了5种通用看板，包括待PK项目、日常看板、日常进度看板、项目进度看板、线上问题转需求看板和针对每个项目的单独看板。

图8-1　TAPD看板

需求流转流程如图8-2所示。

图8-2　需求流转

通过使用看板功能，需要处理的业务需求优先级、拆解后各独立项目的任务清单、研发、测试和上线的进度都一目了然，研发流程的各个环节被打通，为团队高效的协作建立了良好的氛围和基础。

2.发展变化期，保证交付效率和服务质量是关键

在业务快速发展期，开发自测效果不佳，提测质量较差，线下Bug较多。一个项目可能就有100多个Bug，Bug多导致项目工期不可控和线上质量不可控。因此缩短线下项目工期，减少线下Bug数量以及减少线上问题数量，保证服务稳定成了我们的核心目标。这个阶段，我们主要使用TAPD的缺陷功能进行线上问题跟进，并使用测试用例和测试计划功能提升研发自测。

（1）构建线上问题处理闭环

以前，大交通业务线上问题反馈的落地点主要是微信群，每天大约有将近10个问题，有咨询、核实类的，也有最后确认为线上故障的，这类反馈在群里的问题由专门的值班人员记录。随着时间的推移，业务越来越复杂，人员越来越多，这种方式带来了一系列问题：

•反馈渠道分散，问题不聚焦，容易漏掉问题。

•问题定位难，无效Bug多，影响修复效率。

•无法及时监控解决过程，存在同样问题反复出现的风险。

针对以上的问题，大交通研发团队优化并完善了线上问题反馈和处理机制，此外通过TAPD落地，提升了解决问题的效率和质量。

标准化反馈流程

线上问题反馈的具体流程为，内部用户和外部客服人员反馈问题后，由运营、产品统一记录到TAPD中，然后值班的技术支持人员过滤问题，复现并确认是否为有效Bug。如经确认是有效问题，则直接提交给相关的开发人员排查修复并评估影响面，遇重大问题则通知Team Leader关注；如初步确认为无效Bug，则与问题反馈人进行核实验证。无论是何种类型的Bug，都要求统一录入TAPD记录，直到问题关闭。最终处理结果将反馈至产品、运营和值班人员。

每周责任技术人员以周报的形式向上级同步线上问题处理情况，如此一来，问题的记录分布在了不同人员身上，专职记录人员不用再全天候盯微信群的聊天记录了，开发人员也可以根据自己的时间安排来处理问题并在TAPD中回复解决方案，不用即时回复群消息，化同步为异步，不仅大大解放了之前专职记录人员的时间，使其可投入更多精力到其他有价值的工作上，也有效提升了团队的协同，保证每一条问题都能及时得到记录、处理和反馈，提升解决问题的效率。

问题评级，影响范围较大的优先处理

在大交通线上，测试团队对可能出现的线上问题进行了统一梳理，并将问题类型及其产生的影响进行了相应的评级。在问题录入时初判问题的等级，不同级别的问题其解决的时效性不同。

一旦发现问题，按照优先级由高到低快速处理，最大程度缩小问题影响的范围，降低业务损失，同时使技术人员在解决线上问题的过程中可更加合理地规划时间，提升问题解决效率。具体的故障级别及解决时限见表8-1。

表8-1　故障级别与解决时限

重大故障Review后行动项跟进，避免再次发生

对于优先级比较高的线上故障，问题排除后会紧急进行故障线下Review，复现问题发生的时间线，明确问题产生的原因，并制定可执行的Actions。

之前，在故障线下Review结束后，这些Actions不能得到有效监督，有时五、六天甚至更久，都没有往下落实。现在，每个Action都会通过TAPD建立任务作为行动项，根据不同的等级设置Deadline，分配给专人执行。Team Leader会定期跟进各个行动项的执行，提醒执行人及时处理，有效提高处理效率并避免类似的故障再次发生。

问题分类，提供改进方向参考数据

由于之前的问题记录呈现在维基上，格式比较松散，所以当回溯问题时，很难进行数据的统计和分析。在TAPD上，问题的记录有固定的格式和规范，这样我们就可以从不同的角度，对问题进行统计和分析。

对于已经解决的问题，结合规定时间内发布的数据和线上问题数据进行综合分析，得出结论，制定有针对性的改进措施，避免再次发生。

（2）研发自测质量提升

软件的质量是在整个研发过程中逐步形成的，离不开质量保证团队，但只靠质量保证团队关注肯定是不够的，开发也要增强自测的意识。另外，为了缩短研发交付周期，对于一些简单的日常和项目需求，我们采用了开发自测，产品验收后直接上线的模式。

“测试左移”“发现问题漏斗模型”等概念大家可能都听说过，但真正让“测试左移”落地并不容易。实行之初，测试团队经常会碰到开发自测后的提测需求有时连冒烟用例都无法通过，只能把程序打回。这样既影响交付，还造成了开发和测试团队间的关系紧张。

后来，测试人员把研发自测用例都导入到TAPD用例中，创建研发自测执行计划，开发人员连调后运行自测用例并在TAPD上标注结果，提测时测试人员会首先在TAPD上检查自测用例的执行情况，全部通过后再接收测试。从2019年1月份开始，我们的部分重点项目加入了提测时show case、上线前统一开会验收的环节，有效地降低了线下Bug个数，2019年第一季度的线下Bug比2018年第四季度下降了约25%，2019年第二季度比第一季度下降了约15%。

3.业务扩张期，需要更精细化的管理

经过一段时间的探索，我们对于未来一段时间内的业务模式和技术方向有了比较清晰的定位，队伍也逐渐壮大为初始团队的几倍。

之前我们一直是用TAPD的看板功能进行需求、任务和项目的迭代管理，但随着使用的深入，我们发现TAPD看板主要是针对团队轻量级协作的，但随着团队的壮大和职责的细化，能清晰地查看团队里每个成员当前的工作进度也很重要，此外，除了对需求进行管理以外，也需要对人员进行管理，而且管理的方式要更加场景化、精细化。

因此，我们将看板的使用方式调整为对团队事务的管理，将对整体研发流程和项目质量的管理转为使用迭代功能，团队人员之间的工作安排和进度管理使用甘特图功能，这样不同的项目和团队都可以灵活地根据自己的场景和需求添加字段来满足自己的管理需求，比如添加的字段包括业务线、需求来源、价值模型、优先级、项目角色、关键时间节点、线上故障级别、人均有效Bug数、需求变更次数等。

每次需求PK前都会新建两个迭代，即双周的日常迭代和四周的项目迭代，PK通过的需求会进行相应的迭代，我们把项目需求拆解成任务，全部任务完成则更新状态为已上线。改用迭代后我们的月平均产出项目比看板阶段提升了约25%。

使用TAPD甘特图后，在需求PK时可以查看个人名下的需求，领导也可以随时查看下属的任务和任务完成情况。

此外，随着跨团队、跨部门的工作越来越多，我们也非常重视对全员项目流程管理意识的培养。大交通技术团队目前没有专职项目经理，所有项目的项目经理均为产品或技术兼职。为了保障所有日常和项目均能如期甚至提前完成、更好地让项目流程落地以及优化项目流程，由两名技术人员兼任PMO，针对项目流程中的问题为研发和产品人员进行分享和培训，提升研发人员的项目管理能力和产品人员的流程意识。

制定规范的项目流程并落地，每个环节负责人都高质量地交付给下一个环节的负责人，是实现项目持续集成和持续交付的基础。

4.未来，持续探索敏捷与DevOps的整合之道

大交通团队经过一年多的摸索，在研发流程管理上积累了一定的实践经验，但我们才刚刚启程。

随着业务系统越来越复杂，对测试人员和质量体系的要求也会越来越高，我们需要持续探索敏捷研发和DevOps的整合之道，使开发、运维和质量管理实现真正的一体化。

近期，我们的PMO团队设计了基于TAPD API的初版PMO系统，目前主要用于统计产出和延期率，目的是给各Teamleader提供一些数据展示和分析，比如一个迭代究竟接多少项目需求、多少日常需求才是合理的，我们会计算已完成项目和日常的平均人日，每个迭代的项目和日常个数以及到期完成情况，供各Teamleader作为参考。此系统目前还不完善，我们也在逐步优化中。

另外，我们还会将TAPD和大交通内部DevOps平台打通，实现业务、开发、运维、质保的全流程自动化。

案例总结

要分析业务和团队在不同阶段的特点、目标和挑战，不断提升项目管理和质量思维，完善流程，通过平台研发、工具建设和应用，保证高质量的持续交付。