敏捷项目管理概述及应用实践

本文内容结构

1、认识敏捷

（1）敏捷宣言

（2）敏捷4个价值观

（3）敏捷12项原则

（4）敏捷的定义

2、传统与敏捷方法论

（1）传统软件开发方法论

1）管理方法

2）适用场景

3）开发模式

（2）敏捷方法论

1）敏捷方法论概述

（3）传统和敏捷的比较

（4）敏捷的使用范围

3、敏捷项目管理概述

(1)敏捷项目管理定义

(2)项目管理架构

(3)敏捷团队和成员

(4)仆人式领导

(5)组建高效能团队

4、敏捷项目管理实践

(1)立项

1)设置激动人心的目标

①重要性

②明确性

③挑战性

2)论证项目的价值

①项目是否值得做

②项目团队是否有能力交付

③项目能实现收益

3)做出MVP

①打靶法确定最小范围

②投入最少的人力资源，快速开发

③团队内部确认MVP

④向高层汇报

(2)启动

1)搭建项目管理体系

①识别干系人

②搭建团队组织架构

③建立沟通体系和机制

a、核心管理群

b、工作统筹群

c、 项目研发群

d、项目特性群

e、功能模块群

④搭建知识共享平台

2）做好项目全局规划

①梳理需求框架

②明确需求优先级

③进行项目全局规划

④制定整体里程碑计划

3）明确版本管理流程

①规范项目研发流程

②明确版本开发模式

③明确版本合流流程

④推动落实工具建设

4）开好项目启动大会

①做好全员信息同步

②对齐项目目标

（3）版本循环

1）明确版本范围

2）进行详细的规划

3）版本规划确定会议

4）输出版本发布计划

5）执行版本计划

6）版本回顾会议

①整体版本演示

②版本数据展示

③产品的规划和想法

④技术和美术专项

⑤目标回顾（更新）

⑥复盘总结

（4）迭代循环

1）迭代评审

2）迭代（需求）评估

3）迭代开发

4）迭代验收

5）迭代转测试

6）迭代完结

（5）适应变更

1）市场方面

2）政策方面

3）目标本身

4）人员的变化

（6）需求池

（7）结尾

互联网行业有一种说法，叫做“敏捷已死”。事实上，不是敏捷已死，是很多项目用着用着就偏离了敏捷的思想和原则，甚至走入了误区，不仅没有发挥敏捷本身的效用，更是给组织，给项目带来了很大的困扰。

今天，就个人的理解，来聊一聊用敏捷思维做中大型项目。

之所以说是用敏捷思维，是因为，敏捷思维其实在我们的工作生活中无处不在的。比如最常见的，我们去餐厅吃饭，我们点了10个菜，餐厅是一个菜一个菜持续交付的，并不是等到10个菜全部做完后才统一上菜。这个过程中，也经常会出现，更换其中的某个菜，或者退掉某个菜。那餐厅要服务好客户，就得拥抱变化，合理满足。

而我们实际开展一个项目，大多数的时候并没有真正套用敏捷的某个方法论，比如最常用scrum方法论（占有率66%：数据来源于2021年7月发布的敏捷报告）。

那么在正式开始介绍用敏捷思维做中大型项目管理之前，我们还是先认识一下什么是敏捷。

1、认识敏捷

（1）敏捷宣言

敏捷宣言诞生之后，其包括4个价值观和12条原则，以及一系列的敏捷实践。

敏捷是一种心态，这是敏捷的核心，是一种基于敏捷价值观、原则及实践的心态或做事的思维哲理。

所以，从这个维度来说，敏捷并不是某种特定的方法论、过程、架构或工具。

敏捷真正告诉我们的是要以敏捷心态、敏捷思维来做项目，做事情。

（2）敏捷4个价值观

我们知道敏捷宣言包括敏捷4个价值观：

个人与互动胜于过程与工具

可用的软件胜于复杂的文档

与客户协作胜于合同谈判

响应变更胜于遵循计划

我们可以看到这其实是分成了左右两部分，右边的过程与工具、复杂的文档、合同谈判、遵循计划，也是有价值的，但相比较而言，左侧的个人与互动、可用的软件、与客户协作、响应变化则更有价值。

（3）敏捷12项原则

敏捷12项原则。

原则指导行为。其他的都可以裁剪，唯独原则不能裁剪，可见原则的重要性。

也就是说，要运用敏捷，就需要遵循这12项原则。

1）我们的第一优先任务是，通过尽早且持续交付有价值的软件来满足客户。这是使用敏捷的目的，尽早交付、持续交付，让客户满意。

2）即使在最后开发阶段也要竭诚欢迎改变需求，敏捷过程掌控改变，以维护客户的竞争优势。我们的态度就是拥抱变化。尽管尽早交付，持续交付可以降低风险，但也很难预测未来，当发现按原计划执行下去的时候无法替客户创造价值，就要欢迎改变，团队拥抱变化。

3）经常交付可以的软件，频率可从数周到数月，以较短的时间间隔为佳。关注的重点是交付客户需要的软件，所以，尽早且频繁的交付，交付频率1-4周，最好不超过6周。

4）业务人员与开发者在项目进行中，必须每天一起工作。合作共赢，业务人员和开发者在项目进行中时，可以频繁的沟通，通过共享彼此的想法、文档和解决方案，对齐目标和需求。

5）项目靠积极的个人来完成，给予他们所需的环境支持，并相信他们可以完成工作。核心还是人。要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。项目成功最重要的因素是人。

6）在开发团队与团队成员之间，面对面的沟通是传递信息最有效率与效能的方式。最优效的沟通，是面对面。所以，敏捷团队大都是集中办公。

7）可用的软件是进度的主要测量标准。衡量进度的标准就是交付可用的软件。

8）敏捷过程提倡稳定持续的开发，发起人、开发者及用户都应该能不断地维持稳定的步调。虽然我们的态度是拥抱变化，但并不代表着可以随时随地的进行变更。项目方、开发人员和用户应该能够保持恒久稳定的步调，持续交付可用的增量成果，既不过渡疲劳，也不过渡空闲。

9）对技术的精益求精以及对设计的不断完善将提高敏捷性。所有团队成员都应持续专注于追求卓越，团队协同工作的平台和工具也都要随着时代的演进和精进，让团队更有效率和效能地完成项目。

