ACP敏捷知识点汇总

行 Scrum定义以及Scrum流行的原因

• Scrum理论以及三大支柱

• Scrum框架组成3355

• 三个角色

• 三个工件

• 五个会议

• 五个价值观

• DOD

Scrum是由Ken Schwaber 和 Jeff Sutherland 在1990年创建的主流敏捷技术。它是最受欢迎的敏捷技术，超过50%以上的项目在运用这项方法。

• Scrum不是开发产品的一种流程或一项技术，而是一个框架，在这个框架可以应用各种流程和技术，在这个框架中人们可以解决复杂的自适应问题。

• Scrum提供简单和可证明的结果、它包含其他敏捷工程技术、它强调小型团队和团队授权、欢迎需求的变更、它允许单一来源的优先项目工作开展、Scrum会议包括日常状态会议、提供团队在冲刺阶段一个潜在的可交付增量承诺

Scr基于经验型流程控制理论，或者称为经验主义。经验主义主张知识源于经验，而决策基于已知事物。

透明性：

• 过程或项目的各个方面必须是对结果负责任的，透明的；

• 运用信息发射源,让这些关键信息,如产品待办事项列表,冲刺待办事项、障碍、风险和项目进展对所有的利益相关者是透明的。

检视：

• 团队根据项目目标定期检查他们的绩效和进展；

• 他们不断寻找问题和计划的偏离。

调整：

• 基于观察期间的检查,采取必要的变更流程,以避免问题再次发生,提高项目交付成功率。

Scrum框架由Scrum团队及其相关角色、事件、工件和规则组成。框架中的每个模块都有其特定的目的，对Scrum的成功实施和运用都至关重要，而Scrum规则把事件、角色和工件组织在一起。

为了方便大家记忆，我们把Scrum概述为3355。就是

• 3个角色

• 3个工件

• 5个会议

• 5个价值观

有三种类型角色：

产品负责人：产品负责人定义项目愿景、需求和优先级，对产品成功负责。

Scrum Master：负责团队，并移除障碍，帮助他们实现产品负责人所设定的目标。

开发团队：自组织、跨职能。他们协同工作,以确定如何最好地满足产品负责人的目标。

团队中有“鸡”和“猪”的角色，“猪”的角色包括Scrum master，PO, team；“鸡”的角色是指团队成员以外的管理角色

俩个重要特性：跨职能和自组织。

自组织团队自己选择如何最好的完成工作，而不是由团队外的指导。

跨职能团队拥有完成工作所需要的全部技能，不需要依赖团队以外的人。

• 清晰地表达产品待办列表项

• 对产品待办列表项进行排序，最好地实现目标和使命

• 优化开发团队所执行工作的价值

• 确保产品待办列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作

• 确保开发团队对产品待办列表项有足够的理解

开发团队最佳规模是：足够小以保持敏捷性，足够大以完成重要工作。正常是7+-2，不建议小于3或者大于9。因为小于3可能会收到技能的约束，无法交付可发布的产品增量。大于9人的团队需要过多的沟通协调工作。产品负责人和sm不在这个范围内，除非他们也参与执行sprint代表事项列表中的工作。

有自主权选择如何最好地满足目标，并且为之负责。

Scrum Master负责确保所有人都能正确地理解并实施Scrum。因此，Scrum Master要确保Scrum团队遵循Scrum的理论、实践和规则。

Scrum Master是Scrum团队中的服务型领导。Scrum Master帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。

1）Scrum Master的职责是：

在项目生命周期早期定义基本规则；

确保团队理解干系人期望；

同团队沟通项目愿景，有利于确保团队；

认识到他们的目标同项目总目标紧密一致；

以连贯的单元模式工作；

对愿景给予承诺。

2）Scrum Master制定的基本规则包括：

设定Scrum仪式的开始-结束时间；

保持对主题的专注减少分散；

会议期间杜绝中断；

允许团队成员特别是初级成员言论自由；

在制定决策前应广泛搜集所有成员意见。

Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机会。Scrum中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。

① 产品待办列表（Product Backlog）-只有PO可以修改

② Sprint待办列表（Sprint Backlog）-开始后，只有团队可以修改

③ 产品增量（PSPI：Potentially Shippable Product Increment）-要满足完成的定义

冲刺计划会议：

Scrum团队的所有成员出席，在此次会议中,开发团队识别当前冲刺开发交付的产品待办事项中的故事。

这个会议时间箱为一个月的冲刺，会议时间8小时，4个小时用于选择故事和4个小时估算分配。

由Scrum Master和开发团队参加,产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议，用来分享迭代或迭代进展。

每个团队成员就他们将要完成的任务对其他人做口头承诺。

每个团队成员回答以下问题:

“昨天做什么?”

“今天将做什么?”

“遇到了什么问题?“

每日立会只有猪的角色可以发言，鸡的角色不可以发言这次会议时间箱15分钟,每天发生在同一时间和地点。

这次会议是由Scrum团队的所有成员参加。

开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。

Sprint评审会议的结果是一份修订的产品待办列表，确定很可能进入下个Sprint的产品待办列表项。

这个会议时间箱为一个月的迭代，4个小时，比冲刺计划会议的持续时间更短。

冲刺评审是在迭代末期进行的时间盒（有指定时间限制）会议，此时不断变化的解决方案展示给利益相关者，他们的反馈得到收集。

该会议是：

针对冲刺末期召开；

被时间盒定义到四个小时，按月冲刺和较短的时间段；

冲刺评审会议由包括开发团队，产品负责人，Scrum Master，和企业的利益相关者的整个团队出席；这些冲刺评审会议被团队通过录音、快照来展示产品。

是由Scrum团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括：什么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代，3个小时，比迭代评审时间短。

冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：

针对冲刺末期召开；

被时间盒定义到三~四个小时按月冲刺和较短的时间段；

由包括开发团队，产品负责人，ScrumMaster，和企业的利益相关者的整个团队出席；在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。

来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。细节包括：什么进行顺利，缺少什么，需要改变什么等等……

