敏捷PMI-ACP知识点梳理
最近在学习敏捷ACP，将个人学习的一些总结记录在这里，网上ACP资料不多，总结中的有些观点和翻译也只代表我自己的理解，转载请注明出处。
敏捷宣言
● 个体和互动 高于流程和工具(Individuals and interactions over processes and tools)
● 工作的软件 高于详尽的文档(Working software over comprehensive documentation)
● 客户合作 高于合同谈判(Customer collaboration over contract negotiation)
● 响应变化 高于遵循计划(Responding to change over following a plan)
12条敏捷原则
1 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2 欢迎需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。
3 经常地交付可工作的软件，相隔几星期或几个月，倾向于采取较短的周期。
4 业务人员和开发人员必须每天在一起工作。
5 激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
6 在团队内部，传递信息效果最高效的方式是面对面的交谈。
7 可工作的软件是进度的首要度量标准。
8 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9 对技术精益求精，对设计不断完善，将提高敏捷能力。
10 以简洁为本，极力减少不必要工作量。
11 最好的架构、需求和设计出自于自组织的团队。
12 团队定期地反省如何能提高成效，并由此调整团队的行为。
相互依赖声明 (Declaration of Interdependence)
● 我们通过创造我们关注的持续价值流来提高投资回报率。
● 我们通过与客户频繁的交互和分享所有权来交付可靠的结果。
● 我们承认不确定性，并通过迭代、规划和适应来管理它。
● 我们通过承认个人是价值的最终来源、创造使他们有所作为的环境来激发创造力和创新力。
● 我们通过团队结果问责制和团队职责分享制来提升绩效。
● 我们通过因地制宜地应用具体的策略、过程和实践来改进效率和可靠性。
敏捷术语和概念
- 敏捷最适合具有复杂要求和技术的项目
- 敏捷项目范围不固定，而时间和成本是固定的
- 敏捷使用自上而下的估计
- 敏捷文档通常勉强够用
- 敏捷有利于适应，而传统的管理方法有利于预期
- 敏捷挣值管理（EVM）用于价值跟踪报告，最好应用于迭代级别
l 积极倾听(Active Listening) - 通过以下步骤进行听力技能进步：
● 内部倾听(InternalListening)（这将如何影响我）
● 集中倾听(Focused Listening)（他们真正想说的是什么）
● 整体倾听(Global Listening)（注意除了所说的之外的其他标志）
l 适应性领导(Adaptive Leadership ) - 领导者必须适应形势，以最有效地领导
l 敏捷游戏（协作和创新游戏）
记住未来：用于视觉设定和需求启发的游戏
修剪产品树：用于以帮助收集和塑造需求的游戏
快艇/帆船：用于识别产品的威胁和机会（力量）的游戏
购买功能：确定优先级的游戏
Bank-for-the-Buck：审视价值与成本的游戏
产品盒（Vision Box）：设计产品的虚拟盒子（确定最重要的前3项工作）以确定优先级
l 架构刺探(Architectural Spike) -源于极限编程模式中的技术探险，写足够的代码来探知某个新兴技术（或不熟悉的技术）的使用所可能带来的技术风险， 对于复杂的调研任务，架构Owner可能需要部分团队成员的配合，在Sprint中安排Spike类型的任务。
l 探针(Spike) - Spike是一种技术尝试，用于通过快速失败来降低风险。
l 燃烧率 - 每次迭代的人工（最大部分）和其他成本，用于准备预算或EVM
l 洞穴和公共区域（Caves and Commons）
● 公共区域(Commons)：为最大化渗透沟通而组织的共同工作空间
● 洞穴(Caves)：半私人空间，可以做电子邮件，打电话等，不被别人打扰
l 冲突级别(Conflict Levels)
1.Problem to Solve
2.Disagreement
3.Contest
4.Crusade
5.World War
l 构造成本模型（COCOMO） - 对已完成的软件项目的输入进行逆向工程，这些项目已知具体成本，以便对新项目进行估算。是普及程度比较高的一种自顶向下项目成本估算模型，是比较精确，易于使用的成本估算方法。
l 累积流图(CFD) -一个实践工具，可以帮助我们看到WIP的状态、项目的步调、并且快速识别出交付时间存在的风险以及瓶颈。
l 周期时间(Cycle Time) - 将需求转化为生产所需的时间
l 决策谱（由Jim Highsmith提供） - 一种参与式决策制定工具，允许人们表明对决策的支持/保留
Decision Spectrum (by Jim Highsmith) – a participatory decision making tool to allow people to indicate support/reservation for decision
l DRY (don’t repeat yourself) –一种编程哲学，要求程序员不要重复相同的代码
l 经验过程控制(Empirical Process Control) –关于项目的决策是基于项目执行期间的持续观察和实验而不是预先计划
l 史诗故事(Epic Story) – 史诗般的故事是大型用户故事，可以分解为较小的用户故事，可以在产品backlog的底部找到
l 逃逸缺陷(Escaped Defect) – 客户发现的问题或错误，即逃过验证，验证和验收测试.
l 失败模式Failure Modes [by Alistair Cockburn]
- 犯错误Making mistakes
- 喜欢保守地失败Preferring to fail conservatively
- 发明而不是研究Inventing rather than researching
- 成为习惯的生物Being creatures of habit
- 不一致Being inconsistent.
l 功能缓冲区(Feature Buffer) – 用于管理风险，以确保可以提供必须具备的功能.
l 通才(Generalized Specialist) – 通才最适合敏捷团队，因为敏捷团队成员必须具有跨职能
l 基本规则(Ground Rules) –由ScrumMaster / Coach定义的规则，与团队达成共识，每个人都必须遵守
l 强化迭代(Hardening Iteration) (Iteration H) –为产品准备产品的最后一次迭代，通常涉及最终测试，管理，文档
l 所见即所得(IKIWISI , I know it when I see it) –这是普通客户的典型，他们需要直观感受产品以挖掘自身的需求。
l 信息发射源(Information Radiator )–显示项目进度和状态的高度可见的图表和数字，例如 看板，燃尽图。
l Iteration Zero（迭代0） - 迭代1之前的迭代，用于创建Charter，征求要求或调研技术，做一些前期的规划和设计，包括一系列初始化工作 为后续迭代做好启动准备。
l Kano分析：这是一种对用户需求分类和优先排序的有用工具，它将客户偏好分为4类。
● 兴奋（魅力）型需求—Exciters / Delighters - 带来最大价值
● 满意者 - 带来价值
● 不满意 - 如果不存在则引起不适
● 无差异型需求——Indifferent
l 精益投资组合管理(Lean Portfolio Management ) - 选择项目以最大化投资回报的方法
- 投资组合应包括最低市场特征（MMF），以便快速交付
- 尽量减少在制品
l 最小化可交付的特性（MMF）-为最终用户提供价值的最小功能集. 一个MMF是最小粒度且有商业价值的特性。MMF被放在一个队列中维护，（很像Scrum中的产品Backlog），但对队列的大小有严格的限制（James认为应该是两到三个，最多七个）。
l 渗透式沟通- 通过无意间听到其他人之间的对话而无意中获取有用的信息，当一个人提问时，房间内的其他人可以选择听或者不听——参与讨论或者继续工作。
l 帕累托原则 - 也称为80-20规则指出，对于敏捷项目，80％的最有用的功能可以在20％的努力中完成，强烈建议关注“20％”
l 参与式设计 - 通过积极让利益相关者参与设计过程来确保结果符合预期的设计方法。
l 项目章程对于敏捷项目和传统项目都很重要，必须在敏捷项目开始时创建。
l 项目数据表（PDS） - 是所有关键业务和质量目标，产品功能和项目管理信息（包括里程碑，风险等）的单页摘要。
l 产品路线图(Product Roadmap) - 提供功能发布里程碑的高级概述。
l 重构 - 在不改变行为或效率的情况下提高代码质量
l 莫斯科原则MoSCoW
- 必须有的（基本功能）
- 应该有的（重要但短期内有替代解决方案的功能）
- 可以有的（没时间就不考虑的）
- 这次不会有（客户期望拥有但同时承认需要在后续发布中实现的功能）
l 发布计划输出是：（进入首个 Sprint 阶段之前，需要举行一个发布计划会议）
- 发布计划
- 发布backlog
- 行动/行动项目
- 风险
- 假设
- 依赖
l 风险燃尽图 - 显示风险严重程度(severities)随时间的变化，风险通常随项目进展而下降
风险严重性(severities)=风险概率*风险影响
l 故事地图(Story Maps) - 显示每个版本中用户故事/史诗的分类方式：
- 主线(backbone)：基本功能
- 行走的骨骼(walking skeleton) Walking Skeleton：最小的功能集
- 附加功能：其他功能
l 隐性知识(Tacit Knowledge) - 是项目中无书面表达的信息和知识，不能/很难通过写下或用语言表达来转移给他人。隐性知识是高度个性化而且难于格式化的知识，主观的理解、直觉和预感都属于这一类。
l 团队形成阶段
- 组建期(Forming)[领导风格：指挥或告知Directing] – 项目小组启蒙阶段。
- 激荡期(Storming)[领导风格：教练Coaching] – 形成各种观念，激烈竞争、碰撞的局面。
- 规范期(Norming)[领导风格：支持Supporting]- 规则、价值、行为、方法、工具均以建立。
- 执行期(Performing)[领导风格：委任式Delegating] – 人际结构成为执行任务活动的工具。
- 休整期(Adjourning) – 任务完成，团队解散。
l 技术债(Technical Debt)
技术债务 - 包含代码，技术文档，开发环境，第三方工具和开发实践方面的缺陷，这使得团队难以更改代码
通过简化或优化设计来降低技术债务可以提高生产率，从而提高速度
从理论上讲，XP项目不会产生技术债务，因为重构是一只进行的。
l 敏捷冲突的三步干预方法：
您是否与_________分享了您对此的疑虑和感受？
_______应该知道你的担忧。 如果我和你一起去，会有帮助吗？
我可以告诉_________你有这些顾虑吗？
l 三角测量(Triangulation) - 用户故事可以通过定义几个故事（各种大小）作为基线来估算. 三角测试是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。比较故事的故事点；列出所有故事的故事点，按故事点排列比较
l 角色(Persona) - 表示产品的一组典型用户
极端角色(Extreme Persona) – 极端角色，以识别用户故事，否则将被遗漏
l 用户故事 -意思是来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能或目标。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达： 英文：As a <Role>, I want to <Activity>, so that <Business Value>. 中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>
l 3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
● 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
● 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
● 确认（Confirmation）：通过验收测试确认用户故事被正确完成。
l 用户故事的六个特性- INVEST：
- I dependent(独立的)
- N egotiable(便于沟通的)
- V aluable(有价值的)
- E stimable(可估计的)
- S mall(短小)
- T estable(可测试的)
l 速率(Velocity) - 衡量团队速度的指标（一轮迭代完成的故事点数），用于在迭代计划中创建项目进度表。
l 宽带德尔菲法（Wide band Delphi）- 一种生成估计的方法，涉及参与者之间比传统Delphi方法更多的交互和沟通。团队成员聚在一起演示用户故事，讨论面临的挑战，然后私下进行估算的一种估计技术。每个故事的估算结果都会被匿名标注在图表上，然后团队就故事点范围进行讨论，并尝试达成普遍共识。
宽带德尔菲估计法建立在传统德尔菲技术基础上。具体方法是，在会议中，只讨论估计时可能会遇到的问题，估计本身和所花费的成本不做讨论。会议讨论后让每个人分开，独自准备他们的估计，一定要注意，让每个人做估计时远离群体。 接下来召回团队成员，汇集所有的估计，并在图表中画出来，展示价值的分布，但每个估计都不写估计者的名字。然后团队再讨论存在估算差异的情况，并设法达成共识。
l 在制品（WIP） - 过多的WIP会降低效率，因为可能需要更多的返工。
小定律：循环时间与WIP的数量成正比
l 精益生产七大浪费(The seven forms of waste)：
● Transport
● Inventory
● Motion
● Waiting
● Overproducting
● Over processing
● Defects
l 故事点估算：
● 计划扑克：需要整个开发团队参与，包括业务分析人员、开发人员以及测试分析人员，此外还包括Scrum主管以及产品负责人。开始讨论时，首先对产品积压工作上每个用户故事作一些详细的介绍，然后要求每个人用故事点数来给故事的大小投票。在一个单独的sprint内，当要估算的用户故事数目不多时，可以使用计划扑克。
● 亲和估算：当用户故事数量比较多或者时间太短时的时候，是一种快速估算故事相对大小的方法。团队无需逐个讨论每个故事，只需要从产品积压工作中提取两个优先级最高的故事并对比它们的工作量大小，然后将小故事的卡片放在桌子的左侧，大故事的卡片放在桌子的右侧。
l 产品待办事项(product backlog)的DEEP原则:
● 详略得当（D etailed Appropriately）
● 做过估算的（E stimated）
● 涌现的（E mergent）
● 排列优先级的（P rioritized）
l 敏捷项目团队规模：团队人数5-9人（不含PO和SM）
个人总结，转载请注明出处 ：）
-
figure-it-out 转发了这篇日记 2018-12-26 17:13:02
