一个月拿下PMP，看完这三篇知识点，猛刷题就稳了——（篇2）敏捷串讲

手机端☞一个月拿下PMP，看完这三篇知识点，猛刷题就稳了——（篇2）敏捷串讲

• 开发生命周期类型
• 1.预测型：范围明确、有厚实的行业基础、计划驱动，也叫瀑布型。
• 2.敏捷（适应型）：快速应对变化，以较小的增量，快速迭代，每次增量都注重价值交付。
• 3.混合型：一个项目中存在多种生命周期类型，可以在风险不大，具有中低程度不确定性的项目中尝试，可以实现预测向敏捷的渐进过渡。

## 常见考点：

各种生命周期类型的选择
（混合背景的题目除了生命周期类型的选择，其他大多是考察敏捷的方向）

• MVP
• 1.MVP的定义

最小可行产品，符合产品预期的最小功能集合。在MVP的基础上继续快速迭代，直到产品稳定。
最小：只具备必备的基本功能（必备不代表价值一定最高）
可行：可正常运行，以验证产品理念和商业模式。

• 2.MVP的作用

试错，快速推向市场，快速获得验证。

## 常见题型：

不知道市场是否欢迎；不知道是不是客户想要的；
客户自己想要什么说不清楚；
时间比较紧或者预算有限的情况下需要立即发布产品；无法在有限的条件下做一个大而全的产品。

• 敏捷宣言
• 1.个体以及互动胜过过程和工具
• 2.可用的软件胜过完整的文档

## 常见考点：

对文档的要求可以记录在DOD；
不可以用专门的Sprint写文档，注意“切蛋糕”原则。

• 3.客户合作胜过合同谈判
• 4.应对变更胜过遵循计划
• 敏捷十二原则
• 1.我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

## 常见考点：

及早、持续不断地交付/增量交付； 
价值驱动

## 常见题型：

敏捷中应该优先完成价值较高的待办事项。

• 2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 （为什么敏捷可以拥抱变更）

## 常见题型：

敏捷遇到新需求如何处理？放入PB排优先级，当前Sprint理论上无变更。

• 3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

## 常见考点：

短期频繁交付，强调干系人频繁参与，及时获取反馈
例如：经过四次迭代之后，PO对可交付成果不满意…

• 4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

## 常见考点：

仆人式领导，辅以信任，授权，支持协助

• 6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

## 常见考点：

提倡集中办公，面对面沟通，但也可以使用虚拟协作工具：鱼缸窗口、远程结对

• 7.可工作的软件是进度的首要度量标准。
• 8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

## 常见考点：

可持续开发，步调稳定延续

## 常见题型：

评审会发现有缺陷，发现新需求，发现功能尚未完成，一律放入PB排优先级，不提倡加班处理，否则不利于步调稳定；另外，敏捷不提倡随意增加资源，团队人数一般固定，否则不利于团队速率的稳定。

• 9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

## 常见考点：

技术债务和重构

• 10.以简洁为本，它是极力减少不必要工作量的艺术。

## 常见考点：

专注于目标

• 11.最好的架构、需求和设计出自自组织团队。

## 常见考点：

自组织的含义

• 12.团队定期地反思如何能提高成效，并依此调整自身的行为表现。

## 常见考点：

定期回顾，持续改进

• 敏捷实践

Scrum

Scrum的三个角色

• 1.产品负责人（PO，业务专家）

清晰描述产品待办事项列表ProductBacklog（PB），负责管理产品待办事项列表PB的唯一责任人，对列表项进行优先级排序，确保PB透明清晰，确保开发团队对PB有足够深的了解，团队可以参与上述工作，但是责任人还是PO。

## 常见考点：

(1)当团队对需求或优先级有疑问，澄清需求和优先级的最佳选择就是PO，如果没有PO也可以考虑让干系人澄清需求；
(2)Sprint评审会上，最终PO决定是否接受完成的增量。

• 2.开发团队（开发人员，牛马）

(1)自组织：自主决定每个Sprint做什么，做多少；负责任务的估算、自主决定任务的分配、自行决定任务具体的执行。

## 常见考点：

执行层面的工作都交给团队自组织。

(2)跨职能：团队拥有创建产品的全部技能，T型人才一专多能，有利于协作、交叉培训和结对。
(3)去中心化：不认可任何头衔，不管承担什么工作，都叫开发人员，没有多个层级也不认可子团队（比如测试、架构等等）
(4)相对稳定：一般3~9人，比较稳定，建议全职。步调稳定延续。
(5)主动学习：愿意接受挑战，主动要求学习和成长。

• 3.ScrumMaster（敏捷教练，服务型领导）

服务型领导（仆人式领导）：敏捷题中的项目经理、敏捷教练、敏捷主管、团队促进者等等说法均是服务型（仆人式）领导。
(1)服务于PO：确保产品负责人了解如何安排PB，帮助理解并实践敏捷性；
(2)服务于团队：作为教练在自组织和跨职能方面给予指导，移除开发团队工作中的障碍（考试中常见的障碍：团队外部的干扰，仆人式领导要发挥牧羊犬的作用）；
(3)服务于组织（干系人）：作为教练指导组织采纳Scrum，帮助干系人理解并实施Scrum。

Scrum的三个工件

• 1.产品待办事项列表PB

(1)涵盖产品的已知需求，包括所有的特性、功能、需求、增强和修复，按照优先级排序，优先级越高则越详细；
(2)优先级较高的，可以交给开发团队去开发的用户故事应该符合就绪的定义DOR（Definition of Ready）；

• 2.Sprint待办事项列表

为当前Sprint选出的产品待办事项，至少包括一项在前次回顾会议中确定的高优先级的改进；