Scrum团队在冲刺中经常会面进行待办事项的梳理。

梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。

该会议有助于：

增加新用户故事；

丢弃不相关的用户故事；

估算新增加的用户故事；

重新估算用户故事；

对用户故事进行优先级重排序；

史诗分解成更小的用户故事。

需要记住的点：

梳理会议提供了调整估算范围的最佳时机；

利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理；

已经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相关者来评审；来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；识别出的现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。

开放Openness

专注Focus,

勇气Courage,

承诺Commitment,

尊重Respect

通过事先确定一个对“完成”的共识可以为团队与业务节约大量的时间来处理反差大、模棱两可或隐藏的工作。

这个定义也同时被用来指导开发团队了解在Sprint计划会议时能选择多少产品待办列表项。

每个Sprint的目标都是交付符合Scrum团队当前“完成”的定义的潜在可交付功能增量。

开发团队在每个Sprint都交付产品功能增量。这个增量是可用的，所以产品负责人可以选择立即发布它。如果开发部门制定了“完成”的定义作为规范、标准或者指引，那么所有Scrum团队都必须遵守；如果“完成”的定义还没制定，那么Scrum团队中的开发团队就必须制定符合产品的“完成”的定义。如果系统或者产品由多个团队开发，那么所有Scrum团队中的开发团队必须一起参与制定。

每个增量都添加到之前的所有增量上，并经过充分测试，以此保证所有的增量都能工作。

随着Scrum团队的成熟，“完成”的定义会扩大，包含更严格的标准来保证更高的质量。任何产品和系统都应该对在其上面开发的工作有“完成”的定义。

• 信息发射源

• 看板

• 燃尽图

• 障碍日志

• 可视化图表

• 速度

定义：一个信息发射源在任何人都可见的地方显示信息。有了信息发射源，大家不需要问任何问题。

有效的信息发射源

简单：易于掌握

突显：错误不应该掩盖,而是应该用于提高工作和性能

当前：展示的信息必须是当前的

转移：一旦问题被纠正,应该从图表中移除

影响：授权团队做决定

高度可见：容易看到和理解

最小的数量：关键信息应该被强调

信息发射源有助于对于成功验收、交付物的共识。

信息发射源用来促进干系人期望管理，对当下进行的工作可见、透明。

他们提供团队日常进展、工作质量、障碍和风险的视图。

看板是一个跟精益和及时制生产相关的概念

• 任务板被细分成段来反映关键活动。

• 故事是由索引卡或代表的便利贴来表示。

• 卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。

• 看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指

看板卡片

看板任务板上的每一张卡片就是看板卡片。

看板卡片用来显示迭代过程。

看板任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。

看板卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。

在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。

及时制在制造行业很流行。及时制强调只生产、开发、交付和消耗特定时间特定量的产品，而不是堆积工作流。

看板就是一种及时制系统，通过替换已消耗的资源来控制资源的流动。

通过可视化和展示即将在看板面板中强调的用户故事，产品负责人可以确保用户故事正在按照及时制原则来满足“准备好定义”。

这将确保团队已经就需求和验收标准达成共识。

看板或任务板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状态。

燃尽图

燃尽图

• 燃尽图显示在一次迭代或发布中的剩余工作量。这些图可以用来追踪实际速度和预期速度的对比，评估项目绩效。

• 燃尽图用来预测团队最可能的速度，团队按照这个速度去开发即将到来的冲刺或迭代交付物，从而促进有效计划。

发布燃尽图

项目组在迭代末期通过更新发布燃尽图来对比计划进展。

当曲线达到零，项目中没有更多的故事点，它已经准备好发布。

障碍特指阻碍团队实现冲刺目标的任何因素。

障碍日志的主要方面有:

Scrum Maters的主要职责是快速解决障碍，因为他们会直接影响团队生产力；障碍通过障碍日志得到展示，提供所有已解决和突出障碍。

可视化图表

 

 

 

可视化图表是信息发射源的一部分，同时也被引用为极限编程的一部分。

 

 

这些图表的特征有：

轻松便利地给团队和其他人提供信息；

随意，通常手绘、庞大、展示项目重要信息。

 

 

这些图表工作时：

团队停止阅读图表；

团队成员不再抱怨更新图表；

他们反映项目实际情况。

速度

 

 

 

 

速度是敏捷项目中运用的主要度量，用来预测交付期限，它通过给在迭代中团队需要完成的用户故事增加故事点来计算。

1、需要记住的点：

 

• 速度是团队每次迭代完成工作量的观察，而不是估算或目标；

• 速度是基于参考估算时间和团队规模而定，不是由时间或由团队成员以外的任何人来决定的；

• 速度是对特定项目特定团队的跨迭代比较。

速度举例

 

 

 

例1：团队完成了一次迭代中的4个故事，基于以下故事计算速度：

 

 

故事A-5 故事B-3 故事C-7故事D-5

速度等于每个用户故事所分配的故事点总和

所以例子的速度等于以上4个数字的总和：20。

未完成的用户故事不计入故事完成的点数

速度测量单元

 

 

 

速度测量单元

速度测量单元在估算会议期间确定。测量单元有：

故事点：如果团队基于相对规模来计划提交用户故事。理想时间：如果团队基于时间来计划提交用户故事。需要记住以下几点：

 

 

• 只有已完成的工作进行速度计算；

• 速度纠正估算错误；

• 速度追踪客户满意度；

• 速度追踪早期和持续交付。

三、敏捷团队 干系人

 

• 干系人管理

• 沟通管理

• 敏捷建模

• 积极倾听

• 全球化、文化和团队多样性

• 敏捷参与式决策

• 敏捷冲突与处理

• 敏捷团队

干系人管理

 

 

干系人是：

• 在项目中拥有股份的人；

• 项目成果对其利益产生积极或消极影响的人；

• 对项目有积极或消极影响的人；

• 有效的干系人管理是项目成败中最重要的决定因素，它可以通过有效和及时的沟通实现。

