从0到1，马蜂窝大交通团队如何构建高效研发流程体系？
“旅游之前，先上马蜂窝” 已经成为许多人习惯性的选择。
2019年5月，马蜂窝完成了新一轮融资，金额达2.5亿美元。这也标志着通过集内容、社区、交易为一体的消费决策场景构建，从攻略社区起家的马蜂窝开始迈入在线旅游行业头部阵营。
决定出门旅游，交通方式是用户首先要考虑的事情，为了帮助用户从行程起点开始，高效完成旅游消费决策的全链路闭环，马蜂窝上线了“大交通”业务，主要提供机票、火车票及租车自驾游等服务，让用户从出行方式开始，享受旅游的乐趣。
第一阶段 成立初期填补业务空白是首要目标
在成立初期，团队的首要目标是快速支撑起业务，填补业务空白。
业务从无到有，功能开发需要具有快速迭代和交付的能力。我们采用的是双周迭代模式，挑战性比较强。从初期开始，我们就对项目研发全流程管理就非常重视，尽力使每一个环节都能做到规范、高效、透明。
1. 分类需求，明确迭代周期
初期团队只有十几人，但是每周并行的需求也不少。为了在项目快速上线的同时保证质量，我们按照需求的不同类型和等级梳理了交付的核心时间节点，大致分为3类：
• 线上事件：计划外的突发状况，通常来说紧急程度高，可能会直接影响线上业务，需要及时响应。
图1：需求交付核心时间节点
为了合理安排开发资源，除线上事件外，所有需求每双周进行一次PK，根据项目价值、优先级、资源情况等确认后续2周的需求范围。
日常、项目需求主要流程如下图所示：
图2：项目流程示意
2. 借助TAPD，实现可视化管理
工欲善其事，必先利其器。
为了实现研发流程的高效、透明，团队初期就决定用工具来管理研发项目全周期。经过对比后，我们最终选择了TAPD，主要是因为 TAPD 具有灵活配置、操作简便以及支持移动办公、项目间隔离性强等优势。
在团队初期，我们主要用到的是 TAPD 的 “看板”功能进行需求管理、迭代管理和项目管理。
使用看板标签区分以下字段——
共创建了4种通用看板——
图3: TAPD 看板示例
图4：成立初期需求流转流程示意
通过使用“看板”功能，待处理的业务需求优先级，拆解后各独立项目的任务清单，研发、测试和上线各环节的进度都一目了然，使研发流程的各个环节实现打通，为团队高效的协作带来了很好的氛围和基础。
第二阶段 快速发展期保证交付效率和服务质量是关键
在业务快速发展期，开发联调和自测效果不佳，提测质量较差，测试阶段Bug较多，一个项目可能就有100多个Bug，导致项目工期不可控和线上质量不可控。因此缩短线下项目工期、减少测试阶段 Bug 以及线上问题数量、保证服务稳定是我们的核心目标。
这个阶段，我们主要使用了TAPD的“缺陷”功能进行线上问题跟进，以及“测试用例”和“测试计划”提升研发自测效率。
1. 构建线上问题处理闭环
从前，大交通业务线上问题反馈的落地点主要是各种微信群，每天大约有将近10个问题，一出现问题相关人员就要在群里讨论回复，正常的开发节奏总是被打断，值班人员也要随时盯着反馈群。
随着时间长了、业务复杂了、人员多了，这种方式带来了一系列问题：
针对这些，大交通由测试团队先行，优化并完善了「线上问题反馈和处理机制」，并通过 TAPD 落地，提升问题解决的效率和质量。
1)标准化反馈流程
图5：线上问题反馈流程
内部用户和外部客服人员反馈问题后，由运营、产品统一记录到 TAPD 中， 由值班的技术支持人员过滤问题，复现并确认是否为有效 Bug。如经确认是有效Bug，则直接提交负责的开发人员排查修复并评估影响面，遇重大问题则通知 Team Leader 关注；如初步确认为无效 Bug，与问题反馈人进行核实验证。无论何种类型的 Bug，都会统一录入 TAPD 记录， 直到问题关闭。最终，处理结果将反馈至产品、运营和值班人员。
图6：线上问题处理流程
如此一来，问题记录分布在了不同人员身上，专职记录同学不用再全职盯微信群的聊天记录，开发同学也可以根据自己的时间安排来处理问题和在TAPD中回复解决方案，不用即时回复群消息，化同步为异步。
这不仅大大解放了之前专职记录同学的时间，使其投入到更多工作中去释放价值，也有效提升了团队的协同，保证每一条问题都能及时得到记录、处理和反馈，提升问题解决的效率。
2)问题评级，影响范围大的先处理
大交通线上测试团队对可能出现的线上问题进行统一梳理，并将问题类型及其产生的影响进行了相应的评级，不同级别的问题要求解决的时效性不同。
图7：事件等级和解决时效性要求
3)重大故障Review后，创建任务跟进
对于线上故障级别比较高的，问题排除后会紧急进行故障线下 Review， 复现问题发生的时间线，明确问题产生的原因，并制定可执行的 Actions。
之前，在故障线下 Review 结束后，这些 Actions 不能得到有效监督，有时超过5-6天都没有往下落实。
现在，每个 Action 都会通过 TAPD 建立任务，根据不同等级设置 Deadline，分配给专人执行。Team Leader 会定期跟进各行动项的执行，提醒执行人及时处理，有效提升处理效率，避免类似故障再次发生。
4)问题分类，提供改进方向参考数据
之前的问题记录在文档中，格式比较松散，所以回溯问题时，如果想进行数据的统计和分析是很困难的。
图8：问题分类
图9：TAPD 缺陷模块使用示例
对于已经解决的问题，通过 TAPD“报表”结合规定时间内发布数据和线上问题数据的综合数据分析，得出相关结论，制定有针对性的改进措施，生成 TAPD“项目报告”同步项目组成员，避免再次发生。
2.研发自测质量提升
软件的质量是在整个研发过程中逐步形成的，离不开 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，针对项目流程中的问题对研发和产品同学进行分享和培训，提升研发人员的项目管理能力和产品同学的流程意识。
制定规范的项目流程并落地、每个环节负责人都高质量地交付给下一个环节的负责人，是实现项目持续集成和持续交付的基础。
第四阶段 未来展望持续探索敏捷+DevOps 的整合之道
大交通团队经过一年多的摸索，在研发质量管理上积累了一定的实践经验，但我们才刚刚启程。
图15：不同阶段对 TAPD 的使用方式
随着业务系统越来越复杂，对测试人员和质量体系的要求也会越来越高，我们需要持续探索研发效能的统计度量以及敏捷研发和 DevOps 的整合之道，使开发、运维、质量管理实现真正的一体化。相信这个过程也不会缺少与 TAPD 的密切合作。
图16: 项目数据统计
另外，我们还会将 TAPD 和大交通内部 DevOps 平台打通，实现业务、开发、运维、质保的全流程自动化。
最后，感谢 TAPD 这款工具及官方团队给予我们的支持，希望在未来更加深度的合作中，马蜂窝和 TAPD 都能为更多团队的研发效率和项目质量提供更多更好的经验。