PMP^®项目案例：PM如何快速上手敏捷模型开发？

一、本期话题

如何快速上手敏捷模型开发？

二、背景介绍

新入职一家公司，行业跨度很大(从应用软件转为操作系统那种)，完全不了解新公司的业务。

项目管理方式区别也很大，以前的项目类型是定制化的交付项目，采用传统瀑布型模式管理，现在的项目的内部研发项目，采用SCRUM敏捷模型开发。领导又着急让新人上手。

目标：如何快速接手敏捷项目？

三、嘉宾分享

01用户昵称：Fiona

这边我想几个我个人比较看重的敏捷的几个要点：

1、尽早和持续的交付有价值的软件给客户；

2、敏捷欢迎变更，对每个故事进行优先级排序(做到一半的时候，有新的紧急的需求进来，那么产品可以考虑重新排列优先级，在当前迭代中可以把优先级较低的需求移到下一个迭代，拥抱变更不是指无限增加工作!)；

3、敏捷不做长期详尽的规划，一般只做短期规划(比如这2周或者这1个月要完成的目标)。

我下面会从5个会议以及我目前使用的看板进行阐述下。敏捷需要做好的5个会议：

1、需求评审会

澄清需求，很多公司比如我们之前没有进行需求澄清，导致开发不理解需求，基本是按照开发自己怎么想就怎么做，最后的结果就是返工了，评审会建议团队都参加，确保有问题可以及时理清。

2、计划会

分配这1-2周需要完成的故事点数，故事拆分要遵从INVEST原则，我们开发中的经验是更注重，小的，独立的，可测试的，拆分故事可以使用的方法很多，比如计划扑克，相对规模估计等等，这个之前群里有讨论过，这里就不赘述了;目前我公司拆分的故事原则是一个故事不超过2周，并且故事要明确验收规则。

3、每日站会

沟通进度，站会上只沟通 昨天做了什么;今天要做什么;目前有遇到什么问题;时间限制在15分钟内;团队成员最佳在5-9人，如果团队过大，建议划分成小组进行;目前我公司是有使用看板，每日站会都在看板前进行

4、产品迭代功能演示会

开发在完成产品功能后，需要先演示给产品看，确认功能符合期望，避免惊喜

5、回顾会

目前我们公司是每2周一次，总结回顾(15分钟-1小时)，这边要注意下，回顾会不是批判会议，可以不邀请大领导参加会议，不然容易变成大家都不敢说或者变成甩锅大会;回顾会重要的一点是要形成改进措施，在下一个阶段可以有所进步，保证迭代更加稳定的进行。

（这是我目前在用的看板规划）

（用户故事）

（任务贴）

当然要做好敏捷，还有很长的路要走，指导团队了解理解敏捷；目前我们公司每个季度会对每个小组的敏捷成熟度进行评估，可以建议公司在每个季度前，让小组设定敏捷季度OKR目标，比如：1、团队成长目标 2、效能提升目标 3、质量提升目标。

除了OKR评分，每个季度我们还会进行敏捷成熟度的评估，一下子做好敏捷很难，但是大家可以一点一点累积。

我建议题主可以从以上5个会议以及OKR进行敏捷切入指导团队共同参与敏捷，使用敏捷。

02用户昵称：李昀

看到这位道友能提出这样的问题，应该是已经懵了。

换到一个新的环境，不只是你，很多人都有这样的困惑，特别是中途接手一个既不熟悉业务，至于如何快速的熟悉流程，特别是敏捷环境的流程可以议一议。

从组织背景和行业背景来看，这个企业规模不小。

从组织形式来看，我猜测，这是一个刚刚做敏捷转型不长的企业，且这个转型在我看来也不算是太成功，类似于一个将特性迭代加入门禁控制的螺旋结构的产品开发，我们暂且不论他是不是敏捷，至少他里面有一些Scrum的影子，且我大胆猜测这个项目组之前在人员上出现了一些问题，才会有这种情况