10）简洁，即尽最大可能减少不必要的工作，这是一门艺术。根本的原则是简洁，不做过渡和华而不实的设计。比如我们很多电视的遥控器，其实大部分功能是没有用的，你看看小米的电视遥控器，就几个主要按键。

11）最佳的架构、需求和设计将出自于自组织团队。敏捷团队是自组织团队，团队成员共同解决项目中所有问题，每个成员都具有项目所有方面参与权，共同承担职责。

12）团队要定期反省怎样做才能更有效，并相应地调整团队的行为。敏捷团队是要不断的改进开发成果的方式，复盘总结经验。

（4）敏捷的定义

前面我们介绍了敏捷的核心，4个价值观和12项原则，那我们给敏捷下一个定义。

敏捷是适应“互联网+”时代的一种思维方式，是一种心态，一种基于敏捷的价值观原则跟实践的心态，或者是做事情的思维哲理。

敏捷是创造并响应变化，从而在动荡的商业环境中创造利润的能力•敏捷是平衡灵活性和稳定性的能力。

敏捷不只是交付（产品/功能），而是发现（价值）

所以，我们常说的敏捷不是流程，也不是方法，而是一种适应时代需要的思维方式，是一种为产品创造最高价值的心态。

2、传统与敏捷方法论

（1）传统软件开发方法论

传统软件开发方法论，通常指的是预测型，是属于完全计划驱动型生命周期。

1）管理方法

•早期完整计划，可使用滚动式规划

•顺序或交叠的按计划进行

•各阶段工作有不同的性质

•各阶段项目团队结成与所需技能不同

2）适用场景

•适用于充分了解拟交付的产品

•行业实践基础厚实

•整批一次性交付产品有利于相关方

3）开发模式

传统软件开发模式是一种瀑布式的模式，从下图也可以很好的理解。

（2）敏捷方法论

1）敏捷方法论概述

我们所熟知的敏捷方法论，包括scrum、XP、看板、精益、水晶、DSDM等

其核心价值大都是客户导向、价值导向、消除浪费等。

（3）传统和敏捷的比较

传统项目是铁三角，范围、时间、成本，包括质量，组成了四要素。

下图左边的三角形。传统项目是以计划为导向的。

而敏捷项目三角是价值、质量、约束。如上图右边的三角形。

价值：可发布的产品

质量：可靠、适应性产品

约束：成本、时间、范围

考量指标是价值（向客户交付价值）

质量（需要向客户交付可持续的价值）

约束（范围、进度和成本）。约束仍然是重要的项目参数，但不是项目的目标。在敏捷中，价值才是目标。

为了提升客户价值，这几个约束可以随着项目的进展适时作出调整。进度可能仍然是一个固定的约束，如果是那样的话，范围就可以调整为在固定的时间期限内向客户交付最有价值的产品。如果要有适应性，就必须牺牲或调整一些约束为代价来实现价值或质量目标。

再举个例子来说明下，传统和敏捷的比较：

比如传统开发为期一年的项目，下图已经比较形象的展示出来了，项目从启动之后，需求准备，设计，开发，测试，到最后发布，或交付给客户都是将所有的事情做完之后才到下一步。这样一来，会大大增加最后交付产品的风险。

而采用敏捷思维，开发为期一年的项目，参考如下图，从项目启动之初，就是持续的交付，每次交付优先级最高，价值最高的系统，然后获取客户的反馈，并根据商业价值调整待办列表（或者是优先级）。过程中，如果有不满足客户需求的，就及时沟通调整，最终到项目收尾的时候，交付让客户满意的项目。

更详细的说明，在PMBOK指南第6版里面是有详细介绍的，参考如下图：

（4）敏捷的使用范围

3、敏捷项目管理概述

(1)敏捷项目管理定义

敏捷项目管理提供以人为本的项目管理方式，核心概念就是主管以“仆人式领导”方式，与一群被充分“授权”的团队完成项目目标，充分地将人的时间、精力、金钱集中在对组织及客户最有价值的部分，并以风险最小及自我组织的方式完成令客户满意的成果。

敏捷项目管理是紧盯愿景和目标而不是紧盯计划

敏捷项目管理是以价值驱动的项目管理

•这两点非常重要，敏捷项目管理是紧盯愿景和目标，而不是计划；是以价值驱动的。

什么叫做紧盯愿景和目标，而不是计划。

举个例子简单说明下：可能过去大多数的时候，是每天和团队成员去校准计划，让团队成员发日报，结果导致团队的效率和完成度没有得到提升，反而不断的下降。

在使用敏捷思维做项目的过程中，是追求效率和效果的平衡的，更加注重以人为本。事情的背后都是由人而完成，我们不能忽视人的因素。人应该是项目进程中最大的风险之一。

如果一个目标和计划制定好之后，项目经理每天去校对计划，不仅起不到监控的效果，反而会引发各种抵触。

因为谈到和人有关，事情在执行的过程中，某某同学今天状态好一点，可能就做的多一点；而某某同学今天状态不好，可能当天的计划不一定能够达成。这个时候如果是校准计划，势必会给这位成员带来很大的紧张感和压力，长此以往，心理的压力会更大。

因此，使用敏捷思维做项目时，就要调整之前校准计划，改为校准目标。也就是说，当计划制定好之后，和团队成员达成共识，在某个时间节点，需要完成哪些工作，达成怎样的目标，这些清晰传达给团队成员之后，项目经理重点关注的就是这个目标达成情况。至于今天是多做一点，还是明天少做一点，由团队成员自己决定。

当然，我们是相信团队的，但必须要去核实。所以，如果是时间周期比较长的目标，项目经理可以通过设置一些关键里程碑来进行核实，同时重点关注关键路径的完成情况，以及最大风险等多个维度，来综合监控目标达成情况。而且还可以和团队建立必要的规则，出现问题或者遇到困难时，要第一时间上报。

(2)项目管理架构

这个敏捷项目管理架构是许秀敏博士提出来的，她结合了吉姆·海史密斯提出的敏捷项目管理模式结构，和麦克斯·格里菲斯提出的敏捷通用过程。

吉姆·海史密斯提出的敏捷项目管理模式结构是：构想-推演-探索-适应-收尾。感兴趣的同学，可以去看看他写的敏捷项目管理一书。书中有详细的介绍。这本书也是ACP考试推荐书之一。

