PMP 敏捷知识点整理
敏捷宣言
个人与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵守计划以人为本,交付价值,拥抱变化,持续改进
敏捷十二原则
`交付价值`
1、我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
2、可用的软件是衡量进度的首要度量标准。
3、要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
4、对技术的精益求精以及对设计的不断完善将提高敏捷性。
5、简洁，即尽最大可能减少不必要的工作，这是一门艺术。
`以人为本`
6、敏捷过程是提倡可持续的开发，项目发起人，开发人员和用户应该始终保持步调稳定。
7、项目实施过程中，业务人员与开发人员必须通力协作。
8、要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
9、无论是对开发团队还是内部，信息传递最具有效的方法都是面对面的交谈。
10、最佳的架构、需求和设计将出自于自组织的团队。
`拥抱变化`
11、欢迎对需求提出变更，即使在项目开发后期也不例外，敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
`持续改进`
12、团队要定期反省怎么做才能最有效，并相应地调整团队的行为。
Scrum 方法的敏捷角色
- 产品负责人（需求方）
- 理战略: 制作产品路线图
- 定需求: 增加、调整用户故事、根据商业价值对用户故事进行排序
- 做验收: 项目成果的评审反馈
- Scrum Master
- 保护: 保护团队不被中断
- 保障: 移除障碍
- 保持: 通过项目和团队章程，保持持续引导项目愿景
- 保姆: 为团队提供支持
- 团队
- 虚拟团队: 鱼缸窗口和远程结对
- 工作区域: 私人区域和公共区域
- 渗透式沟通
- 全职的通才跨职能自组织团队
敏捷项目交付方法
- 精益
- Less
- Scrum of Scrums
- DSDM
- FDD
- 看板
- XP
- Scrum
- SAFe
看板
XP
其他技术实践
Scrum 管理框架要素
- 产品待办列表，也叫用户故事集，每个需求都是一个用户故事。
用户故事三要素：
1、作为<角色>，在<时间/地点>,我想<做什么>，是为了<什么目的/商业价值>
2、于是，我<怎么做/怎样操作>
3、最后<如何验证> - 产品待办梳理会
- 内容：把当前产品的需求清单进行梳理，包括排优先级、拆成粒度适中的故事卡片等。
- 时间：两周的冲刺用1小时的时间讨论
- 与冲刺规划会议的关系：只有产品待办列表梳理会完成，冲刺规划会议才能开始
估算用户故事
- 故事点估算
- 扑克估算
- T-SHIRT 规模估算
- 亲和规模估算
评估用户故事优先级
- 莫斯科法(MoSCoW): M必须有, S应该有,C可以有, W不会有
- Kanno 模型: 基本需求、性能需要、愉悦需要
- 100点法: 分给每人100点，他们可以使用这些点给最需要的需求投票
- 相对量级: 根据客户的判断，按照产品的特性价值最大化来排序
估算团队速率
敏捷进度计划
传统：通常制定出1-2层进度计划
敏捷：制定出多层进度计划
冲刺规划会
敏捷：制定出下一轮冲刺计划，描述冲刺如何开展
传统：制定出项目管理计划，详细描述项目如何开展
- 前半部分：团队向产品负责人询问待办列表的内容、目的、含义及意图
- 后半部分：团队计划本冲刺的安排
- 把用户故事继续分解为活动
- 团队成员确定活动分工
项目工作监控
敏捷：自承诺+自组织
传统：监督+控制
每日站立会
Scrum 任务板
燃尽图、燃起图
风险燃尽图
项目或阶段收尾
敏捷：冲刺评审验收
传统：项目评审验收
经验教训总结
敏捷：冲刺回顾会议
传统：总结经验教训
敏捷转型原则
考点
错题
