pmi-ACP考试知识点梳理（部分）

敏捷宣言

• 个体和互动 高于流程和工具
• 工做的软件 高于详尽的文档
• 客户合做 高于合同谈判
• 响应变化 高于遵循计划

十二条敏捷原则

1 咱们最重要的目标，是经过持续不断地及早交付有价值的软件使客户满意。

2 欢迎需求变化，即便在开发后期也同样。善于掌控变化，帮助客户得到竞争优点。

3 常常地交付可工做的软件，相隔几星期或几个月，倾向于采起较短的周期。

4 业务人员和开发人员必须天天在一块儿工做。

5 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们可以达成目标。

6在团队内部，传递信息效果最高效的方式是面对面的交谈。

7可工做的软件是进度的首要度量标准。

8 敏捷过程倡导可持续开发。责任人、开发人员和用户要可以共同维持其步调稳定延续。

9 对技术精益求精，对设计不断完善，将提升敏捷能力。

10 以简洁为本，极力减小没必要要工做量。

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

12 团队按期地检讨如何能提升成效，并由此调整团队的行为。

相互依赖声明(Declaration of Interdependence)

● 咱们经过创造咱们关注的持续价值流来提升投资回报率。

● 咱们经过与客户频繁的交互和分享全部权来交付可靠的结果。

● 咱们认可不肯定性，并经过迭代、规划和适应来管理它。

● 咱们经过认可我的是价值的最终来源、创造使他们有所做为的环境来激发创造力和创新力。

● 咱们经过团队结果问责制和团队职责分享制来提高绩效。

● 咱们经过因地制宜地应用具体的策略、过程和实践来改进效率和可靠性。

敏捷术语和概念

敏捷最适合具备复杂要求和技术的项目

敏捷项目范围不固定，而时间和成本是固定的

敏捷使用自上而下的估计

敏捷文档一般勉强够用

敏捷有利于适应，而传统的管理方法有利于预期

敏捷挣值管理（EVM）用于价值跟踪报告，最好应用于迭代级别

积极倾听(Active Listening) - 经过如下步骤进行听力技能进步：

• 内部倾听(InternalListening)（这将如何影响我）
• 集中倾听(Focused      Listening)（他们真正想说的是什么）
• 总体倾听(Global      Listening)（注意除了所说的以外的其余标志）

适应性领导(Adaptive Leadership ) - 领导者必须适应形势，以最有效地领导

敏捷游戏（协做和创新游戏）

记住将来：用于视觉设定和需求启发的游戏

修剪产品树：用于以帮助收集和塑造需求的游戏

快艇/帆船：用于识别产品的威胁和机会（力量）的游戏

购买功能：肯定优先级的游戏

Bank-for-the-Buck：审视价值与成本的游戏

产品盒（Vision Box）：设计产品的虚拟盒子（肯定最重要的前3项工做）以肯定优先级

架构刺探(Architectural Spike) -源于极限编程模式中的技术探险，写足够的代码来探知某个新兴技术（或不熟悉的技术）的使用所可能带来的技术风险， 对于复杂的调研任务，架构Owner可能须要部分团队成员的配合，在Sprint中安排Spike类型的任务。

探针(Spike)- Spike是一种技术尝试，用于经过快速失败来下降风险。

燃烧率 - 每次迭代的人工（最大部分）和其余成本，用于准备预算或EVM

洞穴和公共区域（Caves and Commons）

公共区域(Commons)：为最大化渗透沟通而组织的共同工做空间

洞穴(Caves)：半私人空间，能够作电子邮件，打电话等，不被别人打扰

冲突级别(Conflict Levels)

1.Problem to Solve

2.Disagreement

3.Contest

4.Crusade

5.World War

构形成本模型（COCOMO） - 对已完成的软件项目的输入进行逆向工程，这些项目已知具体成本，以便对新项目进行估算。是普及程度比较高的一种自顶向下项目成本估算模型，是比较精确，易于使用的成本估算方法。

累积流图(CFD) -一个实践工具，能够帮助咱们看到WIP的状态、项目的步调、而且快速识别出交付时间存在的风险以及瓶颈。

周期时间(Cycle Time) - 将需求转化为生产所需的时间

决策谱（由Jim Highsmith提供） - 一种参与式决策制定工具，容许人们代表对决策的支持/保留。
Decision Spectrum (by Jim Highsmith) – a participatory decision making tool to allow people to indicate support/reservation for decision

