PMP敏捷部分
什么是scrum
较传统的瀑布模型而言，瀑布模型对于项目中的各个阶段只会执行一次，当基准确立后，就不允许任何非正常的修改，如需修改的话，需要提交变更请求，待请求批准后即可更改。（一切不走变更流程的变更都是耍流氓！）
基于瀑布于敏捷之间其实还有两种项目模型，即迭代跟增量。举个栗子，同样要交付一副蒙娜丽莎的画，迭代的感觉是先画个手稿，然后不断精雕，最后一次交付作品；增量的感觉就是先画一个完整的手，再画完整的头，然后身子，其他。。。如此反复，是多次交付。
最后对于敏捷而言，就像是迭代+增量，即每个迭代周期都会交付，属于频繁交付的模型。当我们再回过头来看瀑布模型时，就会明显感觉到敏捷里面没有流氓！不对，敏捷拥抱变更，但是对变更是有要求的，这点一会再说~先记下。让我们先来看看敏捷包含哪些东东。
3大角色
- 产品负责人（product owner）
负责将敏捷团队所产生的产品价值最大化，负责对PB(product backlog)进行有效管理，包括：
1.开发并明确沟通product goal。
2.创建并清晰的沟通product backlog条目（items）。
3.对product backlog条目今昔排序。
4.确保product backlog是透明的，可见的和可理解的。
po是一个人，不是一个委员会，可以自己做上述工作，也可以委托给他人，但是po是最终负责人。
- 敏捷教练（scrum master）
打造一个成熟的团队，为交付扫清一切在接口上的障碍。
- 团队（developers）
致力于做交付。
3大工件
- 产品代办列表（product backlog）
- 冲刺代办列表（sprint backlog）
- 产品增量（product increment）
5大会议
- 产品细化会（product backlog refinement）
相当于pmbok的5.2收集需求，该会议测量的是下个迭代的需求。
- 冲刺规划会（sprint planning）
相当于pmbok5.3定义范围，该过程会定义what+how。
- 每日站会（daily scrum）
- 迭代审查会（sprint review）
相当于pmbok5.5确认范围，会对产品增量做验收。
- 回顾会（retrospective）
相当于pmbok4.7结束项目或阶段，该过程会总结经验教训。
scrum的一个迭代流程