麦克斯·格里菲斯提出的敏捷通用过程是指：可行性研究-启动-发布规划-迭代-收尾，5个过程。

这个敏捷项目管理架构设计旨在协助团队聚焦于将项目的商业价值最大化，是基于价值分析和分解的项目管理，也就是价值驱动的项目管理。关于这点，去年最新出版的PMBOK指南第7版也同样是以价值为导向。

团队在项目进行的过程中，所做的任何工作都要遵从项目愿景，为客户与敏捷团队所属的组织创造最高价值。过程中，运用敏捷建模、根据商业价值排序、发布循环和迭代循环来持续交付有价值的成果以达成项目目标。

有区别于PMBOK的五大过程管理组，敏捷项目管理阶段分为：立项、启动、发布循环、迭代循环、收尾5个过程。这5个过程其实是更详细的阐述了PMBOK里面提到的渐进明晰的具体做法。

比如项目一开始的时候，只做大方向的计划，不做详细的需求分析，而是了解初步需求，做出整体高阶计划后，然后采用小步快跑的方式，在很短的时间内就进行一次发布。项目包含多次发布的循环，以可持续性的脚步，持续维持相同的团队节奏或速度，每次发布都会将当次发布工作所产生的增量成果或产品交付给客户，并尽快获得客户的反馈，修改这次的产品，以便修改后面的计划。

每次的发布又会分为多次迭代的循环，每次迭代约为1-2周，经过几次迭代，发布内的所有迭代完成后，产出当次发布的增量成果，就可以在最后一次迭代将增量成果交给客户，当所有的发布都完成时，项目就完成了。

在每次发布开始的时候，才做当次的发布计划，发布增量成果完成后则进行回顾，看看团队在当次发布期间，哪些做的好，哪些有待改进，有哪些需要开始做，哪些需要停止做，以此作为团队在下一次发布时的改进依据。

同样，对于迭代也是如此，每次迭代结束后，也审查与回顾迭代做的好与不好的地方，持续进行改进。

(3)敏捷团队和成员

敏捷团队包括三个重要角色：PO、SM和DT，通常是5-9人组成。7±2

敏捷团队有几个特点：

1）团队包含交付产品增量所需要的技能

2）团队都是T型人才，团队成员都是多面手---这点其实挺难的

3）团队成员是全职工作，是责任制

但实际上，我们的项目团队是下图这样的架构，是属于弱矩阵的。

也正是因为组织架构的原因，项目经理是没有办法去改变本身的组织架构的，这个时候，为了更加适应敏捷开发，项目经理就需要根据项目和团队的特点，搭建有利于项目快速推进的项目组织架构。

(4)仆人式领导

“仆人式领导”的理论来源于美国管理学家罗伯特·K·格林里夫（Robert K.Greenleaf，1904—1990）的无私的领导哲学，此类领导者以身作则，乐意成为仆人，以服务来领导团队。

仆人式领导鼓励合作、信任、聆听以及有道德地使用权利，有的时候仆人式领导不一定拥有正式的领导职位，但是也可以领导其他人。

敏捷才有仆人式领导，项目管理计划书不再是由项目经理规划好之后，将工作包分派给工作人员的模式进行，而是运用快速迭代等积极的做法，拥抱变化，进行团队激励与团队合作，才能做出最深度契合用户需求的产品。

仆人式领导者必须从解决问题转换为提倡授权，帮助团队成员成长和帮助他人解决实际的问题。

也就是说仆人式领导要从以往的命令和控制式转向支持型，为团队提供实际的支持，以便帮助团队达成项目目标。

(5)组建高效能团队

敏捷团队是自我组织的团队，要想组建高效能的敏捷团队，在项目初期，就要先建立团队规范，以协助团队高效运转。

所谓的团队规范，通常是指团队针对特定的项目，大家共同制定一套工作协议，并一致同意用此工作协议，规范他们相互期望的行为。

那我们有必要了解团队的组建过程，这个团队组建过程，是由心理学家布鲁斯·塔克曼提出的，从建立团队到形成高效运作的团队，会经历组建期、震荡期、规范期、执行期和解散期。

关于组建高效能团队，从我个人的理解来看，真正要打造一个高效能的团队，打造一个自组织团队，是非常难的一件事，这需要天时地利与人和，而且需要一个真正成熟的团队。但或许正因为此，是项目经理不懈努力的目标之一。

因此，我们需要学习了解塔克曼理论，来助力我们更好的去组建高效能团队。

塔克曼里面告诉我们，团队组建在不同的时期，团队的状态和团队的工作绩效都是不一样的。

那么在不同的时期，项目经理，或敏捷教练，所提供的支持是不一样的。

这里分享大家四句话：

组建阶段：不用讨论，项目经理决定。项目经理示范。

震荡阶段：团队成员讨论，项目经理决定。项目经理引导。

规范阶段：团队成员讨论，团队成员决定。项目经理鼓励。

执行阶段：不用讨论，团队成员决定。项目经理授权。

4、敏捷项目管理实践

敏捷项目管理实践，是以一个实际的项目来和大家分享下，我是怎么运用敏捷思维来做项目的。

因为当前这个项目还在研发期，也处于保密期，所以更详细的信息也不便于透露，只能说下，我们的团队规模是100+。一旦涉及到百人团队，整个管理就要成体系化。

因为项目经理这个时候凭借一己之力，是没有办法去很好的管控的。这个时候，就需要搭建框架和赋能，让团队可以被赋能在框架之内运转。

因为一直在讲的是运用敏捷思维做中大型项目，所以我们团队其实并没有完全的使用敏捷的某种方法论。

根据我自己的理解和团队实际的情况，我总结梳理了下我们项目的整个项目管理过程，分为立项-启动-版本循环-适应变更-迭代循环-收尾。

接下来就来分别介绍一下，每个过程应该怎么做。

(1)立项

关于立项，分两种情况来说：

第一种情况，未参与立项过程，直接接到老板分派的项目。

这是非常常见的一种情况，我们很大一部分项目经理并未实际的参与立项，大都是接到老板/领导安排的一个项目，就开始正式启动了。因此这里先聊一聊，这种情况下，项目经理专业的做法是怎样的。

项目经理在开始负责一个项目的时候，不是一上来就开始着手安排工作的，更不要接到项目时，和老板讨价还价，或直接拍胸脯说什么时候做完。