DRY (don’t repeat yourself) –一种编程哲学，要求程序员不要重复相同的代码

经验过程控制(Empirical Process Control) –关于项目的决策是基于项目执行期间的持续观察和实验而不是预先计划

史诗故事(Epic Story) – 史诗般的故事是大型用户故事，能够分解为较小的用户故事，能够在产品backlog的底部找到

逃逸缺陷(Escaped Defect) – 客户发现的问题或错误，即逃过验证，验证和验收测试.

失败模式Failure Modes [by Alistair Cockburn]

• 犯错误Making      mistakes
• 喜欢保守地失败Preferring      to fail conservatively
• 发明而不是研究Inventing      rather than researching
• 成为习惯的生物Being      creatures of habit
• 不一致Being      inconsistent.

功能缓冲区(Feature Buffer) – 用于管理风险，以确保能够提供必须具有的功能.

通才(Generalized Specialist) – 通才最适合敏捷团队，由于敏捷团队成员必须具备跨职能

基本规则(Ground Rules) –由ScrumMaster / Coach定义的规则，与团队达成共识，每一个人都必须遵照

强化迭代(Hardening Iteration) (Iteration H) –为产品准备产品的最后一次迭代，一般涉及最终测试，管理，文档

所见即所得(IKIWISI , I know it when I see it) –这是普通客户的典型，他们须要直观感觉产品以挖掘自身的需求。

信息发射源(Information Radiator )–显示项目进度和状态的高度可见的图表和数字，例如 看板，燃尽图。

Iteration Zero（迭代0） - 迭代1以前的迭代，用于建立Charter，征求要求或调研技术，作一些前期的规划和设计，包括一系列初始化工做 为后续迭代作好启动准备。

Kano分析：这是一种对用户需求分类和优先排序的有用工具，它将客户偏好分为4类。

• 兴奋（魅力）型需求—Exciters      / Delighters - 带来最大价值
• 满意者 - 带来价值
• 不满意 - 若是不存在则引发不适
• 无差别型需求——Indifferent

精益投资组合管理(Lean Portfolio Management ) - 选择项目以最大化投资回报的方法

• 投资组合应包括最低市场特征（MMF），以便快速交付
• 尽可能减小在制品

最小化可交付的特性（MMF）-为最终用户提供价值的最小功能集. 一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护，（很像Scrum中的产品Backlog），但对队列的大小有严格的限制（James认为应该是两到三个，最多七个）。

渗透式沟通- 经过无心间听到其余人之间的对话而无心中获取有用的信息，当一我的提问时，房间内的其余人能够选择听或者不听——参与讨论或者继续工做。

帕累托原则 - 也称为80-20规则指出，对于敏捷项目，80％的最有用的功能能够在20％的努力中完成，强烈建议关注“20％”

参与式设计 - 经过积极让利益相关者参与设计过程来确保结果符合预期的设计方法。

项目章程对于敏捷项目和传统项目都很重要，必须在敏捷项目开始时建立。

项目数据表（PDS） - 是全部关键业务和质量目标，产品功能和项目管理信息（包括里程碑，风险等）的单页摘要。

产品路线图(Product Roadmap) - 提供功能发布里程碑的高级概述。

重构 - 在不改变行为或效率的状况下提升代码质量

莫斯科原则MoSCoW

• 必须有的（基本功能）
• 应该有的（重要但短时间内有替代解决方案的功能）
• 能够有的（没时间就不考虑的）
• 此次不会有（客户指望拥有但同时认可须要在后续发布中实现的功能）

发布计划输出是：（进入首个 Sprint 阶段以前，须要举行一个发布计划会议）

• 发布计划
• 发布backlog
• 行动/行动项目
• 风险
• 假设
• 依赖

风险燃尽图 - 显示风险严重程度(severities)随时间的变化，风险一般随项目进展而降低

风险严重性(severities)=风险几率*风险影响

故事地图(Story Maps) - 显示每一个版本中用户故事/史诗的分类方式：

主线(backbone)：基本功能

行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集

附加功能：其余功能

隐性知识(Tacit Knowledge) - 是项目中无书面表达的信息和知识，不能/很难经过写下或用语言表达来转移给他人。隐性知识是高度个性化并且难于格式化的知识，主观的理解、直觉和预感都属于这一类。

团队造成阶段

