最后一篇来分享敏捷实践下的迭代循环、适应变更、需求池和收尾。
四、迭代循环
迭代循环是指的在版本循环的时候，规划的每个大版本，这些大版本会拆分为不同的迭代来进行增量交付。
在实践中，我们项目组规划好的每一个beta版本，是按照特性线的模式，有机地分发至各特性线进行。
各特性之间，就是独立的流水线模式，哪个特性先完成，哪个特性就先合入主干进入到验收和测试环节。
在迭代循环，我们项目的整个全流程参考如下：
1、迭代评审
每个迭代，具体对应的需求在人员落实之后，则会开始拉起需求评审，通常是对应特性下的所有参与人员都需要参加需求评审会。
需求评审会主要目的就是需求负责人对需求进行宣讲，包括需求的设计目的、具体功能、模块划分、细节确认、美术相关等。
在需求评审完之后，如果涉及到可行性论证，则还需要邀请核心管理层参加，进行拍板决定。而后才分别是开发和美术对工作量进行拆分。
2、迭代（需求）评估
由于我们项目是有合作方一起参与的，所以在需求评估阶段，分为两种情况：
1）有合作方一起负责的需求，在需求设计方案和详细工作量评估输出的时候，需要合作方的负责人先审核确认，而后才是项目组负责人审核确认；
2）没有合作方一起负责的需求，则在需求设计方案和详细工作量评估输出后，项目负责人审核确认即可。
在详细工作量评估输出之后，会将相对应的时间填入我们的项目管理工具（TAPD），而后项目经理根据详细的工作量评估进行排期。
排期的时候，可以项目经理和FO一起排期。如果FO有这方面的能力也可以FO自己排期。
具体计划输出之后，我们会在特性群（企业微信）输出详细计划安排，包括但不限于：FO是哪位、晨会安排、各模块负责人、关键时间节点、主要问题或风险点、详细计划、需求链接。对于一些大的特性，我们还会邮件更新同步，并且同步到TAPD的指定位置。
3、迭代开发
计划输出之后，就正式进入到开发阶段了。
开发根据自己评估输出的时间，进行编码、自测、联调。在需求开发阶段，有几个特别需要关注的点：
1）对于有涉及到UI方面的需求，在开发联调自测结束后，需要拉起美术UI负责人在PC上先行验收，这样可以优先解决一部分很明显的美术体验问题。这个过程也是开发和美术先行验收美术效果。
2）在需求开发的同时，测试人员也会同步开始进行用例的测试，待测试用例输出后，测试负责人会拉起和开发、策划的用例评审，并且输出开发自测用例。
3）开发自测联调之后，就会开始跑自测用例。跑自测用例的目的是为了在输出产品验收的版本的质量稳定，全流程不出现卡点。也正是因为此，开发跑自测用例是版本交付验收的必要条件，且自测用例跑完并通过的比例是要超过90%。
4、迭代验收
开发自测通过之后，就进入到需求验收阶段。因为我们是分支流水线模式，所以先输出的是分支版本。
在分支版本输出之后，分别会有特性小组和美术人员一起安装APP版本进行验收。
与此同时，开发侧本身需要同步提交代码review（code review：CR）。
版本验收的时候，产品和美术会提相关的体验问题，开发人员则同步修改体验问题，以及CR的问题。
在确认体验问题和CR问题都修改完成之后，则会提交正式的合并请求。
这里需要特别注意：
如果当前特性是一个非常大的特性，对原有功能预判有比较大的影响的时候，在原主干版本合入当前特性分支的时候，还可以安排测试人员接入进来，参与冒烟测试，这样可以更进一步确保合入主干的版本稳定。
5、迭代转测试
在项目启动之初的时候，我们就有过约定，版本的正式转测试，都需要合入主干，统一一个版本，减少分支版本和主干版本的不一致性。
所以，在分支版本体验问题修改完成后，经过特性小组评估确定，验收通过，则会正式进入到转测试的环节。
开发人员在正式转测试的时候，除了要发转测试邮件，还需要写清楚转测试的内容，环境等。
6、迭代完结
我们的迭代完结，是以最后的bug修改，体验问题修改完为基准的。在版本循环的时候，我们有介绍，每个迭代的标准。所以，每个迭代的完成，是严格按照迭代的要求来进行的。迭代标准参考如下：
五、适应变更
VUCA时代下，变化才是唯一不变的。作为项目经理，在项目推进的过程中，需要更好地拥抱变化。
在实际的背景情况下，当项目规划制定好之后，当目标确认了之后，也还是会由于各种情况而发生变化。
在这样的背景之下，项目经理需要做的是保持平常心，保持积极、客观的应对心态，当出现变化时，当出现对目标有影响时，及时地进行调整和更新。
结合我自己负责的这个项目来看，总结了四个变更的维度，分别是：市场、政策 、内部目标、人员。
1、市场方面
对于互联网项目或游戏项目来说，是市场驱动型的项目。因此当市场出现变化，项目出现变更则是一件再正常不过的事情了。
作为项目经理，则需要具备敏捷思维，拥抱变化。要相信，变是为了更好。当然，项目经理也可以在此过程中更多的参与和了解项目的背景，产品的规划，以及多和高层管理者沟通，汇报，及时的了解到相关信息，以便更加快捷的应对变化。
事实上，在VUCA时代，更自如地应对项目中的突发情况，并且积极高效调整后快速推进，也是项目经理的一项重要能力。
2、政策方面
这点就非常好理解，关于政策方面，使得项目出现不同程度的变更。
这几年互联网，游戏的监管越来越进入深水区。长远来看，是为了着眼于未来更良性的发展。但政策方面的变化，必然也是会对项目的规划、目标带来影响。项目经理只需要按照相关政策要求，去进行调整即可。
客观的情况，无需特别的焦虑。但有一点，就是在允许的情况下，要尽量多和团队成员解释清楚，因为政策变化而带来的项目侧的变化。
3、目标本身
这点也是非常常见的，项目的初始规划或目标并不会一成不变，由于市场、政策等带来的变化，会导致目标有所变化。
但同时，项目侧内部既定目标，也会根据项目的实际情况而进行调整，这都是很正常的事情。
项目经理是需要重点关注目标的，但不能因为目标的变化而感到焦虑，积极的应对即可。同样也需要做好相关的信息同步，并及时刷新计划。
4、人员的变化
还有一种情况，就是项目在推进的过程中，有部分人员的变化，也会导致项目目标出现变更。
一个公司、部门或者一个项目组，资源都是有限的，如果出现更高级别或战略更高的项目，很有可能会大规模的人员抽调，这个时候对于原有项目来说，则一定是会受到影响的。与此同时，目标也会跟着变更。
这种情况下，项目经理要做的就是做好突发情况的应对策略，梳理已经完成和未完成的情况，做好人员陆续补充或者人员陆续回来的工作安排。
六、需求池
需求池更多的是指敏捷scrum方法论里面的产品待办事项列表。
需求池之所以要单独拿出来讲，是因为在具体实施的过程中，我们有不少项目经理会有某种误区，觉得需求只包含了产品需求。
其实真正的需求池，是包含三个方面的需求的：产品需求、美术需求和技术需求。
产品需求和美术需求都是明面上的需求，但技术需求，往往容易被忽略，比如性能的优化、工具的建设、基础框架的搭建、服务器的优化，还有其他和技术相关的需求。这些往往也是需要花费实实在在的时间的。
所以，如果项目中出现不同程度的delay，则需要好好的审视，项目中的需求安排，是不是遗漏了隐性的需求，导致工作评估和实际输出的不一致。如果是，那有必要在每个迭代计划制定的时候，把这部分隐性需求都纳入到正常的计划里面来。如此，计划的制定或许才会更加的合理。
七、结尾
收尾和正常项目过程无特别的差异化，主要的事项就是交付产品或成果、开展项目回顾会议、项目活动收尾、组织过程资产的整理、团建。
其中回顾会议，非常建议项目经理在每个版本完结的时候，带着团队一起进行迭代回顾。这是可以和特性小组一起提升经验的，包括这个过程中做的好的方面，做的不好的方面，或者是都讲一讲觉得开心的事情，觉得不开心事情，一些建议是什么等等。
组织过程资产，则是项目非常重要的积累和沉淀，这本身也是项目最初始到结束持续做的，最后项目结尾的时候，再对这些过程资产必要的整理，如果有可以提炼的则进行提炼和升华，这样也是组织的财富。
至于团建，则根据项目完成的实际情况来定，比如吃饭聚餐、出去happy等。一个项目的完结也可以让团队成员共享项目果实。
本文来自公众号：项目管理跃迁（ID:xmglyueqian），
作者：徐州，鹅厂项目经理一枚，PMP，PRINCE2，专注于分享日常项目管理过程中的点滴，辅以分享职业成长的思考与感悟。著有《谁说菜鸟不能成为项目经理》一书。
授权发布于管理圈，如需转载请联系原作者。
粤公网安备 44010602010970