干系人管理10大原则

1. 干系人利益需要紧密相关；

1. 我们需要自愿精神去确保干系人参与而非组织监督来进行；

1. 我们需要自发去寻找能够让各种干系人满意的解决方案；

1. 我们所做的一切是为了服务干系人，我们从来不置任何其他一方干系人利益于不顾；

1. 我们行动的目的是为了实现我们对干系人的承诺，我们充满激情地朝着目标前进；

1. 我们需要密集沟通以及与所有相关干系人对话；

1. 干系人组成复杂；

1. 我们需要推广的营销方法；

1. 我们让所有主要和次要干系人参与进来；

1. 我们持续监控和重新设计过程去更好服务于干系人。

沟通管理

 

 

项目经理需要意识到影响项目成败最有价值的因素是沟通。

敏捷强调最有效的沟通是面对面，这将促进信任和双向沟通。

 

敏捷沟通

敏捷识别有效沟通的需要，同时提供丰富多样的工具和检查点来促进有效沟通。

这有助于避免目标和期望不匹配导致的项目错误。

 

促进持续参与和干系人有效合作的会议有：

每日站立会议；

评审会议；

回顾会议；

需求收集；

计划会议；

估算。

随着项目推进，持续检查干系人清单确保它符合当前现状和有效性显得非常重要。

同样，相关干系人必须参与到决策制定过程。

敏捷建模

 

 

敏捷建模指的是团队在实施前对过程或产品的工作流进行评审。模型可以是短暂的，自发的或一个原型。

 

 

敏捷建模促进：

提升干系人之间的沟通；

通过投入最少时间、降低成本去建立模型；在开发实际产品前管理期望。

模型需要刚刚好就可以，它可以只是一个白板上的图形描绘、纸模型、投影展示或流程图。

 

 

这些模型的重点不是完美，而是提供一个整体解决方案。

积极倾听

 

 

积极倾听是一种要求倾听者了解、解读和评估他们听到内容的沟通技术。

可以通过以下方式实现积极倾听：

• 给予发言者反馈；

• 解释他们所说的内容去确认各方的理解。

• 有效倾听的关键因素

• 集中注意力；

• 展示倾听手势；

• 提供反馈；

• 推迟点评；

• 做出适当反应。

全球化、文化和团队多样性

 

随着大部分项目正在从西方国家外包，全球分布式团队已成为当今一种常态。这将涉及处理文化、多样性、语言、表情和术语的差异。通信技术的进步使得这一切成为可能。

任何新组建的团队通常需要经历的阶段有：形成、震荡、规范、成熟、解散。文化多样性问题的建议

文化多样性在提升团队绩效的过程中会导致延迟和困难。

为了解决这些问题，有以下建议：

1. 项目周期的早期阶段制定出差预算，因此团队成员可以短期内在同一地点开展合作，并最大限度地减少意见分歧；

1. 开展面对面的项目启动会议，让团队能够彼此了解；

1. 开展面对面的发布计划会议，这是团队成员常规见面的最佳机会，提高团队凝聚力；

1. 开展文化培训，以便团队可以理解可接受和不可接受的行为；

1. 允许每个团队成员前往现场，给他们机会进行结对编程和极限编程技术，从而提高技术知识，减少文化差异。

敏捷参与式决策

 

 

敏捷参与式决策指的是团队参与决策制定的过程。目标是在项目中给项目社区提供具体实践去建立框架、分析和制定不同决策。

 

 

参与式决策的主要目标是

• 促进目标和限制因素的清晰沟通；

• 开放未开发的知识；

• 发挥组织的创造力和洞察力。

 

 

敏捷参与式决策模型

输入型：所有参与者有机会在决策制定过程中提供输入；

共享协作型：参与者不仅仅提供咨询参考，同时也要积极参与到达成决策的过程中。

命令型：决策由高级领导者或者一个小群体制定，团队成员被告知决定。

敏捷冲突与处理（一）

 

 

冲突的五层级

冲突是不可避免的甚至团队需要冲突。冲突的强度我们按照5个层级来区分：

层级1最低，层级5最高，冲突层级越高，越难达成友好协议。

 

 

第一层级：团队意识到有问题待解决，团队保持关注发生了什么改变以及如何去弥补。

第二层级：团队成员开始有异议和冲突，团队成员疏离，进入冷战模式。

第三层级：冲突变成竞争。人们开始寻找同盟，多种问题遗留未解决。关注点不再是解决问题、妥协，而是一定要赢。

第四层级：冲突演变为运动。带着正义和纠正的态度，团队成员认为冲突另一方不会改变，必须打倒。

第五层级：冲突演变成战争。没有建设性成果。

敏捷冲突与处理（二）

 

 

 

 

冲突层级	成功应对方案
层级1：问题待解决	合作：寻求双赢
	共识：综合各方需求，达成一致
层级2：异议	支持：授权他人解决问题
层级3：竞赛	包容：当关系比问题重要时，遵从他人观
	念
	谈判：如果冲突围绕着人们的价值观，这
	种方案无用
	事实依据：收集信息建立事实
层级4：运动	吸取第三方建议，将问题缓和。
层级5：战争	做所有必须的一切去阻止伤害

​

敏捷团队-塔克曼理论

​

敏捷团队-塔克曼理论

 

团队发展的五个阶段

形成阶段、震荡阶段、规范阶段、成熟阶段、解散阶段，所有五个阶段都是必须的、不可逾越的，团队在成长、迎接挑战、处理问题、发现方案、规划、处置结果等一系列过程中必然要经历上述五个阶段。

 

• 形成阶段 (Forming)项目小组启蒙阶段

团队成员互相认识，并了解项目情况及他们在项目中的正式角色和职责；团队成员倾向于相互独立，不一

定开诚布公。

• 震荡阶段 (Storming)出现各种观念，形成激烈竞争、碰撞的局面

团队开始从事项目工作，制定技术决策，讨论项目管理方法；如果团队成员不能用合作和开放的态度对待