而应该是在项目正式启动之前，需要花大量的时间去详细了解项目的背景。作为项目经理，必须要清楚自己负责的项目是一个怎样的项目，这点非常关键。

当了解清楚项目的背景之后，只能说项目经理对项目是有了一个清晰的认知。这个时候，还需要和管理层去对齐预期。当然，因为项目一切都才刚刚启动，这个预期初始是不准确的，但为什么还需要去对齐。

这是因为，项目经理需要清楚的知道，部门或公司，以及管理层为什么要花这么多成本去做这个项目，他们的期望是什么？这些期望包括但不限于：做这个项目的真实目的；战略目标；第一个demo版本时间；阿尔法和贝塔版本的重要里程碑；最后上线的时间。等等。

当详细了解清楚了项目的背景和管理层的预期之后，这是有助于我们更好的去制定目标，并且在制定详细规划和执行时有的放矢。

所以，对于第一种情况，未参与立项阶段，项目经理专业的做法就是要花大量的时间，去详细了解清楚项目的背景、老板为什么要做这个项目、核心管理层的预期是什么，然后根据获取的这些信息，梳理给出整体的规划和目标，再和项目核心管理层沟通对齐。

第二种情况，有机会参与到整个立项的过程。

当项目经理有机会参与到立项的整个过程时，要清楚的知道，立项的整个过程，三件大事：设置激动人心的目标、论证项目价值（商业论证），还有做出MVP版本。

1)设置激动人心的目标

目标设定被认为项目成功的关键因素。激动人心的目标能让项目团队了解产品的价值，建立共同的方向并激发团队士气。

换句话说，从公司到部门，到项目发起人，到整个项目的核心管理层，都需要理清楚，为什么要投入成本做这个项目。

那么对于目标的设定，有三个重要衡量要素：

①重要性

这是来自组织的要求。体现在为客户创造价值。为客户创造价值，回答的是我们的关键客户/用户是谁？我们为客户/用户提供什么样的价值主张？价值主张就是客户/用户选择我们而不选择其他人的原因。对于产品或项目来说，就是产品或项目的核心卖点或竞争力是什么？

公司，部门，到项目组，投入成本做一个项目，总不能是为了做一个项目而做一个项目，做这个项目一定是有它的核心价值所在的。哪怕是一开始模仿或借鉴他人的产品，也要做出差异化，在细分市场找到竞争力。

②明确性

是团队成员成功的标准。体现在个体实现价值，回答是组织对大家的期待是什么？大家的各自主要价值是什么？对于个体价值实现，需要回答3个问题：组织对你意味着什么？你对组织意味着什么？在他人眼中你对组织意味着什么？

也就是说，团队参与到整个项目中时，最终这产品做成了，在行业里面是一个怎样的定位？团队成员是否也会成为行业的牛人或者专家。或者至少团队成员经过这个项目的历练，是否可以取得组织期望的成长和进步。

③挑战性

团队理想未来的目标。聚焦的是回报体现价值。回答的是成功时，将获得怎样的回报？回报是否具有较强的激励性。

项目的成功也要给团队带来收益和价值，不能说团队辛辛苦苦做完了一个项目，结果项目收益，团队却获取不到预期的收益，那对于组织的稳定性来说，也是一种伤害。

所以，设置激动人心的目标，应该是包括三个维度的。因为保密项目的关系，这里就不给大家展示我们项目的目标了，但最终大家如果要去设置这个目标，可以从这些维度出发去考虑。模板参考如下：

一款xxx的产品，具备xxx的核心竞争力，预期的流水是xxx；

产品是行业的标杆或者xxx，团队成员是各自领域的行家，牛人；

成为一个有x，有x，有x的高效能团队，具体怎么定义高效能，可以根据实际情况增加定语。

2)论证项目的价值

有了激动人心的目标，并不代表着项目可以马上启动。如果项目团队中，发起人或者项目高管有直接开始进入到论证，则是更好，说明真正启动一个项目的时候的慎重，而且项目的重要性也不言而喻。但假设作为项目经理的我们，在接手这个项目时，团队并没有进行论证，则作为高阶的项目经理需要建议项目高管对项目的价值再次进行论证。

那么如何论证项目价值？有三个维度：是否值得做、是否有能力交付、是否能实现收益。

①项目是否值得做

以19年我们开始做的这款游戏项目为例，当时准备接手这个项目的时候，前期是做了大量的论证工作的。当工作室总经理确定要做这个品类的游戏时，并没有直接让团队开始做设计和进入到研发阶段，而是做了大量的论证，比如一系列的工作：

团队内部对市场各个品类的游戏进行方案的梳理和设计；

团队内部基于当前这个品类游戏进行SWOT分析；

团队内部多次开会讨论，最终明确品类的细分方向；

而后开始进行市场的用研（CE），分析这个游戏品类的市场，分析IP的价值，分析IP和这个品类的融合；

进而再对该品类细分领域进行商业化的推算；

除此之外，还有一个重要的点，就是投入成本和预期收益进行对比（ROI），最终才落定项目立项和启动。

对于这些，在游戏项目中来说，可能大都是制作人和策划要做的事情，但今天谈及这个论证点时，是期望作为项目经理，可以积极的参与其中，也可以基于自己对业务的理解献言献策。

②项目团队是否有能力交付

关于这个维度，大部分项目经理应该都是有实际参与其中的。

作为一名项目经理，我们都需要清楚的是，项目是立项启动了，有它的价值所在，但必须要思考的是，团队得有能力交付才行。

比如老板觉得当前有一个项目非常值得投资，但部门内本身就已经有很多其他事情在做，日常的运营资源就已经饱和了，几乎没有人力资源可以释放出来投入新项目里面，这样一来，是很难在预期时间内交付的。

再比如，团队之前一直做2D项目，但这个项目是一个3A大作，在交付方面则是一个大风险，因为没有3D方面的人才，要承接这个项目，就得想办法解决这个问题。

③项目能实现收益

项目实现收益这个维度，以游戏项目为例，大多是产品（策划）团队对项目正式上线后，其商业化进行推演。

要根据一些数据模型，去推演结算得出上线后的DAU、MAU，付费ARUP，以及每个月大概的流程和全年的流水，包括未来三年的流水。

然后结合实际团队投入的成本，估算实际获得的利润，并计算出利润率。

