目录
PMP敏捷管理常见考点
Scrum框架的3355
Scrum框架有3个角色，3个工件，5个事件，5个价值观，简称3355。
3个角色
- 产品负责人PO(Product Onwer)
- 开发团队（Develop Team)
- 敏捷教练（Scrum Master)
敏捷中主要包括三个角色：产品负责人(ProductOwner)、敏捷教练(ScrumMaster)、项目团队(ScrumTeam)。
产品负责人(ProductOwner)：主要负责确定产品的功能和达到要求的标准，维护产品代办事项列表，指定软件的交付的内容，同时有权力接受或拒绝开发团队的工作成果。
开发团队（Develop Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在3~9人左右(PO、SM不包含在人数中，除非参加执行冲刺列表中的工作)，团队获得授权，自组织和管理他们的工作。每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，责任属于整个开发团队。为团队提供了一种一起成功、失败、调整、改进的途径。
敏捷教练（Scrum Master）:主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。主要有服务团队、教导团队、保护团队、引导Scrum的有效应用职能。
3个工件
- 产品待办列表（Product Backlog）
- 迭代冲刺列表（Sprint Backlog)
- 产品增量表（Increment）
产品待办列表：是所有工作的有序列表，它以故事形式呈现给团队，价值越大的排在上面。
- 产品需求列表
- 产品负责人对该列表进行优先级排序
- 待办事项列表中的条目以用户故事的形式呈现
迭代冲刺列表：
- 是产品代办列表的子表，只记录当前迭代的工作
- 将用户故事拆分成任务，团队成员主动领取任务
- 团队成员可以添加、删减或者更改迭代中的任务
产品将增量表：
团队在迭代内完成交付成功，集成到以往的迭代成功中，形成增量式的交付。
每次交付的用户故事必须符合验收条件
5个事件
- Sprint(Sprint 本身是一个事件，包括了如下4个事件)
- Spring 冲刺计划会议（Sprint Planning Meeting）
- 每日站会 （Daily Scrum Meeting）
- Spring 冲刺评审会议 （Sprint Review Meeting）
- Spring 冲刺回顾会议 （Sprint Retrospective Meeting）
冲刺计划会议
目的：用来决定本次Sprint的交付成果以及为了达成目标应该如何工作。
特征：标志着Sprint的开始；确定哪些用户故事会被纳入本迭代中进行；并拆分成task以估算时间团队成员领取task；PO必须为迭代计划会议准备一个最新的、经过排序的待办事项列表；对于一个月的Sprint来说，Sprint计划会一般不超过8个小时，4个小时用于选择故事和4个小时估算分配。
每日站会
目的：为了在团队内部沟通交流成果以及阐述任何存在的障碍而召开的每日例会。
做法：昨天做了什么？今天将做什么？遇到了什么问题？每日展会不解决问题！！！，可以提出问题但不用解决，会后沟通。
特征：每日展会只有15分钟，每天发生在同一时间和地点。
冲刺评审会议
目的：团队给PO和相关干系人演示Sprint中所完成的功能(尽可能使用相对真实的环境)；并接受PO的意见、建议和评价，用以检视所交付的产品增量并根据需要调整产品待办事项。
评审结果：一份修订后的产品待办事项列表，明确很可能进人下一个送代的待办事项。
冲刺回顾会议
定义：在Sprint结束时召开的关于团队自我持续改进的回顾复盘会议。通常在Sprint评审会之后，在下次Sprint计划会议之前展开。一个月的sprint不超过2小时。
目的：总结这一个迭代中的经验和问题；找出后续潜在改进的主要方面，同时加以排序；制定改进工作计划。
5个价值观
- 承诺-愿意对目标做出承诺
- 专注-把你的心思和能力都用到你承诺的工作上去
- 开发-Scrum 把项目中的一切开放给每个人看
- 尊重-每个人都有他独特的背景和经验
- 勇气-有勇气做出承诺，履行承诺，接受别人的尊重
《敏捷宣言》四个价值观，十二大原则
4大价值观
- 个体和互动，高于流程和工具
- 工作的软件，高于详尽的文档
- 客户合作，高于合同谈判
- 响应变化，高于遵守计划
12大原则
- 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
- 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势
- 要经常交付可用的软件，周期从几周到几个月不等，且越短越好
- 项目实施过程中，业务人员与开发人员必须始终通力协作
- 要善于激的项目人员，给予他们所需的环境和支持，并相信他们能够完成任务
- 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈
- 可用的软件是衡量进度的首要衡量标准
- 敏捷过程提倡可持续的开发。项目发起人、 开发人员和用户应该都能够始终保持持步调稳定
- 对技术的精益求精以及对设计的不断完善将提高敏捷性
- 简洁，即尽最大可能减少不必要的工作，这是一门艺术
- 最佳的架构、需求和设计将出自于自组织团队
- 团队要定期反省怎样做才能更有效，并相应地调整团队的行为
敏捷相关的名词
仆人式领导
定义：一种为团队赋权的方法。通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。
作用：促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。
WIP在制品限制
work in process，是指材料或部分已开始生产但是还未完成的产品，也就是半成品。
看板
看板是丰田公司在19世纪40-50年代开发的一个及时（JIT）生产调度系统。它是通过卡片或者信号来请求（需求信号）其他独立系统中（供应方）生产流程的必须部分，以此控制和减少库存。看板已被应用于敏捷中，来帮助控制工作流。他可以帮助团队意识到他们是如何工作以及下一步要做什么，让团队形成自我指挥。
XP极限编程
极限编程(XP)是一项以编程人员为中心的敏捷架构，注重小而迅速的发布。XP极限编程强调以下原则：结对编程 可持续速度 不断自动测试 有效沟通 简单性 反馈 勇气 集体所有 持续集成 激励工作 共享工作空间 现场客户代表 使用隐喻说明概念。
XP极限编程用语中“caves和common”指的是，为团队成员创造的两个分区。common是一个公共的空间，在此常有渗透沟通和协作。caves是一个私人的交易预留空间，需要一个孤立且安静的环境。
计划扑克
计划扑克是基于宽带德尔菲估算技能、是以共识为基础的工作量估算技能。有时候也称为敏捷扑克，往往在故事点和开发用户故事中用来估算相对工作量。
在计划扑克会议中，每一位成员各持有一副相同价值的计划扑克卡片。
计划扑克会议按如下的步骤运行：
- 一名调停人，主持会议，不参与估算
- 产品负责人对用户故事做概述，并回答开发者提出的澄清问题，往往产品负责人不参与投票
- 每一位成员抽取一张卡片来估算工作量
- 每人抽取一张卡片后，同时将他们的卡片翻转
- 持高和低估算的成员各有一次辩护机会
- 达成共识前，不断重复以上流程
用户故事
用户故事：User Strory，它是这样来描述需求的：身为某一个角色，为了什么价值，需要什么功能。
用户故事三要素：角色，动机，价值。
举例：作为一个60后的微信用户，为了高效地完成信息交流，需要一个语音聊天的功能。这就是用户故事来描述用户需求的方法。
用户故事开发时长：开发一个用户故事的理想持续时长是2-5天。
用户故事3C：卡片card，对话communication，确认confirm. (罗恩•杰弗里斯提出的)
优先级排序技术MoScow
MoSCoW技术通常用在敏捷项目中，主要用来对用户故事进行优先级排列：
M-must have必须有：完成业务需要/价值所必须的功能，合规，安全等，没有要丢命。
S-should have应该有：不涉及核心功能，但是严重影响用户体验，没有要丢钱。
C-could have可能有： 影响不大，忽略也没有问题，没有可能会丢脸
W-won't have this time这次不会有：// 团队决定本次迭代不予实现，丢来没事。
解聚
将史诗故事或大型故事分解成小型用户故事。解聚类似于传统项目的分解。（史诗是大型故事的意思，实现的时候，要进行分解，分解的过程就是解聚）
燃尽图
项目的燃尽图是一个常用来展示迭代进度的信息发射源。它记录两项序列，横轴是时间，纵轴是剩余的实际工作和剩余的理想/预估的工作。
燃起图
与燃尽图相反，它的横轴是时间，纵轴是已完成的实际工作和剩余的理想/预估的工作。
累积流量图
展示用户故事的未完项、过程中的工作及完成功能与时间关系的一种图表，是信息发射源的组成部分。