不同的观点和意见，团队环境可能变得事与愿违。

• 规范阶段 (Norming)规则，价值，行为，方法，工具均已建立

在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员之间开始相互

信任。

• 成熟阶段 (Performing)人际结构成为执行任务活动的工具，团队角色更为灵活和功能化，团队能量积聚起来

进入这一阶段后，团队就像一个组织有序的集体那样战斗；团队成员之间相互依赖，平稳高效地解决问题。

• 解散阶段 (Adjourning) 任务完成，团队解散

在解散阶段，团队完成所有工作，团队成员离开项目；通常在项目可交付成果完成之后，再释放人员解散团队。

敏捷团队-高绩效团队（一）

 

高绩效团队可以定义为一小群具备辅助技能的人，他们致力于共同的目标，并为了实现绩效目标自主承担共同的责任。

 

高绩效团队（HPT）对于组织发展特别重要，在高绩效团队中团队专注于他们的目标去实现优越的商业成果。

 

高绩效团队主要特点

• 具备合适技能和积极性的人员；

• 承诺和有效授权；

• 建立信任；

• 胜于其他团队并超过预期；

• 保持可持续的速度去交付高质量软件；

• 一致性和可预见的速度；

• 具备技术水平和商业知识；

• 具备良好的沟通技巧。

 

虽然不是每个项目成员都能成为多面手，但是团队协同能力可以充分促进交付要求性能的提高。

敏捷团队-高绩效团队（二）

 

高绩效团队之多面手专家

高绩效团队的主要特征是拥有多面手专家。

多面手专家不仅仅在他们的核心领域具备专业知识，同时对于商业领域和技术领域也有广泛涉猎。在项目的不同阶段也许会需要一个只精通于该领域的专家，但是敏捷思维建议团队成员往多面手专家发展，比如同一个人可以肩负多个角色：项目的设计人员、开发人员、测试人员。这个灵活性有助于均衡人员资源的转移，创造高绩效跨职能团队。

 

高绩效敏捷团队将具有以下特征：

• 参与式领导力；

• 有效的决策；

• 开放和清晰的沟通；

• 价值多样性；

• 相互信任；

• 管理冲突；

• 清除目标；

• 明确定义角色和职责

• 协调关系；

• 积极的氛围。

敏捷团队-授权团队

 

 

 

授权团队会进行自我决策以适应管理的复杂性。敏捷强调具备授权和积极性的自我管理团队，他们将对项目成果充分负责。

授权是：

• 责任和所有权；

• 朝着共同目标独立工作；

• 理解为什么要做决策；

• 衡量决策对于所有干系人的影响；

• 创造更多权衡。

 

授权不是：

• 抛弃规章制度；

• 淘汰任何说不的人；

• 做其他人工作里有趣的部分；

• 不考虑他人的自由决策。

敏捷团队-团队空间

团队空间又称作“作战室”，指的是团队进行日常工作的环境。

 

糟糕的团队空间迹象

糟糕的团队空间会导致团队生产力下降。通常缺乏沟通被认为是项目失败的最主要原因。

 

糟糕的团队空间迹象如下：

 

• 团队成员间缺乏互动；

• 根据职位安排座位；

• 墙上陈旧的设备；

• 团队成员戴着耳机；

• 专注家具布局多于创建团队空间；

• 工作区缺乏信息发射源；

• 缺乏吸引力的空间。

 

关注点应该放在减少分散去避免沟通差距，以此来持续交付预期成果和价值。

敏捷团队-集中式办公

集中式团队在同一地点共同工作。集中式团队的特征如下：

每个团队具备所有需要的技能；

团队独立工作，合作式去协调工作。

 

集中式团队

• 团队成员全部在一个空间内，创建  作战室  ；
• 问题得到非正式的及时解决；

• 偶尔的互动会激发生产力；

• 团队基于冲刺目标来确定角色；

• 他们遵循  洞穴和共享  模式：
• 洞穴：用于进行电话，简短的会议，或用于集中团队成员；

• 共享：共享区域作为团队渗透式沟通的地方。

 

渗透式沟通

渗透式沟通指的是听到的信息在团队房间区域流动，其中一些被吸收，这是集中式团队带来的好处之一。没有障碍影响整个工作区域信息的流动。因此，在这样的环境中，渗透式沟通自然而然地发生。

敏捷团队-敏捷领导力

 

 

作为一名成功的敏捷领导：

• 行为模式：应该遵循一个领导者四大最有价值的特点：诚信，前瞻性，竞争力和激励性；

• 创建和传达愿景：一个领导者应该结合组织目标，确定未来明确的目标或愿景；

• 激发他人行动：一个领导者要建立信任树立合作，通过授权激发他人。

• 挑战现状：一个领导者应该通过挑战任务寻找创新方法来改变，成长。
• 定位合适的人，并鼓励他们：一个领导者应该认识到团队的贡献并肯定个人才能。

 

服务式领导力定位领导者作为推动者：

• 帮助团队；

• 移除团队面临的障碍；

• 给予他们需要的工具和技能去保护他们远离不必要的干扰。

 

敏捷服务式领导力

服务式领导力对任何项目都有价值，不管什么方法。而且在敏捷中它是必须的。

原因如下：

• 敏捷坚信自我管理的团队，他们不需要任务管理的帮助，但是需要帮助去凝聚、组建。

• 敏捷管理者用他们的行为去满足团队需要，同时愿意去帮助团队实现目标。

• 在敏捷团队中价值应该被珍视，包括信任、同理心、协作等。

四、敏捷方法和工具

 

 

• 项目规模测量

• 不确定性椎

• 优先级技术

• XP

• 价值流图

• Timebox

• 累计流图

• 敏捷问题检测

• WIP

项目规模测量-故事点

故事点是描述一个用户故事及其相关努力总体规模的测量单元。

1）故事点：

• 是相对测量；

• 用户故事的故事点互相进行对比；

• 故事点是团队运用计划扑克等估算技术确定的；