1、千万别害怕，不会学就是。没有谁生来就会，不会或者不懂都是正常的，环境切换是要花费一些学习成本的，不会就学是人类与其他物种的最根本区别，最基本的情况是，尽快的把scrum的基本方法的过程熟悉起来，对3355要有个理解，更进一步的要对应到你熟悉的知识领域，一方面，要了解一下《Scrum指南的内容》，另外一方面要去找一些网络的资料，比如说创造营中的分享【敏捷是什么】， 另外如果有精力，去学个PMI-ACP^®或者CSM是最好的。

2、把组织过程了解清楚，我没有看到整体的组织过程和项目方法，我猜测该组织的过程方法跟Scrum还是有一定的差距的，不管是内训资料，还是已定义过程，相信组织中一定是有的，看看去绝不会吃亏，最好是能够将自己的问题列一个清单，去一个一个的解决。

3、不要看人家怎么说，看看实际的情况是什么样的。深入的项目中，很多情况下，你看到的培训资料跟实际情况是有一定的出入的，从组织结构来看，受诊人的角色也不是一个意义上的SM，更像是一个迭代组织者。

那我建议关注的焦点就在于一些基于迭代的特性上，比如说backlog的建立和规划，速率，潜在交付成果关口定义，过程质量内建，回顾和改进。

从一个瀑布的PM到一个scrum的SM是会颠覆一些认知的，但是客观情况对这些认知是起一定的塑造作用的，事是怎么办的最重要，知道该怎么办更重要，书上怎么说的，不重要。

总的来说，我们遵循这样的过程，应该可以尽早的融入一个过程中：

1、建立信心，不惧挑战，相信自己的专业程度和业务能力；

2、了解组织过程，并提出自己的问题，学习相关的知识和理论，尽早解决；

3、深入项目，从实际出发，回溯到理论基础和组织过程，形成焦点关注和项目原则；

4、持续更新，持续学习。

最后，scrum的5大价值观送给大家

承诺– 愿意对目标做出承诺

专注– 把你的心思和能力都用到你承诺的工作上去

开放– Scrum 把项目中的一切开放给每个人看

尊重– 每个人都有他独特的背景和经验

勇气– 有勇气做出承诺，履行承诺

03/ 我有话说 /

聪少-广州-无业闲人：

“1、先了解公司业务，不用急着上手，公司做什么都不了解，如何带好一个团队。

2、按各位大神所讲，找有经验的人，先了解瀑布式与敏捷式开发的不同之处。

3、查看相关项目的组织过程资产。”

04/ QA /

Q：scrum里面有没有项目经理？

A：理论上没有.

Q：Scrum master 不是类似PM吗？

A：完全不类似，sm要保证团队使用正确的方法做正确的事向正确的目标。

Q：现在很多团队在弱化测试人员， 敏捷开发对人员要求高，数量有限，是配专门配测试人员，还是采用研发间互相测试更合适？

A：敏捷中对这方面没有具体的定义，但是会有质量内建这个概念，也就是说，在团队内部对质量负责，但具体是谁，要看具体情况。

Q：或者立项的项目 开发团队不做呢？

A：通常来说，这个时候，会有人站出来，通常我们管这类人，叫PMO。如果说，你把每个阶段独立来看，他就有个上下游的关系，通常这个时候，我们会考虑分阶段管理，给每个阶段设立Gate

Q：既然 敏捷组织中 没有项目经理， 那么PMO 在这个组织中 是什么样的角色呢？

A： 敏捷组织中没有项目经理，不意味着项目没有管理者。作为pmo，这时候就不是项目经理的管理者，而应该是资源协调者，目标灌输者，或者是战略统一者等等，层次要高一点。

总结：从5个会议以及okr进行敏捷切入指导团队共同参与。建立信心，了解组织过程，深入项目，从实际出发，持续更新，持续学习。