PMP-敏捷专题_思维导图模板

敏捷专题

敏捷原则与理念

PMP考试中的敏捷特点

题目场景50%是预测型，50%是由混合型和纯敏捷型组成

题目首先需要准确判断出题目场景，需要了解不用场景的特点和关键词

混合场景下不同角色的职责和定位（PM、PO、SM、开发团队）

混合型和敏捷场景下团队特点和PM领导风格

敏捷里的名词概念需要理解

敏捷的使用场景

敏捷的“洋葱圈”

敏捷宣言（2001年诞生）/四大价值观

敏捷软件开发宣言

个体以及互动

可用的软件

客户合作

应对变更

敏捷原则

1.我们最高目标是通过持续不断地及早交付有价值的软件使客户满意。

2.欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。

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

4.业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5.激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以新人，从而达成目标。【如何建设团队？】

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

7.可工作的软件是进度的首要度量标准

8.敏捷过程倡导可持续开发。责任人（项目发起人）、开发人员和用户要能够共同维持其步调稳定延续。【敏捷不鼓励加班，以工作效率衡量，不以工作时间衡量】

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

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

11.最好的架构、需求和设计出自自组织团队。【自组织团队：无领导、工作不一定在一起。团队建设初期不是自组织团队，通过发展成为自组织团队】

12.团队定期地反思如何能提高成效，并以此调整自身的举止表现。

子主题1

敏捷思维模式、价值观、原则以及实践之间的关系

在艾哈迈德·西德基 (Ahmed Sidky) 启发下提出的模式将敏捷明确表述为一种思维模式，它由《敏捷宣言》的价值观所界定，受《敏捷宣言》原则指导，并通过各种实践实现。

敏捷实践

Scrum体系

Scrum流程图

在一个迭代中，计划的范围不发生改变

3355结构

3种角色

产品负责人
（Product Owner PO）
权力相对较大的角色

客户代表

定义所有产品功能

决定产品发布的内容以及日期

对产品的投入和产出负责

根据市场变化对需要开发的功能排列优先顺序

合理的调整产品功能和迭代顺序

认同或者拒绝迭代的交付

确保开发团队知道产品待办事项列表

服务式领导/敏捷专家/团队促进者(Scrum Master SM)与PM项目经理

项目早期SM和PM相对统一（制定规则、管理期望、管理相关方、制定沟通策略、管理承诺等）

项目执行起来则SM与PM进行切割（SM不做决策）

鼓励言论自由

保证仪式

团队有问题，优先内部讨论解决

保护团队一个整体

职责

起到教练的职责

领导团队完成Scrum的实践以及体现其价值

开发团队(Dev Team DT)

自主选择

团队成员主动选择

全职能

团队成员自身能力可以跨专业和跨领域进行工作

跨团队本身不进行解决

若外部团队出现问题，将外部团队拉入自身团队内部共同解决问题

决策在团队内

平级

经典团队拥有5-9人

团队成员都是多面手

团队成员都是全职工作

团队自我组织和管理

团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整。

3种工件

产品待办事项列表（Product Backlog）
【排了序的需求池，包含所有需求，PO管理】
记录用户故事

产品需求的列表

包含业务需求、技术需求、NFR（非功能性需求）等

理想情况下，每一个待完成的工作都将对客户产生价值

PO对该列表进行优先级排序

每个迭代开始前，优先级排序还需要再度修正

待办事项列表中的条目以用户故事的形式呈现

符合的原则DEEP

Detailed 适当的详细程序

Estimated 被估算的

PO进行

Emergent 涌现的

Prioritized 排了优先级的

用户故事INVEST原则

独立的

可讨论的

有价值的

可估算的

小的

可测试的

迭代待办事项列表（Sprint Backlog）
【迭代完成的需求列表，一旦确定即锁死】
记录的是任务

Product Backlog的子集，只记录当前迭代的工作

将用户故事拆分成任务，团队成员主动领取任务

团队成员有共同的迭代目标，为交付可工作的成果而努力

团队成员可以添加、删减或者更改迭代中的任务

用户故事在一个迭代中是不允许添加、删减、更改

迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新

产品增量（Product Increment）
【交付物，潜在的可发布产品增量】

团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付

每次交付的用户故事必须符合验收条件

验收条件即DOD(完成的定义)

每次交付的增量成果必须处于可用状态（可以随时上线使用），而不管PO是否决定发布这个用户故事（交付和上线）