• 组建期(Forming)[领导风格：指挥或告知Directing] – 项目小组启蒙阶段。
• 激荡期(Storming)[领导风格：教练Coaching] – 造成各类观念，激烈竞争、碰撞的局面。
• 规范期(Norming)[领导风格：支持Supporting]- 规则、价值、行为、方法、工具均以创建。
• 执行期(Performing)[领导风格：委任式Delegating] – 人际结构成为执行任务活动的工具。
• 休整期(Adjourning)      – 任务完成，团队解散。

技术债(Technical Debt)

技术债务 - 包含代码，技术文档，开发环境，第三方工具和开发实践方面的缺陷，这使得团队难以更改代码

经过简化或优化设计来下降技术债务能够提升生产率，从而提升速度

从理论上讲，XP项目不会产生技术债务，由于重构是一只进行的。

敏捷冲突的三步干预方法：

您是否与_________分享了您对此的疑虑和感觉？
_______应该知道你的担心。 若是我和你一块儿去，会有帮助吗？
我能够告诉_________你有这些顾虑吗？

三角测量(Triangulation) - 用户故事能够经过定义几个故事（各类大小）做为基线来估算. 三角测试是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。比较故事的故事点；列出全部故事的故事点，按故事点排列比较

角色(Persona) - 表示产品的一组典型用户

极端角色(Extreme Persona) – 极端角色，以识别用户故事，不然将被遗漏

用户故事 -意思是来描述用户渴望获得的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：须要完成什么样的功能或目标。
3.商业价值：为何须要这个功能，这个功能带来什么样的价值。
用户故事一般按照以下的格式来表达：

• 英文：As a      <Role>, I want to <Activity>, so that <Business Value>.
• 中文：做为一个<角色>, 我想要<活动>,      以便于<[商业价值]>

3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

• 卡片（Card）：用户故事通常在小卡片上写着故事的简短描述，工做量估算等。
• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认（Confirmation）：经过验收测试确认用户故事被正确完成。

用户故事的六个特性- INVEST：

- I dependent(独立的)

- N egotiable(便于沟通的)

- V aluable(有价值的)

- E stimable(可估计的)

- S mall(短小)

- T estable(可测试的)

速率(Velocity) - 衡量团队速度的指标（一轮迭代完成的故事点数），用于在迭代计划中建立项目进度表。

宽带德尔菲法（Wide band Delphi）- 一种生成估计的方法，涉及参与者之间比传统Delphi方法更多的交互和沟通。团队成员聚在一块儿演示用户故事，讨论面临的挑战，而后私下进行估算的一种估计技术。每一个故事的估算结果都会被匿名标注在图表上，而后团队就故事点范围进行讨论，并尝试达成广泛共识。

宽带德尔菲估计法创建在传统德尔菲技术基础上。具体方法是，在会议中，只讨论估计时可能会遇到的问题，估计自己和所花费的成本不作讨论。会议讨论后让每一个人分开，独自准备他们的估计，必定要注意，让每一个人作估计时远离群体。 接下来召回团队成员，聚集全部的估计，并在图表中画出来，展现价值的分布，但每一个估计都不写估计者的名字。而后团队再讨论存在估算差别的状况，并设法达成共识。

在制品（WIP） - 过多的WIP会下降效率，由于可能须要更多的返工。

小定律：循环时间与WIP的数量成正比

精益生产七大浪费(The seven forms of waste)：

• Transport
• Inventory
• Motion
• Waiting
• Overproducting
• Over      processing
• Defects

故事点估算：

• 计划扑克：须要整个开发团队参与，包括业务分析人员、开发人员以及测试分析人员，此外还包括Scrum主管以及产品负责人。开始讨论时，首先对产品积压工做上每一个用户故事做一些详细的介绍，而后要求每一个人用故事点数来给故事的大小投票。在一个单独的sprint内，当要估算的用户故事数目很少时，可使用计划扑克。
• 亲和估算：当用户故事数量比较多或者时间过短时的时候，是一种快速估算故事相对大小的方法。团队无需逐个讨论每一个故事，只须要从产品积压工做中提取两个优先级最高的故事并对比它们的工做量大小，而后将小故事的卡片放在桌子的左侧，大故事的卡片放在桌子的右侧。

产品待办事项(product backlog)的DEEP原则:

• 详略得当（D      etailed Appropriately）
• 作过估算的（E      stimated）
• 涌现的（E      mergent）
• 排列优先级的（P      rioritized）

敏捷项目团队规模：团队人数5-9人（不含PO和SM）