产品
协作&沟通
看板
思维导图
在线文档
企业微信集成
规划&跟踪
敏捷需求规划
迭代计划&跟踪
缺陷跟踪管理
测试计划&用例
任务&工时管理
构建&交付
代码集成
持续集成&交付
应用&扩展
T魔方
第三方集成
解决方案
轻量协作
敏捷研发
DevOps持续交付
客户案例
支持
在线帮助
上手视频
帮助文档
使用手册
新鲜Show
服务支持
客户服务
小微扶持
合作伙伴
95716
中文
中文
English
Beta
登录
注册
行业案例
black;马蜂窝;从0到1，马蜂窝大交通团队如何构建高效研发流程体系？
扫一扫分享此案例
扫一扫分享此案例
扫一扫分享此案例
“旅游之前，先上马蜂窝。”已经成为许多人习惯性的选择。 2019年5月，马蜂窝完成了新一轮融资，金额达2.5亿美元。这也标志着通过集内容、社区、交易为一体的消费决策场景构建，从攻略社区起家的马蜂窝开始迈入在线旅游行业头部阵营。 决定出门旅游，交通方式是用户首先要考虑的事情，为了帮助用户从行程起点开始，高效完成旅游消费决策的全链路闭环，马蜂窝上线了“大交通”业务，主要提供机票、火车票及租车自驾游等服务，让用户从出行方式开始，享受旅游的乐趣。 一年多的时间里，马蜂窝大交通研发既要满足业务的需求，提升研发的效能；更要保证服务的质量，降低线上故障率。这支从零组建的团队经历了不小的挑战。  ## !!#2f58b8 第一阶段 成立初期!! ### 填补业务空白是首要目标  在成立初期，团队的首要目标是快速支撑起业务，填补业务空白。 业务从无到有，功能开发需要具有快速迭代和交付的能力。我们采用的是 !!!#ffff00 __双周迭代模式__!!! ，挑战性比较强。从初期开始，我们就对项目研发全流程管理就非常重视，尽力使每一个环节都能做到规范、高效、透明。 #### 1.分类需求，明确迭代周期 初期团队只有十几人，但是每周并行的需求也不少。为了在项目快速上线的同时保证质量，我们按照需求的不同类型和等级梳理了交付的核心时间节点，大致分为3类： • __日常：__ 开发工期较短，1个迭代（双周）内完成。 • __项目：__ 开发工期3天以上， 尽量在2个迭代（四周）内完成。 • __线上事件：__ 计划外的突发状况，通常来说紧急程度高，可能会直接影响线上业务，需要及时响应。  为了合理安排开发资源，除线上事件外，所有需求每双周进行一次PK，根据 !!!#ffff00 __项目价值、优先级、资源情况__!!! 等确认后续2周的需求范围。 日常、项目需求主要流程如下图所示：  #### 2.借助TAPD，实现可视化管理 工欲善其事，必先利其器。 为了实现研发流程的高效、透明，团队初期就决定用工具来管理研发项目全周期。经过对比后，我们最终选择了TAPD，主要是因为 TAPD 具有 !!!#ffff00 灵活配置、操作简便以及支持移动办公、项目间隔离性强!!! 等优势。 在团队初期，我们主要用到的是 TAPD 的 “看板”功能进行需求管理、迭代管理和项目管理。 使用看板标签区分以下字段—— • __需求优先级：__ P0、P1、P2、P3 • __需求类型：__ 项目、日常 • __需求来源：__ 技术、产品和线上 共创建了4种通用看板—— • 待PK项目/日常看板 • 日常进度看板 • 项目进度看板 • 线上问题转需求看板 以及针对每个项目的单独看板。  这一阶段的需求流转流程如下图：  通过使用“看板”功能，待处理的业务需求优先级，拆解后各独立项目的任务清单，研发、测试和上线各环节的进度都一目了然，使研发流程的各个环节实现打通，为团队高效的协作带来了很好的氛围和基础。 ## !!#2f58b8第二阶段 快速发展期!! ### 保证交付效率和服务质量是关键  在业务快速发展期，开发联调和自测效果不佳，提测质量较差，测试阶段Bug较多，一个项目可能就有100多个Bug，导致项目工期不可控和线上质量不可控。 !!!#ffff00 因此缩短线下项目工期、减少测试阶段 Bug 以及线上问题数量、保证服务稳定是我们的核心目标。!!! 这个阶段，我们主要使用了TAPD的“缺陷”功能进行线上问题跟进，以及“测试用例”和“测试计划”提升研发自测效率。 #### 1.构建线上问题处理闭环 从前，大交通业务线上问题反馈的落地点主要是各种微信群，每天大约有将近10个问题，一出现问题相关人员就要在群里讨论回复，正常的开发节奏总是被打断，值班人员也要随时盯着反馈群。 随着时间长了、业务复杂了、人员多了，这种方式带来了一系列问题： • 反馈渠道分散，问题不聚焦，并容易漏掉问题； • 问题定位难，无效 Bug 多，影响修复效率； • 无法及时监控解决过程，存在同样问题反复出现的风险 针对这些，大交通由测试团队先行， !!!#ffff00 优化并完善了「线上问题反馈和处理机制」，并通过 TAPD 落地，提升问题解决的效率和质量。!!! ##### 1)标准化反馈流程 线上问题反馈的具体流程为：  内部用户和外部客服人员反馈问题后，由运营、产品统一记录到 TAPD 中， 由值班的技术支持人员过滤问题，复现并确认是否为有效 Bug。如经确认是有效Bug，则直接提交负责的开发人员排查修复并评估影响面，遇重大问题则通知 Team Leader 关注；如初步确认为无效 Bug，与问题反馈人进行核实验证。无论何种类型的 Bug，都会统一录入 TAPD 记录， 直到问题关闭。最终，处理结果将反馈至产品、运营和值班人员。 每周，责任技术人员以周报的形式向上级同步线上问题处理情况。  如此一来，问题记录分布在了不同人员身上，专职记录同学不用再全职盯微信群的聊天记录，开发同学也可以根据自己的时间安排来处理问题和在TAPD中回复解决方案，不用即时回复群消息，化同步为异步。 这不仅大大解放了之前专职记录同学的时间，使其投入到更多工作中去释放价值，也有效提升了团队的协同， !!!#ffff00 保证每一条问题都能及时得到记录、处理和反馈，提升问题解决的效率。!!! ##### 2)问题评级，影响范围大的先处理 大交通线上测试团队对可能出现的线上问题进行统一梳理，并将问题类型及其产生的影响进行了相应的评级，不同级别的问题要求解决的时效性不同。 一旦发现问题，按照优先级由高到低快速处理，最大程度缩小问题影响的范围，降低业务损失，同时使技术人员在解决线上问题的过程中更加合理地规划时间，提升问题解决效率。  ##### 3)重大故障Review后，创建任务跟进 对于线上故障级别比较高的，问题排除后会紧急进行故障线下 Review， 复现问题发生的时间线，明确问题产生的原因，并制定可执行的 Actions。 之前，在故障线下 Review 结束后，这些 Actions 不能得到有效监督，有时超过5-6天都没有往下落实。 现在，每个 Action 都会通过 TAPD 建立任务，根据不同等级设置 Deadline，分配给专人执行。Team Leader 会定期跟进各行动项的执行，提醒执行人及时处理，有效提升处理效率，避免类似故障再次发生。 ##### 4)问题分类，提供改进方向参考数据 之前的问题记录在文档中，格式比较松散，所以回溯问题时，如果想进行数据的统计和分析是很困难的。 !!!#ffff00 通过TAPD，问题记录的格式和字段被设置为固定的格式和规范，就可以从不同角度，对问题进行统计和分析。!!!   对于已经解决的问题，通过 TAPD“报表”结合规定时间内发布数据和线上问题数据的综合数据分析，得出相关结论，制定有针对性的改进措施，生成 TAPD“项目报告”同步项目组成员，避免再次发生。 #### 2.研发自测质量提升 软件的质量是在整个研发过程中逐步形成的，离不开 QA 团队，但只靠 QA 团队关注肯定是不够的，开发也要增强自测的意识。 !!!#ffff00 另外，为了缩短研发交付周期，对于一些简单的日常和项目需求，我们采用了开发自测+产品验收后直接上线的模式。!!! “测试左移”、“发现问题漏斗模型”等概念大家可能都听说过，但真正让“测试左移”落地并不容易。特别是开始的时候，测试团队经常碰到经过自开发测后的提测需求，连冒烟用例都不会通过的状况，只能把程序打回。这样既影响交付，还造成了开发和测试同学之间的关系紧张。 后来，测试同学把研发自测用例都导入到TAPD用例中，创建研发自测执行计划，研发同学联调后运行自测用例并在TAPD上标注结果，提测时测试同学会首先在TAPD上检查自测用例执行情况，全部通过后再接收测试。  从今年1月份开始，部分重点项目加入了提测时show case、上线前统一开会验收的环节，有效地降低了测试阶段bug个数 !!!#ffff00 ，现在我们在测试阶段发现的 Bug 相较从前减少了约 35%。!!! ## !!#2f58b8第三阶段 业务扩张期!! ### 需要更精细化的管理  经过一段时间的探索，对于未来一段时间内的业务模式和技术方向，我们有了比较清晰的定位，队伍人数也比最开始增长了几倍。 上文提到，之前我们一直是用 TAPD 的“看板”功能进行需求、任务和项目的迭代管理。随着使用的逐渐深入，我们发现 TAPD 看板主要是针对团队轻量级协作。但随着团队的壮大和职责细化，清晰地看到团队里每个成员当前的工作进度也变得很重要，不仅要管理需求也要管理人员，而且管理的方式也需要更加 !!!#ffff00 场景化、精细化!!! 。 因此，我们将看板的使用方式调整为对团队事务的管理，对整体研发流程和项目质量的管理转为使用 !!!#ffff00 “迭代”!!! ，团队人员之间的工作安排和进度管理使用 !!!#ffff00 “甘特图”!!! ，这样不同的项目和团队都可以灵活地根据自己的场景和需求添加字段满足自己的管理需求， !!!#ffff00 比如业务线、需求来源、价值模型、优先级、项目角色、关键时间节点、线上故障级别、人均有效 bug 数、需求变更次数等等。!!! 日常和项目需求的状态均有以下几种：  这一阶段需求实施具体流程如下图所示：  每次需求PK前都会新建两个迭代，双周的日常迭代和四周的项目迭代，PK通过的需求进行相应迭代，项目需求还会拆解成任务，全部任务完成更新状态为已上线。 !!!#ffff00 __改用“迭代”后我们的月平均产出项目比“看板”阶段提升了约25%。__!!! 下图截取了某一个项目迭代，迭代中的需求全部完成后我们就把迭代关闭：  改进后使用TAPD“甘特图”在需求PK时可以查看个人名下的需求，Team Leader也可以随时查看下属的任务和任务完成情况。  此外，随着跨团队、跨部门的工作越来越多， !!!#ffff00 我们也非常重视对全员项目流程管理意识的培养。!!! 大交通技术团队目前没有专职 PM，所有项目的 PM 均为产品或技术兼职。为了保障所有日常和项目均能如期甚至提前完成、更好地让项目流程落地以及优化项目流程，由两名技术人员兼任 PMO，针对项目流程中的问题对研发和产品同学进行分享和培训，提升研发人员的项目管理能力和产品同学的流程意识。 !!!#ffff00 制定规范的项目流程并落地、每个环节负责人都高质量地交付给下一个环节的负责人，是实现项目持续集成和持续交付的基础。!!! ## !!#2f58b8第四阶段 未来展望!! ### 持续探索敏捷+DevOps 的整合之道  大交通团队经过一年多的摸索，在研发质量管理上积累了一定的实践经验，但我们才刚刚启程。 在这个过程中，我们的研发流程和项目质量管理方面的很多理念和方法都借助于 TAPD 实现落地。小结一下我们在不同阶段使用 TAPD 的功能如下图所示：  随着业务系统越来越复杂，对测试人员和质量体系的要求也会越来越高，我们需要持续 !!!#ffff00 探索研发效能的统计度量以及敏捷研发和 DevOps 的整合之道，使开发、运维、质量管理实现真正的一体化。!!! 相信这个过程也不会缺少与 TAPD 的密切合作。 近期，我们的 PMO 团队设计了基于 !!!#ffff00 TAPD API!!! 的初版PMO系统，目前主要统计产出和延期率，期望给各Team Leader提供一些数据展示和数据分析。比如一个迭代究竟接多少项目需求、多少日常需求才是合理的？我们会计算已完成项目和日常的平均人日，和每个迭代的项目和日常个数以及到期完成情况供各Team Leader作为参考。此系统目前还不完善，我们也在逐步优化中。  另外，我们还会将 TAPD 和大交通内部 DevOps 平台打通，实现业务、开发、运维、质保的全流程自动化。 最后，感谢 TAPD 这款工具及官方团队给予我们的支持，希望在未来更加深度的合作中，马蜂窝和 TAPD 都能为更多团队的研发效率和项目质量提供更多更好的经验。