• 故事点对一个项目来说是独特的，不能同其他项目相比较。

2）分配故事点需要考虑的：

• 任务规模-故事规则取决于以下因素：复杂性、投入量、风险大小

• 相对价值-故事点是规模的相对测量，绝对值不是很重要。

• 估算-估算运用基准来完成，相对值被运用。

• 选取最小故事估算价值为一个故事点。

• 选取中等规模故事分配5个故事点。

3）故事点估算的步骤：

• 用户故事拆分为更小的功能，并确保每个故事具有投资属性。理想情况下，每个故事应该由1个人占用不超过2天的时间完成。

• 确定团队达成共识的故事作为基线，创建它的故事点价值。

• 将所有其他故事卡片同基线故事对比。

• 每次迭代末期，将故事点同故事卡片上记录的校准。

4）故事点之类比估算：

• 故事点估算可以通过对比来有效完成。类比估算中需要考虑：

• 将一个用户故事同其他故事对比

• 基于精确性，如果故事A同故事B类似，他们的估算也将类似。

• 创建多层面基准

• 当2到3个不同的规格设定为基准时，一个可能的比较是：故事A比故事B规格大，但是却小于故事C，如果故事C大，故事B小，那么故事A接近于中等规格。

项目规模测量-理想日

1）理想日估算将会回答实施故事所需时间的问题，它需要考虑：

正在进行的唯一任务；

没有中断；

所有需要的信息都可用。

一旦理想日估算达成，经过几天潜在干扰后它将被转化为实际时间。

在极限编程中，理想日被称为完美编程日。

2）在理想日估算被转化为实际时间时会遇到很多干扰，以下是影响理想日的因素：

培训、评审、采访、会议、电话、管理评审、邮件、bug修复、生病、示范

在正常的工作的8小时内，一个开发人员可能会只花5小时在编程工作上。然而，即使开发时间估算在8小时或1天的工作时间，实际时间也可能接近1天半时间。

 

故事点VS理想日（优点）

故事点

• 有助于驱动跨职能行为；

• 故事点估算不会衰变；

• 纯规模测量；

• 故事点估算时间很低；理想日

• 同样的团队内理想日有差异；

• 理想日在团队外部容易说明；故事点更加抽象；

• 理想日迫使公司面对浪费时间的活动。

项目规模测量-宽带德尔菲

1）宽带德尔菲技术用来收集关于项目规模的准确估算

• 项目经理选择一个估算团队，组织专家，通过一系列会议就估算达成一致。

• 在项目经理收集个人估算后将汇总发送给团队成员，估算匿名完成。

• 如果估算差异很大，另一次迭代（重新估算）进行。

• 缺点是相对常用估算技术例如专家判断、类比估算等，它要求更多精力和协调去进行估算。

2）宽带德尔菲的步骤

• 团队选择：选择负责估算的专家团

• 启动会议：计划启动会议去说程序和落地规则

• 个人准备：允许团队成员针对每个任务个人收集初始估算

• 估算会议：实施一系列迭代步骤组成的估算会议

• 配置任务：收集个人估算，编译最终清单

• 任务评审：评审估算程序、最终任务清单和假设的结果。

3）宽带德尔菲技术之计划扑克

计划扑克是宽带德尔菲技术的变化模式，整个团队协同合作估算每个用户故事需要的投入。在计划扑克会议中：

• 每个团队成员收到有编号的卡片，如果需要数字可以延伸；

• 产品负责人朗读每个故事卡片并回答团队问题；

• 每个团队成员评估故事所需投入以及运用相对尺码给故事分配点；

• 当Scrum Master要求时，每个人必须同时举起写有他们估算的数字卡；

• 如果这里有差异，团队成员要解释估算偏高或偏低的原因；

• 讨论后，团队成员重新估算直到达成一致。

项目规模测量-亲和估算

亲和估算是一种被团队成员用来估算大规模用户故事的技术。

1）亲和估算的优势：

• 快速简单；

• 决策制定过程透明可见；

• 它创造了一种积极合作的体验而非对抗性。

2）亲和估算的步骤

• 沉默的相对尺码

• 产品负责人提供产品待办事项

• 故事水平排列在墙上

• 团队成员考虑执行中的努力，对比墙上物品对每样物品进行规模定义

• 团队安静地执行以上步骤，不讨论技术或者特性问题

3）编辑墙

• 故事卡片的规格在这一步里编辑

• 基于设计讨论和其他团队成员的投入，故事卡片根据相对尺码移动

4）将物品置于相对尺码栏

根据团队决定使用的分栏命名，把相应的规模置于墙上。

5）产品负责人挑战

一旦团队完成估算，产品负责人可能会不认同某些估算，如果团队决定一个物品必须重新进行规模估算，它可以通过以下：

• 将它置于独立的墙上重新进行规模估算

• 立即同产品负责人决定新规模

6）储备数据

• 数据被记录和储备，意味着亲和估算流程的结束。

项目规模测量-T恤尺码估算

 

 

 

一种流行的敏捷相对估算技术：（中码，大码，加大码等）

1. 操作简单；

1. 介绍团队使用相对估算的好方法；

1. 亲和估算非常有效

1. 在进行用户故事估算前，每个T恤尺码的基准需要由团队决定。

不确定性椎

 

 

 

不确定性椎的图示

不确定性椎展示了估算准确性在不同阶段的提高：

​

优先级技术

 

 

优先级排序的重要目的是识别高价值特征（功能）并且使它们得到优先交付，这将有助于组织为客户提供最大价值。

 

优先级排序同样有助于：

• 决定团队开展工作的顺序

• 调整范围去满足预算或时间目标的同时保留一系列有用特征（功能）

• 决定迭代计划、版本计划和新需求进入

• 决定无价值的低优先级任务并避免团队去执行优先级要素

进行需求优先级排序时需要考虑的要素如下：

• 特征交付的财务价值

• 开发新特征的成本

• 开发新特征导致的风险

• 在开发新特征时团队获得的学习量

• 学习意义和新知识