• 3.增量

(1)一个Sprint完成的所有待办事项的总和，以及之前所有Sprint所产生的增量的价值总和；
(2)必须达到“完成”的定义标准DOD（DefinitionofDone）；
(3)最终PO决定是否可接受；
(4)无论产品负责人是否发布，增量必须可用。

## 常见题型：

如果团队认为增量是完成的，但是PO或者干系人认为增量并没有完成，那么最可能的原因就是大家对DOD的理解不一致。

Scrum的五个事件

• 1.Sprint

(1)长度固定（一般2~4周）；包括：Sprint计划会议、每日Scrum站会、Sprint评审会、Sprint回顾会议和日常的开发工作；
(2)Sprint期间不能做出有害于Sprint目标的改变；

• 2.Sprint计划会议（P）

(1)计划Sprint要做的工作，整个Scrum团队共同完成；
(2)2周的Sprint，一般4小时；对于一个月的Sprint，最长8小时；
(3)在计划会议中确定Sprint目标；
(4)产品负责人帮助解释所选的产品待办事项；
(5)开发团队自己决定选择产品待办事项列表的数量；
(6)开发团队决定如何完成选定的产品待办事项。

• 3.每日站会（D）

(1)增进沟通，同步信息；
(2)时间盒限定为15分钟的事件，每天举行；
(3)开发团队自行负责；
(4)站会仅说三个问题：昨天做了什么，今天准备做什么，遇到了什么障碍或问题；
(5)会上不讨论其他问题，有问题会后另行讨论；
(6)开发团队自己负责召开会议。
(7)如果有开发团队之外的人出席会议，ScrumMaster必须确保他们不会干扰会议进行；
(8)如果有多个敏捷团队为一个项目工作，需要召开SOS会议（Scrum of Scrums）。

• 4.Sprint评审会议（C）

(1)在Sprint快结束时举行，用以检视所交付的产品增量，并按需调整PB；
(2)有时间盒限定：2周的Sprint，一般2小时；对于一个月的Sprint，最长4小时；
(3)整个Scrum团队和干系人参加；团队演示完成的工作；
(4)PO说明哪些已经完成，哪些没有完成；
(5)评审会议的结果是一份修订后的产品待办事项列表，阐明很可能进入下一个Sprint的产品待办事项。

• 5.Sprint回顾会议（A）

(1)团队检视自身，并创建下一个Sprint改进计划的机会；
(2)有时间盒限定：2周的Sprint，一般1~2小时；对于一个月的Sprint，最长3小时；
(3)Scrum团队应该明确接下来的Sprint中需要实施的改进；
(4)可以多次回顾，但一般说的回顾会往往指Sprint结束时的回顾。
(5)了解产品待办事项列表梳理会：澄清或细化用户故事，审查优先级，估算故事点等工作，一般不超过团队产能的10%的时间。

Scrum的五大价值观

• 勇气：有勇气做出承诺，履行承诺，接受别人的尊重。
• 承诺：愿意对目标做出承诺。
• 专注：把你的心思都用到你承诺的工作上去。
• 开放：Scrum把项目中的一切开放给每个人。
• 尊重：每个人都有他独特的背景和经验。
• 看板系统

可视化管控，拉动式生产，消除瓶颈

• 极限编程
• 测试驱动开发（TDD）
• 验收测试驱动开发（ATDD）
• 行为驱动开发（BDD）
• 重构解决技术债务结对编程代码集体所有持续集成。
• 敏捷中的各个知识领域

整合管理

• ①团队自行决定计划及其组件的整合方式（自组织）；
• ②项目经理负责营造一个合作型的决策氛围；
• ③团队如果是T型人才有助于合作并解决知识孤岛；
• ④敏捷一样有高层级的内容，有项目章程，有产品愿景。

范围管理

• ①先为整个项目确定一个高层级的愿景；
• ②多次迭代开发可交付成果；
• ③每次迭代开始定义详细范围；
• ④干系人持续参与；
• ⑤有目的地构建和审查原型；
• ⑥每次迭代都会确认范围和控制范围。

进度管理

• ①具有未完项的进度计划（Scrum）、按需进度计划（看板系统）；
• ②敏捷发布规划：
• ③产品愿景、发布计划、迭代计划；
• ④控制进度（燃尽图、燃起图）；
• ⑤累积流图。

成本管理

• ①轻量级方法生成高层级预测；
• ②详细的估算适用于采用准时制的规划。

质量管理

• ①完成的定义DOD；
• ②测试驱动开发、行为驱动开发、验收测试驱动开发；
• ③持续集成；
• ④Sprint回顾会议；
• ⑤代码集体所有；
• ⑥全员负责。

资源管理

• ①提倡集中办公；
• ②T型人才；
• ③自组织团队；
• ④交叉培训；
• ⑤团队章程（基本规则、工作协议）。

沟通管理

• ①透明、高效；
• ②信息扩散器（看板、燃尽图、燃起图、累积流图、障碍板）；
• ③提倡面对面沟通；
• ④虚拟协作（鱼缸窗口、远程结对）；
• ⑤多团队Scrum of Scrums(SoS会议)；
• ⑥追逐太阳。

风险管理

• ①在迭代规划的时候考虑风险，在迭代期间识别、分析和管理风险；
• ②根据风险敞口的理解加深，重新排列优先级。

采购管理

• ①客户协作高于合同谈判；
• ②多层结构协议（主协议和补充协议）；
• ③关注用户故事而非整个项目的预算；
• ④动态范围方案；
• ⑤提前取消方案；
• ⑥资助团队而非范围。

干系人管理

• ①频繁参与；
• ②高效透明的沟通；
• ③常见的干系人管理方法。