整个过程，都是在计算ROI，也即投入产出比，就等于说，投入了两个亿的成本做这个项目，结果最后成本都收不回来。那做这个项目的意义又何在呢？

3)做出MVP

MVP是精益创业里面的概念，意思是最小可行性产品（Minimum Viable Prouduct）。

最小可行性产品，指的是一个产品的雏形，是指将创业者或新产品的创意用最简洁的方式开发出来，可能是产品界面，也可能是交互操作的胚胎原型。

MVP有四个特点：体现了项目的创意；能够测试和演示；功能极简；开发成本最低。

以游戏项目为例，MVP我们时常也称之为demo版本。那具体怎么来确定MVP的范围和目标呢？

①打靶法确定最小范围

要做出MVP版本，首要的必须是确定最小范围。打靶法是最常用的一种方式。打靶法就是把一定要做的内容放在靶心的位置，其他可做，可不做的则在此之外。

这点在敏捷scrum方法论里面，也有专业术语，叫做MoSCoW 优先级排序法，是项目管理定义范围、确定功能质量、变更管理中常用的工具法则，以便项目团队对项目中的每个需求交付的重要性和紧急性达成共识。M—o-S-C—o-W，是四个优先级别的首字母的缩写，再加上O使之能够形成便于记忆的名称——MoSCoW。

其中Must have：必须有。如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能。

怎么来确定这个Must Have功能呢？如果有竞品，最高效的方法就是体验竞品的前30分钟，把涉及到的重点系统功能都记录下来，然后和产品团队一起再次聚焦Must have功能。但如果没有竞品，那就只能采用逐级打靶法了，根据产品团队给出的需求框架，逐级的精确Must have功能。

②投入最少的人力资源，快速开发

Must have功能确定之后，也是对齐确认最少可投入人力资源的情况。很多时候，对于项目团队来说，人员不一定是可以全部快速到位，往往最开始的时候，只有一部分核心骨干，这个时候，明确Must have功能之后，核心骨干就可以直接参与到功能需求的实现中，以最快的速度实现MVP。

③团队内部确认MVP

MVP功能开发完成，是需要得到团队内部的一致认可，至少是要在核心管理团队中达成共识，一致觉得MVP已经达成，可以代表项目的核心意图。

④向高层汇报

MVP在团队内达成共识之后，最终确定是否立项，需要向公司高层汇报，以最终确定是否可以立项。

以我们公司为例，绝大部分的项目，都是需要走这个流程的，除非是高层直接钦点的项目，但MVP的过程也少不了。

(2)启动

项目正式立项之后，就进入到启动阶段了，在启动阶段，重要的几件事情：

搭建项目管理体系、落实需求规划、明确版本管理流程、开好项目启动大会。

1)搭建项目管理体系

小规模团队的时候，项目经理一个人是可以沉浸到团队的细节中去，帮助团队解决具体的困难。但当团队达到一定的规模时，项目经理则需要根据项目和团队的特点，搭建更加适合的项目管理体系，或者受控环境。那么具体来说：

①识别干系人

项目启动之初，识别干系人是必备步骤，作为项目经理，得知道团队成员中各个人员的情况，尤其是核心管理层和核心骨干。

对于干系人登记造册，有很多相关的工具。登记干系人的情况不仅仅只是登记他们的姓名，职位和角色，更重要的是通过沟通交流，了解他们的需求和期望，判断对项目的影响，以便在后续重点管理。

②搭建团队组织架构

当然，识别干系人不仅仅是登记一个册子，更重要的是明确权责，搭建团队组织架构。项目的职能组织架构是下图的弱矩阵架构，这种架构是组织的需要，但没办法很好的应用到项目管理体系中。

所以，对于中大型项目团队来说，有一个非常关键的步骤，就是要根据项目的实际情况，把项目分为不同的领域群，类似于把一个大项目进行有机的切分，进而搭建一个更加适合项目快速推进的组织架构。参考如下图：

这个有机的切分是有讲究的，不是随便的根据系统功能模块来进行切分的，而是要根据整个项目的内在逻辑关系来进行划分。

当划分好了这个领域群之后，就可以根据不同的领域，分别确定对应的产品、前后台开发、美术和测试负责人。

尤其是产品负责人，要能够对该领域群所涉及到的系统功能有全局观和良好的把控能力。因为产品是源头嘛，所以需要对该领域的需求非常了解，或者一开始至少有这样的一个能力。对于产品领域群的负责人，是在需求审核环节要起到非常重要的效用。

那么这里还有一点项目经理要持续关注的就是，领域群的负责人并不是一成不变的，随着项目的推进，发现负责人不合适，则可以和核心团队沟通进行更换，以便更换的为项目服务。

划分领域群的目的，是为了接下来各版本持续迭代，持续交付时，更好地组建特性小组。这点在后面会详细说明。

③建立沟通体系和机制

我们都知道，在PMBOK管理体系中，项目经理是沟通的桥梁，这对于小规模团队来说（比如小于40人），基本上也不会成为瓶颈。

当团队规模大于40，达到百人，乃至更大时，整个项目的沟通，运行，不能完全凭借项目经理一个人的上传下达。这个时候，就需要建立项目的沟通体系和相应的沟通机制。

关于沟通机制，一个项目中，是有多个维度的，比如对上，对内，对外，有正式的和非正式的。以我们项目在运转过程中的项目信息沟通同步机制为例：5级企业微信沟通体系。

这个企业微信群，是我们项目信息日常沟通的一个机制和体系。这5个群的人员、功能效用都分别不一样，但我们通过这5个企业微信群，使得整个项目信息在推进过程中得以顺畅的沟通：

a、核心管理群：人员主要是高层管理者、项目组的制作人、各小组的leader、项目经理；主要的效用是项目的重要决策，重要里程碑目标的同步，让高层管理者及时的掌握项目的进度和信息。这个群基本上不会讨论具体的方案。建立主要一个核心管理群，还有一个重要的效用，就是获取高层管理的支持和肯定。一旦获得这方面的肯定，项目经理就会把这个信息及时地同步到项目的研发大群。比如某个大版本发布之后，项目经理汇总项目的数据同步到高层管理者，高层领导看到之后，认可点赞，那这就是非常积极的反馈。当把这个认可，点赞同步到项目大群时，团队成员看到之后也会备受鼓舞。