优先级技术

 

 

产品负责人、商业干系人和团队必须对即将实施的技术以及每个与优先级相关的基本原理有清晰的认识。

他们需要关注和确保优先级的定义没有改变或者稀释项目过程。

以下是敏捷中运用的3种优先级技术：

• MoSCoW技术

• Kano模型

• 相对量级

备注：修剪待办事项是指持续对待办事项进行优先级排序的过程。

优先级技术-MoSCoW

 

 

 

 

动态系统开发方法（DSDM）是一种运用MoSCoW技术来进行

需求优先级排序的敏捷方法。

在这种技术下，需求基于以下方面排序：

• Must必须有-这些需求是强制性的

• Should应该有-这些需求不是强制性的，但是高度渴望的

• Could可以有-这些需求如果满足会很好

• Won’t不会有-当下可以不去满足，但是将来可以加入

在开始新一轮时间箱前，会有一个新的MUSTs加入。这些可能是新的需求，或者现有需求被调整优先级进而转移成为MUSTs.

优先级技术-Kano模型

 

 

Kano模型是由Noriaki Kano教授开发。该模型致力于满足需求确保客户满意。

用这种技术，需求根据以下几方面来进行优先级排序：

基本需要

性能需要

愉悦需要

Kano模型类别

 

Kano模型四个类别如下：

门槛（必须具备）：产品必须包含这些特征（功能）才算是成功的

线性或性能要求：客户满意度与特征（功能）成正相关，但并不是必须的

愉悦要求：这些特征（功能）提供极大的满意度，经常增加产品的额外价值，但是缺少这些特征（功能）不会使客户的满意度降到正常水平之下。

淡漠：这些特征（功能）对客户来说最不重要。他们将不会产生任何商业价值。

优先级技术-相对量级

 

 

相对量级技术由Karl Wiegers 开创。这种技术是基于成本、风险和处罚

后能提供最大益处的特征（功能）应该拥有最高优先级。

该技术的关键要素：

Ø一个特征（功能）的优先级和它提供的价值成正比，而和它的成本及

实施相关的技术风险成反比。

Ø每一类使用1-9的规模

Ø益处将反映特征（功能）如何体现价值，同时处罚将反映特征（功能）

缺失时客户体验到的消极感受

Ø此外，风险反映实施特征（功能）的挑战，成本反映实施该特征（功

能）的实际成本。

XP

 

 

该编程法用于：

快速响应需求变化的高成本；

建立强大的工程实践去提升软件质量。XP的软件开发方法引入了许多革命性的概念成为了现在的标准实践。例如：测试驱动开发、持续集成、迭代、用户故事

 

极限编程的5个核心原则

沟通

简单

反馈

勇气

尊重

 

极限编程实践

精细反馈：包括结对编程、计划游戏、测试驱动开发、整个团队；

持续过程：持续集成、重构或设计改进、小版本；

共同理解：编码标准、集体代码所有、简单的设计、系统隐喻；

程序员福利：可持续发展步伐。

价值流图

 

 

价值流图的流程

1. 价值流图是可视化的过程地图，又称为价值流程地图。价值流图流程如下：

1. 识别即将要分析的产品或服务；

1. 通过识别步骤、序列、延迟和信息流来创建当前过程的价值流图；

1. 评审地图去寻找延迟、浪费和限制；

1. 通过消除延迟、浪费和限制来创建未来即将实现的优化状态的价值流图；

1. 开发路线图去实现未来状态；

1. 计划在未来重审过程去持续校对和优化。

 

价值流图的步骤

1. 识别过程的开始和结束点；

1. 识别高层级步骤、库存和序列；

1. 识别支持群体和替代流；

1. 根据增值和非增值活动分类；

1. 消除或减少非增值步骤，优化过程。

Timebox

 

 

时间箱用来给活动设定固定的时限：

• 它让其他特征例如范围不同；

• 在时间箱里，如果有任务不能在时间箱内完成，他们将被顺延到下一阶段；

• 时间箱确定迭代和冲刺间的速度；

• 它常被用来scrum、冲刺、迭代等会议。

 

时间箱的最佳实践

• 时间箱可以有任何的持续时间：1年、1个月等等；

• 在时间箱的最低层次（15分钟）实现控制；

• 如果一个任务落后于进度，它将被顺延到下一个时间箱；

• 时间箱确定了迭代的长度，团队确认多少特性在那段时间交付。

 

时间箱的优势

• 专注：时间箱有助于在一段特定时间内专注当下手头工作；

• 增加创造力：确定固定时间，专注识别的工作有助于工作更加高效，同时有助于减少帕金森以及小学生定律的拖延症现象；

• 时间的价值实现程度：确定固定时间有助于识别在特定时间内完成的工作量减少荒废时间；

• 可用时间：有助于对于完成任务的可用时间有清晰认识。

 

帕金森定律：为了去填充可用时间，工作是会自动膨胀的。

小学生定律：人们总是习惯在最后期限前开始启动工作。

累计流图

 

 

累积流量图

累积流量图由精益思想的创始人Don Reinertsen和David Anderson引入。

累积流量图是追踪和预测敏捷项目的重要工具；它从不同方面描述工作：总范围、进行中和已完成的；相同的报告可以提供对于燃尽图、周期时间、在制品和瓶颈的洞察

 

累积流量图-小定律(又译:利特尔法则)

累积流量图有助于确定系统库存数量，小定律表明在一个既定的在制品水平，在制品与前置时间之比等于吞吐量。

​

敏捷问题检测

 

 

任何项目的成功都取决于团队如何迅速和有效地解决问题。通常，一个高度关注运营的团队不能做到发现和解决问题。

如果问题没有得到解决，它会随着时间持续增加导致延误和返工，从而破坏项目进度。

在敏捷中可以有各种各样的仪式或会议来识别和解决问题，然而以下会议专注问题检测：

每日站立会议：每日站立会议的第三个问题——“有没有障碍阻碍任务完成?”

