一、背景
移动互联网行业中，为了应对市场环境和竞品的竞争压力，为了快速满足海量用户的多样化需求，同时当业务团队规模扩大到一定程度（如50人以上）时，会遇到许多影响团队协作和业务交付效率问题（如需求各方PK、各方步调与节奏不一致、关联配合协调困难、职能墙的困扰、bug后期爆发、hotfix与patch多、等）。
如何提升大业务团队的快速交付能力，就成为了非常重要和急需解决的命题。下面以UC浏览器和九游大业务团队为例，以班车模式为核心来阐述打造大业务团队快速交付能力的模式与关键实践。
二、快速交付模式
总关键词：
统一业务目标与发布节奏
业务、技术与团队解耦
团队协作规则
工程化与工具支撑
关键说明：
1、统一业务目标与发布节奏：
定期（季度、月）拉通各业务方进行业务目标和重点的规划，并分解到版本，确定每个版本的发布发布节奏。达到大业务团队聚焦业务目标和价值，步调统一和协同作战之目的。
2、业务、技术与团队解耦：
A、按特性来进行业务解耦，把大产品分解成多个相对对立的特性功能。
B、从系统架构出发，将大系统分解成多个相对对立的模块。
C、按特性来组建特性或专项团队，把大团队拆分成多个由产研测组成的敏捷小团队，每个敏捷小团队人数控制在10人左右。特性团队长期打磨某个独立功能，专项团队则更多是组织精锐攻关解决TOP重点问题。
通过业务、技术与团队等维度的解耦，达到降低系统复杂度、减少互相关联与干扰、降低沟通和协作成本，确保各特性团队和专项团队能（相对）独立各自快速迭代与交付。
3、大团队协作规则：
A、各特性团队和专项团队各自分支独立规划、迭代和交付：大需求按业务场景拆分成独立小需求，分支上完成后分批回trunk；小需求分支上完成后可及时回trunk。
B、各特性团队和专项团队匹配班车发布节奏：需要发布的需求依据主线班车迭代计划来做上班车的匹配。大需求和基础模块改造需求（比如研发工作量超过10人天）回trunk的计划时间点最好比主线班车版本分支开出时间点早1-2个工作日，以便应对风险和降低赶不上班车的几率。
C、需求提交到trunk的质量要求：大需求和基础模块改造需求（比如研发工作量超过10人天）需要在分支上完成内测与灰度，产研测项目综合评估通过后才能提交到trunk。各专项可招募各自的粉丝用户参与产品需求交流和内测等活动，和用户交流互动，及时获得和更好满足用户的真实需求，及时收集到用户反馈的问题和建议，并及时做修复和处理。
D、分支灰度策略和要求：分支上发灰度时需要在最近发布的稳定版本基础上进行。
4、工程化与工具支撑：
为了保障交付的效率和质量，需要逐步提升团队工程化和工具化能力，如持续集成和UI自动化测试、稳定性自动化测试、一键提测和发布系统等。
三、实施阶段与效果
在UC浏览器和九游游戏大业务团队快速交付能力打造过程中，按初始、稳定、持续优化三个阶段推进和实施。
1、初始阶段
当业务面临发布周期长、质量不高、大团队协作复杂等问题时，引入班车模式，重点是完成团队协作规则制定和团队建立，并快速的行动起来。
2、稳定阶段
大业务团队采用班车模式运作一段时间后，团队已逐步熟悉班车模式的运作框架、发布节奏等，但交付效率、版本质量、人员成长等还需要继续提升，此时需要快速总结并对重点问题进行优化。
3、持续优化阶段
快速交付模式已经过完善和优化，团队在交付效率、交付质量、团队能力成长等多方面都已成熟和得到了提升。此时引导团队做更多思考，确定新的目标和下一阶段优化重点，不断思考和探索，不断追求极致，持续提升交付能力。
目前UC浏览器大业务团队班车模式实施已经进入持续优化阶段，较好解决了早期发布周期较长、Patch较多、关联协作困难等问题，团队交付能力已得到大幅度的提高，正在探索随发模式。九游游戏在2015年中引入班车模式，班车模式基本运作顺利，在团队协作效率方面已取得初步成效，目前重点是提升班车交付质量和交付效率。
(本文于2016-03-19首次发布)