b、工作统筹群：人员主要是项目组制作人、各小组的leader、项目经理、美术项目经理、测试经理。这个群侧重点是项目主要事项的一些沟通，讨论，或者是一些重要会议线下当面沟通对齐之后，项目经理汇总信息同步到这里，让各主要干系人都清楚项目的信息和结论。如果是一些需要高层领导知道的事情，经过大家的确认之后，再同步到核心管理群。（运行一年后，这个群逐渐被FO群所替代了）

c、 项目研发群：项目组的所有成员。这个群主要是项目经理同步项目的整体目标、里程碑计划、版本计划，项目阶段性成果，或者是项目的信息，以及项目全员的一些通知。

d、项目特性群：项目制作人、各leader、项目经理、测试经理、各特性负责人、特性成员。特性群是对于中大型项目来说的，需要进行拆分多个特性来进行管理。那这个群的目的就是各特性线下的版本计划，项目的信息，包括测试过程中的沟通和进展同步

e、功能模块群：项目经理、各leader、测试经理、各特性负责人、模块成员。功能模块群就是具体到各个功能模块的开发，模块成员的沟通交流，联调及问题的反馈。

这个沟通体系的建立，是自上而下，也是自下而上的信息沟通闭环。

还有对上的沟通机制，我们在项目启动之初，就确定了每周五下午2点，开项目周会，周会的议题重点是版本的整体进度同步、下周的计划安排、问题或风险、产品相关工作进展、美术进度同步和本周资源产出展示。

以及项目到推进到一定阶段之后，也即有可玩的版本，确定每周三为核心管理团队集中体验版本。这个机制一来是重点体验上周的版本输出情况，二来是讨论一些重要的事项。

④搭建知识共享平台

对于一个新项目来说，组织过程资产的沉淀，也是重中之重，需要和项目推进同步进行。我们内部有一个强大的TAPD工具，可以直接创建wiki。所以在项目正式启动的时候，就搭建好了知识贡献平台，设置了各个角色，各角色按照模块将项目过程的相关知识都沉淀到wiki，便于积累和查阅。

2）做好项目全局规划

项目在启动阶段，重要事项之二就是做好项目的全局规划。有全局的规划，才可以更好地进行阶段的管控。具体来说：

①梳理需求框架

梳理需求框架，这部分可以和识别干系人，明确职责同步进行，因为这部分的工作，主要是产品（策划）团队要去做的。

项目正式启动之后，项目经理需要要求产品（策划）团队把整个需求框架梳理出来，这和scrum里面提的梳理产品待办事项列表是一个意思来的。

这个梳理出来之后，可以让团队对整体的功能需求有一个全貌。有两种表现形式，左边的思维导图用于规模相对较小的项目，思维导图一目了然。右边是大项目，系统功能和子系统功能，通常都是以百记的，采用在线表格的形式。

②明确需求优先级

在梳理需求框架的时候，其实也是明确需求优先级的过程。表格的优势也体现在这里，可以直接在具体工作拆分的后面加上优先级这一列。优先级的明确，目的不言而喻，就是进行项目全局规划的时候有的放矢。

③进行项目全局规划

一个大的项目，在具体落实的时候，一定是分阶段管理的，所以需要把一个大项目，拆分成多个版本来进行管理。参考如下图：

之所以要对项目进行一个全局规划，一方面是便于分阶段管理，另一方面更重要的是对大目标进行分解，分解的同时，也是进一步评估可能的风险，存在的瓶颈和关键路径。除此两点以外，还可以在这个过程中，更细致地对人力进行盘点。

具体怎么来做全局规划呢？项目经理在初始做规划的时候，一个很重要的依据就是来源于对项目背景的详细了解以及管理层的预期。项目经理要避免自己独自拍脑袋地去做一份项目的全局规划，这其实是不专业的。

我认为比较好的做法就是先有第一步，详细了解项目背景和管理层预期，根据这个来指导做第一版的规划。因为这样可以节省在对齐整体规划时的大量时间。

假设一开始没有和管理层沟通对齐预期，按照自己的理解去做了一份规划，结果和管理层去沟通的时候，发现和预期偏差很远，再回过来进行调整，是需要花费更多的时间的。

反之，先了解预期，根据所掌握的信息和管理层的预期，结合自己的专业，第一版规划做出来之后，和管理层沟通对齐，有细节的调整则微调，没有大的问题，整体规划就达成共识了。

这里有一点要特别强调，在做整体规划的时候，项目经理需要和产品负责人进行深入的沟通和交流，确保彼此的理解一致。项目经理不能完全的去拍个脑袋做一份规划，哪怕是有管理层的预期做支撑。

④制定整体里程碑计划

整体版本规划输出之后，就可以根据初步的估算，做出整个项目的里程碑，这个里程碑是比较粗略的，主要是让项目团队心里有一个预期，尤其是可以初步了解到项目进行中的几个关键里程碑。比如说，第一个重要节点版本，第一个垂直切片版本，第一个完整测试版本和最终上线版本的时间节点。

这个是对整体项目的推进有一定的指导意义的。当然第一版是粗略估算，那么后续就是根据实际版本跑的情况，变化的情况，及时调整更新，并同步给项目团队。

3）明确版本管理流程

持续迭代，持续交付都是以一个个版本来进行的，那么整个项目的研发流程，版本的开发模式以及版本合流就显得尤为的重要。

①规范项目研发流程

下图是以某一个迭代版本目标为例，从下图中不难看出，整个项目研发流程的定义是比较清晰的，而且也应该要界定清晰。

中大型团队，如果没有一个比较清晰的研发流程，团队间各成员间的协作很可能会产生某种内耗。尤其是项目刚刚启动开发阶段。

当然一开始的时候，研发流程一开始不一定要很详细或很全，可以在实际运行的过程中逐步优化和调整。

但有一点是需要特别强调的，项目经理在和团队明确好流程和规范时，就要去守护这个流程和规范了。这本身也是项目经理的一个价值体现。

如果发现团队中有不遵守的，就要进行沟通对齐，可以允许有不同的声音，但在当下某个阶段或者某个版本中，先遵守执行，回顾会上的时候，再和团队一起讨论优化。

除非是当前的研发流程，严重阻塞项目研发进程，否则一般不建议在当前迭代更改研发流程。