冲刺回顾会议：敏捷有助于积极解决问题，确保及时决策让团队交付成果。

问题检测技术：

鱼骨图、5whys、控制图、前置时间和循环时间，漏筛缺陷、在制品

敏捷问题检测-鱼骨图

 

 

鱼骨图又称石川图或因果图：

它是一种快速有效识别问题或缺陷的根本原因分析方法，采取纠正措施的方法；经常同5whys工具结合起来使用；

适用于任何类型的问题，有助于识别问题的所有可能原因；用来识别过程领域促进改进；

在这种技术中，原因来自主要的类别，分支来自主要问题或效果。合成图之后形状类似于鱼骨。

鱼骨图图示

​

在制品（WIP）

 

 

在制品指的是团队已经开始进行但还没完成的需求。

敏捷原则建议受限需求成为在制品。一系列长的在制品清单导致：

• 沉没成本（投入的金钱没有产生任何价值）；

• 需求变更带来更多返工；

• 隐藏的问题区域导致找出问题变得困难。

看板任务板被用来对在制品数量进行可视化和限制管理，缺少它将导致：

• 团队试图去承担比实际能力更多的需求；

• 识别确定障碍变得困难。

下图展示了带有在制品界限设置的看板任务板，挑选的类别在制品设置为3，这表示，在任何时间点，团队要完成的卡片任务不超过3个。

​

五、敏捷项目 项目群

 

 

 

• 敏捷项目管理

• 敏捷项目计划的多层面

• 敏捷项目向组合级看齐

• 发布计划

• 敏捷产品路线图

目管理（一）

敏捷项目管理（APM）：由Jim Highsmith所著的一书敏捷项目管理，试图扩大敏捷技术为一个整体。

敏捷项目管理：

引入敏捷项目管理步骤同PMI所采用的项目管理步骤结合；调整传统铁三角强调价值和质量，创建敏捷三角。

传统铁三角：范围、成本、进度

敏捷三角：价值、质量、制约因素（成本、进度、范围）

敏捷铁三角：进度、范围、成本

敏捷项目管理还指出,价值是外在的，可通过交付功能来体现，质量是内在的。

项目管理（二）

敏捷项目管理框架

构想：确定产品愿景，项目范围，项目群体以及团队如何一起共事。

推测：开发基于特性的版本，里程碑和迭代计划去交付愿景。

探索：在短时间内交付已测试的特性，持续致力于降低项目的风险和不确定性。

适应：评审交付的结果，当前形势，团队绩效和必要的调整。

结束：结束项目，传递主要经验教训。

 

APM和PMBOK

Michele Sliger将敏捷项目管理框架同PMI项目管理知识体系对齐，具体如下：

启动过程组对应设想

计划过程组对应推测

执行过程组对应探索

控制过程组对应适应

收尾过程组对应结束

项目计划的多层面

敏捷项目中计划的多层面通过计划洋葱圈来表示。

最外层：战略层面。战略层面包含领导达成一致的整体商业目标和路线图；

第二层：产品组合层面。产品组合计划包含能实现战略规划愿景的产品；第三层：产品层面。产品计划包含产品负责人对于发布系统的演变计划；第四层：发布层面。发布计划考虑支撑产品计划的每次发布的可交付物和特性；

第五层：迭代层面。迭代计划考虑将特性转换成工作的任务，测试软件，发生在每个迭代的开始。

最里层：每日层面。日常计划由每日Scrum和工作活动组成。

向组合级看

敏捷项目支持项目组合的愿景和目标，可以持续数年。这是通过：主题和史诗，发布，迭代，用户故事来实现。

主题和史诗用来支持项目组合或者产品路线图的长远愿景；发布用来支持产品路线图；

迭代和冲刺支持版本；

用户故事定义迭代内容。

​发布划

1、发布计划表明团队在已识别的项目目标和限制因素下如何实现产品愿景。

发布计划传达了跟正在开发的产品相关的关键信息，它们将：

• 有助于产品负责人和团队去确定创造产品所需要的时间；

• 传达期望；

• 作为路标服务；

 

对于没有历史速度参考的新项目来说，发布计划的完成通过与类似项目比较，或者通过类比估算确定速度，或通过实施一些迭代来确定速度；

 

发布计划的目的是定义一个产品发布的版本或者一个具体可交付产品的增量。

发布计划有2个必须的关键信息：

• 制定发布计划的步骤团队的平均历史速度；

• 一个发布计划内的迭代次数。

​敏捷产品

 

产品路线图是用一个计划好的方法去帮助战略性规划和计划中重要产品里程碑的沟通。产品路线图：

1.是任何产品战略的组成部分；

2.为规划变更提供框架；

3.管理变更对产品的影响；

4.代表长远的产品愿景或者产品目标。

​六、敏捷精益价值观 原则

• 敏捷宣言

• 敏捷原则

• 精益7个原则

• Kaizen

 

2001年敏捷宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观:个体与互动 重于 流程和工具

工作的软件 重于 详尽的文档

客户协作 重于 合同谈判

响应变化 重于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

​敏捷原则

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

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

控变化

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

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

⑤ 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，

从而达成目标

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

⑦ 可以工作的软件进度的首要度量标准。

⑧ 敏捷过程提倡可持续开发，责任人、开发人员和用户要能够共同维持其步调稳定

延续

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

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

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

⑫ 团队定期地反思如何能够提高成效，并依此调整自身的举止表现

​精益7原则

F消除浪费：对客户没有带来价值的事务就是浪费

F增强学习：通过短期迭代周期、重构、集成测试和频繁的客户反

馈会议增强学习。

F较迟决定：管理不确定性的最佳方法是收集信息，最后的责任时

刻给予承诺，打破部件间的依赖关系。

F尽快交付：短期迭代或者小批量提供有价值的反馈机会，促进有

效的决策制定。

F团队授权：精益专注于团队，因为决策制定和管理的来源让团队

了解最佳选择和成本。

F建立整体：确保质量是嵌入在整个系统的，系统需要构建自动化

