一件重要的事情，就是明确并敲定每个特性的owner，我们称之为Feature Owner。
因为我们项目也是一百多人，但具体参与的项目经理只有1.5人，也就是说，我们没有那么多项目经理。这个时候就要考虑采用FO制度，来填补项目经理，承担一部分项目经理的工作。那这个FO主要是由核心团队成员和项目经理来承担。
FO的主要职责可以参考下，当然远不止这些，如果FO项目管理意识或能力很强，可以承担更多。项目经理则只需要管理好FO就可以了。
沟通对齐详细规划之后，会上还需要沟通对齐和资源相关的事项，也就是当前版本下所涉及到的美术资源，这些资源的完成时间是怎样的，是否会存在严重的资源瓶颈？是否会对整体的版本效果带来影响？都需要在这个会上明确。
4、输出版本发布计划
当整体规划，资源情况，FO人员都确定之后，各特性FO和各系统模块负责人则会评估详细的工作量，在这期间，项目经理需要先全员同步整个团队。
这个同步的信息包括：版本主要目标、整体安排思路、发布规划的内容、可能的风险和应对计划。
项目经理一定不能忽略这个项目整个规划信息的同步，这本身也是属于项目可视化的一部分。一个版本的规划做好之后，是需要全员同步到团队的。
让整个团队成员都清楚当前版本的主要目标、规划内容、安排的思路，以及可能的风险和应对计划。这会有利于整个版本计划的推进。
这个信息的同步，我通常都是用邮件的形式发出来，然后在项目大群里面周知大家。通过多个渠道把信息同步好。
当各特性线具体的系统功能时间评估出来之后，项目经理在此基础上，刷新同步整个版本的计划。让项目团队成员都清楚地知道，这个版本是要做到什么时候完结。
5、执行版本计划
版本真正开始落地执行的时候，是一个持续交付的过程，我们是采用流水线分支开发的模式，参考如下图：
什么是流水线分支开发模式？
我们每个版本划分好特性线之后，就会在同一的基线下，每个特性都独立从主干上拉一个分支，作为特性线分支，在该特性线分支下，则独立开发各个系统功能模块。
这样做的好处就在于，可以有效地避免特性之间的干扰，避免开发过程中，因为人为因素，因为环境因素等导致开发进程受阻。当然合版本也会带来一定的成本。所以关于开发模式，没有最好，只有是否真在的合适自己所在的项目。
那么当特性A开发完成之后，我们就会按照计划时间，交付分支版本给到策划和美术进行验收，并进行体验问题的修改；同时并行的还有开发侧本身提交代码review（code review）
体验问题修改完成之后，在合并主干之前，需要先将主干代码合入到特性A分支来，并解决相应的冲突，做好自测及验证，确保主干合入到特性A分支来是稳定的，不会影响到主干原有的功能。
在体验问题，CR问题都修改完之后，就会正式提交合并请求，合并回主干，输出版本给到测试对功能进行测试。
这里还有一步是可选的，就是看功能影响面大小，如果评估影响面很大，则会安排先进行冒烟测试，把相关的问题解决完之后，再提交合并主干。
对于其他各条特性的完成情况，也是如此的做法。当然也还有一种特殊情况，就是当出现两个特性同时完成怎么办？这里有一个原则，就是明确先后顺序，确定谁先合，谁后合，切记两条特性线独自拉主干合入分