5种仪式（活动）

Scrum整个工作流

Sprint 计划会/规划会议

整个迭代的开始时进行迭代计划会，是迭代开始的标志

阶段

阶段一

选取用户故事，确定迭代目标

PO与团队一起从产品待办事项列表选择待完成的用户故事

阶段二

拆任务，创建迭代backlog

团队拆分和确认任务，给出工作量估算

1.确认做什么——做承诺

团队速率

固定时间内团队完成任务的规模

通常是单次迭代

团队速率不是越大越好，而是越稳定越好

团队比较不成立，但可以跨迭代比较，前提是统一基准

DOD（完成的定义）

核心就是做到什么样就是完成了

可以通过流程或者本身交付物来进行限定

探测 Spike

敏捷中使用的一种技术，一般情况下只用来判断可行性的，所有不确定的地方：风险、技术、商业模式等。

2.确认怎样做——拆任务

两周的迭代，2个小时选择故事，2个小时估算分配；1个月的迭代，4个小时选择故事，4个小时估算分配

每日Scrum站会
（开放式会议）

整个迭代中间过程进行每日迭代站会

不是为了解决问题

避免无关讨论

团队成员

昨天你做了什么

今天将要做什么

你有需要帮助的地方吗

用来在团队面前确认个人承诺

参与对象

PO、SM、DT（一定要去的）必须参加

鸡和猪都可以参加，但是只有猪可以说话。这个活动是用来做每日承诺的，而不是讨论会议。

PO、SM、DT是”猪“，具有发言权；其他人不具有发言权

输出

燃起图

燃尽图

更新

Sprint 评审会
（验收阶段）

整个迭代结束前倒数第二个进行迭代评审会，类似验收会议

团队需要演示所完成的迭代工作

典型的做法是

非正式的

2小时的准备

不需要正式演示文档

和外部交互的会议

原则上是计划会议时间的一半

这个活动输出的是一份修订的产品待办事项列表

这个活动在迭代最后倒数第二个去执行

这个是为了和利益相关方的步调一致

输出

修订的产品待办事项列表

可交付的软件

参会人员

PO一定参加

所有人

整个团队都要参加

邀请所有关注产品的人参加

Sprint 回顾会
（收尾阶段）

整个迭代结束时进行迭代评审会

除站会外时间最短的会议

这个活动在迭代最后执行

这个活动上写的是开发团队，产品负责人，SM，企业利益相关者整个团队

该会议只有开发团队和SM参与，其他人别来，封闭式会议

回顾会内容

代码评审

执行过程的活动和问题

制定出行动项

Sprint 迭代

1-4周

产品（需求）梳理会/待办事项列表细化会议
（不包含在5种活动中）

根据业务模型召开产品梳理会，在下一个迭代开始前进行，梳理下一次迭代的需求。

讨论新故事

PO梳理Product Backlog（DEEP）

内容

1.增、删、改、查用户故事

产品愿景——电梯演讲

用户故事

用户故事是一个表述用户需求的固定语法

作为一个<角色>，我想要<活动/功能>，以便于<商业价值/目的>。

识别用户需求——便利贴——用于看板或产品待办事项列表分析

3C原则

Card 卡片（记录位置）

Conversation 交谈

Confirmation 确认

验收标准

Acceptance Criteria

Given 在什么样的情景或条件下

When 做了什么操作，采取了什么行动

Then 得到了什么结果

用户故事地图

绘制用户故事地图，需要召开一次用户故事会议

参加会议的人员必须是各岗位的关键角色

产品负责人

项目负责人

业务负责人

技术人员

老板

参会人数

控制在7人以内，不少于3人

横轴

业务流程，从时间维度用户使用产品的一般顺序

竖轴

故事的颗粒度的大小，由上到下，按一级故事、二级故事、细节故事分解

商业价值，商业价值高的故事排在上面，并且优先级发布。其中”发布1“是MMR最小可发布版本。

2.估算规模

估算——相对概念

敏捷估算基本上都建议使用相对估算法，也就是通过一个基线，其他被估算的事物与基线进行对比，尽可能不使用绝对估算来进行估算。

基线选择相对较小，而不是绝对小的

类比估算使用在相似的任务上，可用来复制基线

3.故事优先级排序

优先级

以价值来分析优先级

交付成本

延迟成本