测试，安装和持续集成。

F目光长远，脚踏实地，快速失败，快速学习。

​kaizen

Kaizen-介绍

Kaizen是个日本词语，指的是持续改善的意思。这个技术被各行业组织

用来进行竞争策略开发。

Kaizen倡导个人在所有层面的广泛参与，每个人都被鼓励持续做出改进。

Kaizen原则之一是大成果来自于小改变，这有助于在减少浪费的同时提

高生产力、效率和创新力。

为了支持持续改进的概念，组织需要在培训、学习资料和持续监督上做投入。

 

Kaizen-主要方面

长远思考、减少浪费、高质量、低成本、授权、灵活实践、及时制、客户关注、团队工作

​七、风险管理

• 风险管理生命周期

• 风险日志

• 风险燃尽图

• 逐步减少风险

• 小试验-探测

​风险管理生命周期

1. 风险识别：在日常Scrum中，进行回顾、需求研讨、迭代计划和迭代评审。

1. 风险评估：捕捉可能性、影响。

1. 风险响应：回避、减轻、转移、接受。

1. 风险评审：在回顾会议中进行。

​第一步-风险

 

项目中的风险识别可以在以下阶段发生：

需求收集：团队和产品经理讨论新想法按照价值最大化风险最小化的方式去考虑和调整需求。

计划扑克：团队估算每个用户故事的相对规模。拒绝超过一定规模的用户故事有助于减少风险。

迭代或冲刺计划：团队识别、评估和响应风险。团队同产品负责人一起工作去最大

化产出，降低失败风险。

Scrum会议：团队识别风险和问题。团队成员增加风险到风险板，记录已获得同意

的响应计划。

迭代或冲刺评审：团队讨论风险。团队成员应该特别标注出成功的风险减轻、回避活动，同相关干系人分享。

回顾会议：团队讨论已成功处理的风险、风险再次发生的几率，在接下来的迭代和冲刺中风险减轻应对有哪些不同。

​第二步-风险评估

 

 

 

风险评估-风险板

风险板是用来提供风险对团队和相关干系人可见的信息发射源。

风险板提示了以下信息：

已识别的风险；

概率；

影响；

风险响应。

风险板应该作为日常Scrum或者冲刺迭代末期回顾的一部分来进行定期评审。

风险板举例如下：

​

​第三步-风险响应策略

 

 

 

1）回避：

改变项目计划，以消除风险或其存在的条件，或保护项目目标不受其影响，或对受到威胁的一些目标放松要求。

有些风险事件在项目早期发生，可以通过澄清要求、获取信息、加强沟通或取得专家意见等方法处理。

2）减轻：

降低不利风险事件发生的概率和/或影响，到可接受的临界点。

及早采取措施比事后努力弥补要有效得多。

3）转移：

将后果连同应对的责任转移给第三方承担，不是消除风险。

最适合用在财务风险上(如：票据贴现)。

总会涉及为风险承担支付保险费。

4）接受：

项目团队已决定不为处理某种风险而变更项目管理计划，或者无法找到任何其他的合理应对策略。

可以是被动或主动的。

被动地接受风险，只需要记录本策略，而不需要任何其他行动，待风险发生时再由项目团队进行处理。

最常见的主动接受策略是建立应急储备，安排一定的时间、资金或资源来应对风险。

​第四步-风险评审

在风险评审阶段，团队会面对评审突出风险，重新评估风险承受力，讨论风险响应有效性。

其成果可以用来细化总体风险管理策略。

风险评审核心关注点是：

积极风险通过每日scrum进行评审；团队需要提供风险管理过程的反馈；评审风险影响和项目风险实际情况。

风险评估的目的是使风险可见，定期监测它们，优先考虑风险问题，提高问责制，鼓励行动，跟踪和解决所有权和解决状态。

​风险燃尽图

燃尽图是一种描述项目风险趋势的简单的图形化风险指标。

燃尽图的特点是：

1. 这个表通过测绘迭代或时间风险承担总量以及风险普查的预期货币价值创建；

1. 项目过程中风险应该有一个线性下降；

1. 每次迭代应该通过交付用户故事来减轻或消除风险板上的风险。

​

​小试验-探测

 

 

 

探测是在极限编程中创新开发出来用于消除不确定性的工具。

探测是在一个时间箱限定的时间内通过学习特征、技术或者过

程来减少不确定性。这有助于更好地估算和开发即将到来的特

性或修复缺陷。

探测：

1. 有助于通过进行尽早的可能性假设来降低项目风险；

2. 应该要求最少的时间和努力，或者不超过2天的时间；

3. 应该通过在产品待办事项中创造一个故事来让它可见；

4. 必须谨慎使用,因为他们不创造故事点。

​8、答题技巧

 

 

 

• 答题技巧

考试中的敏捷团队是一个理想化的团队（团队的成员都是积极向上的，多职能的，都是能去主动领任务并积极完成的，站会都是积极参加的，团队内部是团结的，SM和PO是不会惩罚团队的，用温和的方式改善团队中出现的问题，用鼓励和支持让团队前进。）

1、牢记敏捷价值观、原则

2、太绝对的词要考虑仔细（参考英文作答，有时候可能是翻译问题）

3、团队可以决定很多事

4、站会不解决问题只暴露问题

5、回顾会，发现和解决迭代中的问题

6、两个选项都对，选最合适的那个

7、仔细审题，找到关键词

8、“协调”、“协商”、“讨论”、“鼓励”、“一起解决”、“指导”、“引导”、“教练”一般70-

80%是对的（具体问题具体分析）

9、“上报”、“管理”、“要求”、“必须”、“举报”、“解雇”、“竞争”一般70-80%是错的（具体问题具体分析）

 

【注意】我们考的是ACP，不是PMP，如果有两个选项你觉得都对，A选项偏传统，B选项偏敏捷，一定选B选项，不是说A不对，只是B更敏捷。大家在考试的时候，就题论题，只针对题目作答。不要发散思维，不要钻牛角尖。