②明确版本开发模式

这个版本开发模式，我取名为流水线分支开发模式，简而言之，就是拉分支开发，各系统功能或特性之间，开发节奏不受影响。更细节的在迭代循环的部分详细介绍。

③明确版本合流流程

因为是流水线分支开发模式，所以必然会涉及到一个版本合流的流程，具体参照如下：

④推动落实工具建设

工欲善其事必先利其器。对于中大型项目来说，一定不可忽视的就是工具的建设。工具和业务开发并行，甚至先行，往往是可以大大提升效率的。

看着需求开发的过程是节省了不少时间，但事实上，验收和测试环节，则不够便利，影响整体效率。

所以，作为项目经理，要推动并落实工具的建设，要从全局考虑出发，项目的整体节奏和周期不仅仅只的是开发过程，还包括验收和测试环节，尤其是在敏捷思维下，需要的持续迭代，持续交付。下图就是我们持续建设并不断优化的工具体系。

4）开好项目启动大会

关于如何开好项目启动大会，其实在很多书本，文章中都有介绍了，这里也就不细说。分享两个要点：

①做好全员信息同步

项目启动大会，是一次全体项目的大会，那么在这个大会上，需要做好全员信息的同步。包括项目的整体目标、阶段性的里程碑目标、团队成员角色和职责、主导项目经理（中大型项目团队，项目经理往往不止一个人，需要有一个主项目经理，或称之为大项目经理）、项目的组织架构、各种流程和目的

②对齐项目目标

传达了项目目标并不等于就对齐了，我这里讲的对齐目标，更多的是指，需要项目高管从产品的愿景，部门或公司的期望等更高维度来阐述，包括市场情况、产品竞争力、未来的卖点和亮点，给团队传达和注入强自信心。

不仅如此，还可以阐述为什么要做这个项目以及相关的背景。这个可以更好的让团队成员去真正理解项目目标，也可以知道自己从这个项目中可以收获什么，让团队成员都可以积极的参与到项目中来，为实现自己的目标而不懈努力。

（3）版本循环

版本循环是敏捷实践下的重要一个环节，项目的持续交付，就是按照一个个版本来进行交付的。

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）版本回顾会议

在每个版本结束之后，我们会召开全员版本回顾会议，并进行总结。总结回顾会议的主要要点包括：

①整体版本演示

这一项是策划负责人，将我们整个版本做的需求和功能，在大会上进行全员展示并进行不同程度的解说。通过演示真切的告诉团队，我们整个版本做的具体的事情，这也是成果的展示。

因为在版本开发的过程中，可能很多团队成员都是一直在忙自己所负责的事情，这个演示会的目的就是让团队成员整体感受当前版本的完成情况，也是向项目团队展示整个版本周期的成果。通常15-20分钟左右的演示。

②版本数据展示

这一部分则相对比较客观，是项目经理和团队成员展示当前版本的一些客观的数据，包括版本需求的完成情况、自测通过率、bug修复率等等。

③产品的规划和想法

在项目经理介绍完当前版本的完成情况之后，主策会把项目下一个阶段的规划和想法和项目团队全员同步，主要目的是从产品侧给团队信心。如果这期间因为政策，因为市场的变化，产品的一些规划或者目标有变化，还会在大会上进行解释说明。

④技术和美术专项

这一部分则是主程和主美分别对各自己所负责的领域，和团队介绍过程中的一些重难点，实现方式，也包括一些制作方式，让团队成员也清楚一些工作的完成情况。这一部分则相对会偏专业一点。

⑤目标回顾（更新）

如果目标没有更新，则大会上再次和大家同步并强调目标以及关键时间节点；如果目标有更新，则同步更新的目标，并说明情况。既要说明what to do，也要说明why to do。

⑥复盘总结

复盘总结则会根据实际版本的情况，进行整体的回顾，分特性小组进行讨论，主要侧重点则是当前版本下，哪些是做的好的，哪些是需要持续改进的。

过程中一些不好的方面，主要的原因是什么，有什么改进措施，并且最后形成纪要，以便在下一个版本的时候更好的优化和实践。

（4）迭代循环

迭代循环是指的在版本循环的时候，规划的每个大版本，这些大版本会拆分为不同的迭代来进行增量交付。

在实践中，我们项目组规划好的每一个beta版本，是按照特性线的模式，有机地分发至各特性线进行。

各特性之间，就是独立的流水线模式，哪个特性先完成，哪个特性就先合入主干进入到验收和测试环节。

在迭代循环，我们项目的整个全流程参考如下：

1）迭代评审

每个迭代，具体对应的需求在人员落实之后，则会开始拉起需求评审，通常是对应特性下的所有参与人员都需要参加需求评审会。

需求评审会主要目的就是需求负责人对需求进行宣讲，包括需求的设计目的、具体功能、模块划分、细节确认、美术相关等。

在需求评审完之后，如果涉及到可行性论证，则还需要邀请核心管理层参加，进行拍板决定。而后才分别是开发和美术对工作量进行拆分。

2）迭代（需求）评估

由于我们项目是有合作方一起参与的，所以在需求评估阶段，分为两种情况：

①有合作方一起负责的需求，在需求设计方案和详细工作量评估输出的时候，需要合作方的负责人先审核确认，而后才是项目组负责人审核确认；

②没有合作方一起负责的需求，则在需求设计方案和详细工作量评估输出后，项目负责人审核确认即可。

在详细工作量评估输出之后，会将相对应的时间填入我们的项目管理工具（TAPD），而后项目经理根据详细的工作量评估进行排期。

排期的时候，可以项目经理和FO一起排期。如果FO有这方面的能力也可以FO自己排期。

具体计划输出之后，我们会在特性群（企业微信）输出详细计划安排，包括但不限于：FO是哪位、晨会安排、各模块负责人、关键时间节点、主要问题或风险点、详细计划、需求链接。对于一些大的特性，我们还会邮件更新同步，并且同步到TAPD的指定位置。

3）迭代开发

计划输出之后，就正式进入到开发阶段了。

开发根据自己评估输出的时间，进行编码、自测、联调。在需求开发阶段，有几个特别需要关注的点：

①对于有涉及到UI方面的需求，在开发联调自测结束后，需要拉起美术UI负责人在PC上先行验收，这样可以优先解决一部分很明显的美术体验问题。这个过程也是开发和美术先行验收美术效果。