延迟做该事情造成的成本

ROI

技术

MoSCow技术

Must Have 必须要有的

60%

Should Have 应该要有的

20%

Could Have 可以要有的

20%

Wonnot have this time

一个迭代内的组装
符合“高速公路理论"

Kano模型

基于客户兴奋点对用户故事进行优先级排序

相对量级（权重分析）

1、将所有成功的收获和制约因素均进行罗列

2、分析每一项影响的大小和范围

3、重点关注做带来什么收益、风险、问题，不做带来什么收益、风险、问题。

4、每一个都打个分

5、基于得分高低获取优先级

4.拆解用户故事

5.可以邀请利益相关者来进行参与和评审

PO、SM、DT一定参与

6.可以有技术相关的讨论

输出

敏捷中的计划

发布计划

发布燃尽图

针对整个项目，以迭代为时间维度

条形燃尽图

累计流量图

利特尔法则

平均吞吐量=在制品/前置时间（不考该公式计算）

Kanban中常用

用户故事地图

产品路线图

MVP（三个最小）

最小可交付价值

最小可售单元

最小可行性产品

MVP原则

用最少的资源、最短的时间做试验，获得早期用户的反馈，验证产品的价值。

MVP方法

视频

仿真

众筹

原型

预售

访谈

迭代周期

2-4周期

固定时间、固定活动

优势：专注、增加创造力、时间的价值实现程度更高、可用时间

5种价值观

承诺

专注

勇气

开放

尊重

三支柱

透明

信息透明

检视

检查结果/过程

适应

精益与Kanban体系

看板

区分看板与Kanban系统

看板是用来进行透明的，对于管理干系人的希望有促进燃尽图、燃起图、看板或任务版、风险看板等。

Kanban系统

1.工作流程可视化

2.限制在制品数量

3.度量和管理流动

4.显示化规则

5.建立反馈环路

重点关注：Kanban没有时间箱的概念

敏捷方法和看板方法视为精益方法的子集，都是精益思想的具体实例，都反映了“关注价值”“小批量”“消除浪费”等概念。

“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语，图 2-4 结合上下文将敏捷定位为一个总称，它指的是符合《敏捷宣言》价值观和原则的任何方法、技术、框架、手段或实践。

可通过两种策略践行敏捷价值观和原则

策略1：采用正规的敏捷方法

策略2：以一种适合项目背景的方式对项目实践进行变更，以便在核心价值观或原则方面取得进展。

其他常见单团队敏捷实践

极限编程

定义

极限编程（XP）是一种基于频繁交付周期的软件开发方法

基于理念

将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践。

重点实践

持续集成

CI的工作流程（了解）

提交代码到代码库

CI server监听代码库的变更

CI server触发自动化构建

CI server触发自动化测试

通知相关方

TDD（测试驱动开发）

先写测试用例，再编写开发代码

结对编程

两个人在同一物理空间做同一件事

好处：老带新、技能复制、攻坚

坏处：成本增加

代码集体所有权

小型发布

常考点

结对编程

水晶

一种方法论家族

Scrunban

功能辅助开发（FDD）

动态系统开发方法(DSDM)

敏捷统一过程（AgileUp）

敏捷生态

敏捷团队管理

敏捷变更

跨迭代进行变更，一个迭代内尽量不变更

变更内容

需求

人员

环境

计划

团队组建

阶段

形成阶段

震荡阶段

规范阶段

成熟阶段

团队状态

业绩

新人员加入，团队从形成阶段开始发展至成熟阶段，阶段不可缺少，每次仅发展时间不同

团队领导

共享式领导

支持活动和指导活动均具备

指导型

领导对象：热情高涨的初学者

领导决定

应用于形成阶段

教练型

领导对象：憧憬幻灭的学习者

我们一起探讨，领导决定

应用于震荡阶段

支持型

领导对像：有能力谨慎执行者

我们一起探讨，我们一起决定

应用于规范阶段

授权型

领导对象：独立自主的完成者

应用于成熟阶段

团队成员决定

敏捷团队领导推动成员自主工作，传统团队领导是领队，拉动成员工作。

服务式领导

帮助团队＞命令团队、移除障碍＞创建阻碍、保护团队＞干扰团队

敏捷创建的是自组织团队，所以管理基于团队，不基于任务。

团队应该在一起

PMP-敏捷专题

模板简介

猜你喜欢

相关文章