这一篇继续来分享敏捷实践下的版本管理。
三、版本循环
版本循环是敏捷实践下的重要一个环节，项目的持续交付，就是按照一个个版本来进行交付的。
1、明确版本范围
在做全局规划的时候，项目经理需要把一个项目拆分成多个阶段来进行，也即所以需要把一个大项目，拆分成多个版本来进行管理。参考如下图：
但初步的全局规划，是一个整体的规划，真正要落地的时候，必须要明确每个版本的规划。
在每一个版本正式启动之前，项目经理需要组织项目的核心管理团队开需求范围对齐会议。
这个会非常之重要，范围的确定，直接关系到版本目标的对齐，整体资源的调配。项目经理需要邀请项目核心管理成员一起参加（以我们项目为例，范围对齐会议的主要人员包括：项目制作人、项目管理副总监、主策、主程、主美、项目经理、测试经理）。
需要再次特别说明的是，这个会议的目的就是核心管理团队一起对齐明确，当前这个版本要做的内容，也即明确范围。
2、进行详细的规划
范围明确了，才好进行更详细的规划，这也是开范围明确会议的重要目的。
当范围明确之后，项目经理需要和主程一起对每个功能进行评估和分析，并且考虑考虑需求的依赖关系、耦合度强弱等，这个目的在于更好的对特性进行划分，比如有一些功能依赖关系、耦合度强，则需要放到同一个特性线来开发，而有些功能就相对比较独立，则可以划分到另外的特性里面。
前面我们有介绍，我们是按照流水线分支开发的模式，每条特性线都是独立开发，所以，我们才需要对已经明确的功能再次进行有机的划分，减少特性与特性之间的耦合，从而更有效的加快整体的进度。
在划分好特性线之后，对于每个功能来说，可能都会涉及到不同领域的人参与，所以需要进一步和主程一起确定每个特性下功能模块的前后台开发人员，以及和其他leader确认对应的策划、美术、测试人员。
同步进行的是，主策（包括各系统功能策划的负责人），则需要和主美对齐各特性功能的美术资源需求情况，需要把当前整个版本所涉及到的美术资源都梳理给出来，并且评估好时间。
美术资源分为（UI、动效、原画、3D角色、3D场景），UI的输出时间是需要绝对匹配整个版本节奏的，否则会对整个版本进程有影响。整个绝对匹配是指的，在每个系统功能正式开发之前，UI资源都需要提前到位。
这也是我们做全局规划时的一个重要目的，全局规划做好之后，会给出需求相应的输出时间节点，以便美术先行，提前准备好。
3、版本规划确定会议
当详细规划做好之后，项目经理会发起第二个重要会议，就是版本规划确定会议。
这个会的主要目的就是和核心管理团队一起确定当前这个版本最终要做的内容，以及每个特性的划分是否合理。
为什么要再次和核心管理团队开这个会议，这也是我们项目的一个特点，因为资源是有限的，我们在对齐范围的时候，只是根据人员投入的情况进行的一个预估，认为是可以做完这些功能点，但详细规划之后，会出现两种情况，一是原范围做不完，这个时候会议上就要讨论删减掉哪些需求；还有一种情况就是需求规划的不够，则需要考虑新增一部分需求。
除了需求范围的再次明确以及细节的确定，在这个会上，还有一件重要的事情，就是明确并敲定每个特性的owner，我们称之为Feature Owner。
因为我们项目也是一百多人，但具体参与的项目经理只有1.5人，也就是说，我们没有那么多项目经理。这个时候就要考虑采用FO制度，来填补项目经理，承担一部分项目经理的工作。那这个FO主要是由核心团队成员和项目经理来承担。
FO的主要职责可以参考下，当然远不止这些，如果FO项目管理意识或能力很强，可以承担更多。项目经理则只需要管理好FO就可以了。
沟通对齐详细规划之后，会上还需要沟通对齐和资源相关的事项，也就是当前版本下所涉及到的美术资源，这些资源的完成时间是怎样的，是否会存在严重的资源瓶颈？是否会对整体的版本效果带来影响？都需要在这个会上明确。
4、输出版本发布计划
当整体规划，资源情况，FO人员都确定之后，各特性FO和各系统模块负责人则会评估详细的工作量，在这期间，项目经理需要先全员同步整个团队。
这个同步的信息包括：版本主要目标、整体安排思路、发布规划的内容、可能的风险和应对计划。
项目经理一定不能忽略这个项目整个规划信息的同步，这本身也是属于项目可视化的一部分。一个版本的规划做好之后，是需要全员同步到团队的。
让整个团队成员都清楚当前版本的主要目标、规划内容、安排的思路，以及可能的风险和应对计划。这会有利于整个版本计划的推进。
这个信息的同步，我通常都是用邮件的形式发出来，然后在项目大群里面周知大家。通过多个渠道把信息同步好。
当各特性线具体的系统功能时间评估出来之后，项目经理在此基础上，刷新同步整个版本的计划。让项目团队成员都清楚地知道，这个版本是要做到什么时候完结。
5、执行版本计划
版本真正开始落地执行的时候，是一个持续交付的过程，我们是采用流水线分支开发的模式，参考如下图：
什么是流水线分支开发模式？
我们每个版本划分好特性线之后，就会在同一的基线下，每个特性都独立从主干上拉一个分支，作为特性线分支，在该特性线分支下，则独立开发各个系统功能模块。
这样做的好处就在于，可以有效地避免特性之间的干扰，避免开发过程中，因为人为因素，因为环境因素等导致开发进程受阻。当然合版本也会带来一定的成本。所以关于开发模式，没有最好，只有是否真在的合适自己所在的项目。
那么当特性A开发完成之后，我们就会按照计划时间，交付分支版本给到策划和美术进行验收，并进行体验问题的修改；同时并行的还有开发侧本身提交代码review（code review）
体验问题修改完成之后，在合并主干之前，需要先将主干代码合入到特性A分支来，并解决相应的冲突，做好自测及验证，确保主干合入到特性A分支来是稳定的，不会影响到主干原有的功能。
在体验问题，CR问题都修改完之后，就会正式提交合并请求，合并回主干，输出版本给到测试对功能进行测试。
这里还有一步是可选的，就是看功能影响面大小，如果评估影响面很大，则会安排先进行冒烟测试，把相关的问题解决完之后，再提交合并主干。
对于其他各条特性的完成情况，也是如此的做法。当然也还有一种特殊情况，就是当出现两个特性同时完成怎么办？这里有一个原则，就是明确先后顺序，确定谁先合，谁后合，切记两条特性线独自拉主干合入分支，再一起合回主干。这样做，会导致整个版本冲突很大，对整个版本的质量稳定带来很大影响。
与分支流水线一起规范的就是下面的这个流程，尤其是提交合并主干的时候，有专人进行CR和最后的确认。
此外，在版本执行的时候，我们也是有严格定义版本的达成目标的，而且涉及到具体的细节定义，每个版本都需要按照这个目标来完成。
6、版本回顾会议
在每个版本结束之后，我们会召开全员版本回顾会议，并进行总结。总结回顾会议的主要要点包括：
1）整体版本演示
这一项是策划负责人，将我们整个版本做的需求和功能，在大会上进行全员展示并进行不同程度的解说。通过演示真切的告诉团队，我们整个版本做的具体的事情，这也是成果的展示。
因为在版本开发的过程中，可能很多团队成员都是一直在忙自己所负责的事情，这个演示会的目的就是让团队成员整体感受当前版本的完成情况，也是向项目团队展示整个版本周期的成果。通常15-20分钟左右的演示。
2）版本数据展示
这一部分则相对比较客观，是项目经理和团队成员展示当前版本的一些客观的数据，包括版本需求的完成情况、自测通过率、bug修复率等等。
3）产品的规划和想法
在项目经理介绍完当前版本的完成情况之后，主策会把项目下一个阶段的规划和想法和项目团队全员同步，主要目的是从产品侧给团队信心。如果这期间因为政策，因为市场的变化，产品的一些规划或者目标有变化，还会在大会上进行解释说明。
4）技术和美术专项
这一部分则是主程和主美分别对各自己所负责的领域，和团队介绍过程中的一些重难点，实现方式，也包括一些制作方式，让团队成员也清楚一些工作的完成情况。这一部分则相对会偏专业一点。
5）目标回顾（更新）
如果目标没有更新，则大会上再次和大家同步并强调目标以及关键时间节点；如果目标有更新，则同步更新的目标，并说明情况。既要说明what to do，也要说明why to do。
6）复盘总结
复盘总结则会根据实际版本的情况，进行整体的回顾，分特性小组进行讨论，主要侧重点则是当前版本下，哪些是做的好的，哪些是需要持续改进的。
过程中一些不好的方面，主要的原因是什么，有什么改进措施，并且最后形成纪要，以便在下一个版本的时候更好的优化和实践。
本文来自公众号：项目管理跃迁（ID:xmglyueqian），
作者：徐州，鹅厂项目经理一枚，PMP，PRINCE2，专注于分享日常项目管理过程中的点滴，辅以分享职业成长的思考与感悟。著有《谁说菜鸟不能成为项目经理》一书。
授权发布于管理圈，如需转载请联系原作者。
粤公网安备 44010602010970