PMP中敏捷知识梳理

PMP中敏捷知识梳理

PMP强调做项目要有计划，是典型的计划驱动模式。PMP更多的是基于瀑布型模式管理。要做计划外的东西，就需要明确范围，如果要变更，变更必须受控。

以软件开发为例，以瀑布型管理的项目，就需要将项目分为几个阶段（需求-设计-开发-测试-交付），然后每个阶段重复执行五大过程组，直到将项目做出来。

瀑布式要求需求要明确，要有厚实的行业基础。故瀑布式通常用于传统行业。

瀑布型开发的主要问题在于：

1. 在项目一开始必须对整个项目的详细需求投入大量的人力调研，将需求收集清楚；
2. 项目一开始要编写大量的文档；
3. 客户参与度不高；
4. 需求变更要加强管理，变更必须受控；
5. 需要花大量时间汇报项目进度；
6. 一直要到项目结束，才能交付客户可用的系统；
7. 开发可能会跟不上市场变化。

以敏捷管理的项目，强调“小步快走”。强调先交付优先级最高的。

敏捷开发的主要优点：

1. 一开始不需要对整个项目的需求进行调研，只需要搞清楚高优先级的需求，无需在一开始就投入大量人力；
2. 也不需要大量文档。敏捷不强调文档，文档够用就行；
3. 频繁交付，频繁演示，需要客户不断参与，客户参与度高；
4. 拥抱变更，快速适应变化。

敏捷与迭代的区别： 单纯的迭代是迭代的整个项目，敏捷是做的优先级最高的部分。敏捷的迭代是迭代某一个部分。

敏捷与增量的区别： 敏捷强调优先级，永远做的都是当前优先级最高的功能；增量不强调优先级，也不强调量。敏捷每次冲刺/迭代的时间是固定的，一般是2-4周。

敏捷中有迭代也有增量，但是“以较小的增量”“快速迭代”，每一次交付的是最有价值的东西。强调“价值优先”。

敏捷团队角色介绍：

1. 产品负责人 与客户密切联系，对产品十分了解，负责理解和传达需求，包括对需求进行收集，对优先级进行排序。在团队协作时，要负责回答团队问题；在系统交付时，要负责接受/拒绝完成的成果。
2. Scrum主管 相当于敏捷团队中的项目负责人（在敏捷中没有项目经理）。Scrum主管是服务型领导，仆人式管理。他不会命令、控制团队，而是支撑团队。当团队需要支持时，Scrum主管给予支持，保护团队不受外部干扰。
3. 开发团队  强调自组织和自我管理。敏捷的团队要求团队成员有自组织、自我管理能力，需要通用的专才（T型人才）。

PS：I型人才指的是对某一个方面精通，T型人才强调“一专多能”。

敏捷开发流程介绍：

首先，我们要介绍PB“产品待办事项列表”。

PB（产品待办事项列表、未完项清单），是一组条目化的需求，可以理解成是先将敏捷中的需求全部放在这里。需要注意的是，这里的需求都是用所谓的“用户故事”来描述的，也就是从客户价值的角度描述需求。

用户故事指的是：“作为一个<角色>，需要<功能>，实现<价值>”，这里极度强调“价值”。

有了PB，那敏捷团队是怎么开发呢？

首先，强调优先级。产品负责人会将这些“用户故事”排定优先级，有了优先级后，接下来要考虑做哪些。

这里，需注意敏捷与瀑布的极大差异。

瀑布用的是“范-进-成”正三角的方式，敏捷是先固定人数（成本固定）、定义时间（进度固定），然后再考虑在这个条件下能做多少最有价值的事情，也就是“倒三角”的方式。

敏捷中的每次迭代，又叫每个“冲刺（srpint）”。

一旦确定了每个冲刺要做多少事情，项目团队便只做这些东西，其余不管。

那么，怎么确定在每个冲刺点在固定人数、固定时间内完成多少事情呢？

这里就需要理解“故事点”和“速率”两个概念。

在敏捷中，“故事点”是一个度量单位，是用来描述一个用户故事需要多少工作量。“故事点”一般是选择一个体量最小的用户故事作为基准，其他用户故事就跟其进行比较。也有团队是用时间来度量的，但在敏捷中，一般建议用“故事点”作为度量单位，因为每个团队的效率是不一样的，用“故事点”度量可以减少不必要的争议。

“速率”指的是团队在每个冲刺中能完成多少个故事点。

敏捷要求每个冲刺之间没有太多的关联。

敏捷中的原则是：当前迭代不考虑变更，有变更就放到PB中去排定优先级，在后续迭代中进行处理，故变更不会影响当前迭代。

对每个敏捷项目中，整个项目的范围是不确定的（但在每次冲刺中是基本确定的），成本也是不确定的（所以敏捷项目可以用单价合同）。

那么，敏捷项目中的进度怎么监控呢？一般我们用看板和燃尽图。

DOD原则（Definition of Done）：一定要事先确定“完成的定义”

如果在当前迭代中发现优先级特别高/法律变更之类的极端事宜，可以通过宣布当前迭代失败或者替换故事点来实现。

敏捷中的四大会议：

1. 迭代规划会议 指的是在每个迭代开始前，确定要完成哪些事情，将大家一致认可的用户故事放在“迭代（sprint）待办事项清单”中。
2. 每日站会  这个会议一般比较短，一般不超过15分钟，这个会议只讲3件事情“昨天做了什么、今天计划做什么、遇到了什么问题”。问题提出后，在站会上只记录不讨论。
3. 迭代评审会议  这个会议是指在每次迭代完成的演示会议。
4. 回顾总结会议  总结经验教训，哪些做得好，哪些可以做得更好，下次可以做哪些改进。

另外，敏捷中还有SOS会议，用于多个敏捷团队组成的项目中选一个代表汇报，实现对项目的整体把控。

敏捷还有这几个特点，“持续集成”、“TDD（测试驱动开发，以测试标准来要求开发）”。