②在需求开发的同时，测试人员也会同步开始进行用例的测试，待测试用例输出后，测试负责人会拉起和开发、策划的用例评审，并且输出开发自测用例。

③开发自测联调之后，就会开始跑自测用例。跑自测用例的目的是为了在输出产品验收的版本的质量稳定，全流程不出现卡点。也正是因为此，开发跑自测用例是版本交付验收的必要条件，且自测用例跑完并通过的比例是要超过90%。

4）迭代验收

开发自测通过之后，就进入到需求验收阶段。因为我们是分支流水线模式，所以先输出的是分支版本。

在分支版本输出之后，分别会有特性小组和美术人员一起安装APP版本进行验收。

与此同时，开发侧本身需要同步提交代码review（code review：CR）。

版本验收的时候，产品和美术会提相关的体验问题，开发人员则同步修改体验问题，以及CR的问题。

在确认体验问题和CR问题都修改完成之后，则会提交正式的合并请求。

这里需要特别注意：

如果当前特性是一个非常大的特性，对原有功能预判有比较大的影响的时候，在原主干版本合入当前特性分支的时候，还可以安排测试人员接入进来，参与冒烟测试，这样可以更进一步确保合入主干的版本稳定。

5）迭代转测试

在项目启动之初的时候，我们就有过约定，版本的正式转测试，都需要合入主干，统一一个版本，减少分支版本和主干版本的不一致性。

所以，在分支版本体验问题修改完成后，经过特性小组评估确定，验收通过，则会正式进入到转测试的环节。

开发人员在正式转测试的时候，除了要发转测试邮件，还需要写清楚转测试的内容，环境等。

6）迭代完结

我们的迭代完结，是以最后的bug修改，体验问题修改完为基准的。在版本循环的时候，我们有介绍，每个迭代的标准。所以，每个迭代的完成，是严格按照迭代的要求来进行的。迭代标准参考如下：

（5）适应变更

VUCA时代下，变化才是唯一不变的。作为项目经理，在项目推进的过程中，需要更好地拥抱变化。

在实际的背景情况下，当项目规划制定好之后，当目标确认了之后，也还是会由于各种情况而发生变化。

在这样的背景之下，项目经理需要做的是保持平常心，保持积极、客观的应对心态，当出现变化时，当出现对目标有影响时，及时地进行调整和更新。

结合我自己负责的这个项目来看，总结了四个变更的维度，分别是：市场、政策 、内部目标、人员。

1）市场方面

对于互联网项目或游戏项目来说，是市场驱动型的项目。因此当市场出现变化，项目出现变更则是一件再正常不过的事情了。

作为项目经理，则需要具备敏捷思维，拥抱变化。要相信，变是为了更好。当然，项目经理也可以在此过程中更多的参与和了解项目的背景，产品的规划，以及多和高层管理者沟通，汇报，及时的了解到相关信息，以便更加快捷的应对变化。

事实上，在VUCA时代，更自如地应对项目中的突发情况，并且积极高效调整后快速推进，也是项目经理的一项重要能力。

2）政策方面

这点就非常好理解，关于政策方面，使得项目出现不同程度的变更。

这几年互联网，游戏的监管越来越进入深水区。长远来看，是为了着眼于未来更良性的发展。但政策方面的变化，必然也是会对项目的规划、目标带来影响。项目经理只需要按照相关政策要求，去进行调整即可。

客观的情况，无需特别的焦虑。但有一点，就是在允许的情况下，要尽量多和团队成员解释清楚，因为政策变化而带来的项目侧的变化。

3）目标本身

这点也是非常常见的，项目的初始规划或目标并不会一成不变，由于市场、政策等带来的变化，会导致目标有所变化。

但同时，项目侧内部既定目标，也会根据项目的实际情况而进行调整，这都是很正常的事情。

项目经理是需要重点关注目标的，但不能因为目标的变化而感到焦虑，积极的应对即可。同样也需要做好相关的信息同步，并及时刷新计划。

4）人员的变化

还有一种情况，就是项目在推进的过程中，有部分人员的变化，也会导致项目目标出现变更。

一个公司、部门或者一个项目组，资源都是有限的，如果出现更高级别或战略更高的项目，很有可能会大规模的人员抽调，这个时候对于原有项目来说，则一定是会受到影响的。与此同时，目标也会跟着变更。

这种情况下，项目经理要做的就是做好突发情况的应对策略，梳理已经完成和未完成的情况，做好人员陆续补充或者人员陆续回来的工作安排。

（6）需求池

需求池更多的是指敏捷scrum方法论里面的产品待办事项列表。

需求池之所以要单独拿出来讲，是因为在具体实施的过程中，我们有不少项目经理会有某种误区，觉得需求只包含了产品需求。

其实真正的需求池，是包含三个方面的需求的：产品需求、美术需求和技术需求。

产品需求和美术需求都是明面上的需求，但技术需求，往往容易被忽略，比如性能的优化、工具的建设、基础框架的搭建、服务器的优化，还有其他和技术相关的需求。这些往往也是需要花费实实在在的时间的。

所以，如果项目中出现不同程度的delay，则需要好好的审视，项目中的需求安排，是不是遗漏了隐性的需求，导致工作评估和实际输出的不一致。如果是，那有必要在每个迭代计划制定的时候，把这部分隐性需求都纳入到正常的计划里面来。如此，计划的制定或许才会更加的合理。

（7）结尾

收尾和正常项目过程无特别的差异化，主要的事项就是交付产品或成果、开展项目回顾会议、项目活动收尾、组织过程资产的整理、团建。

其中回顾会议，非常建议项目经理在每个版本完结的时候，带着团队一起进行迭代回顾。这是可以和特性小组一起提升经验的，包括这个过程中做的好的方面，做的不好的方面，或者是都讲一讲觉得开心的事情，觉得不开心事情，一些建议是什么等等。

组织过程资产，则是项目非常重要的积累和沉淀，这本身也是项目最初始到结束持续做的，最后项目结尾的时候，再对这些过程资产必要的整理，如果有可以提炼的则进行提炼和升华，这样也是组织的财富。

至于团建，则根据项目完成的实际情况来定，比如吃饭聚餐、出去happy等。一个项目的完结也可以让团队成员共享项目果实。（来源:项目管理跃迁 徐州起航)