ACP敏捷知识点汇总

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

• Scrum理论以及三大支柱

• Scrum框架组成3355

• 三个角色

• 三个工件

• 五个会议

• 五个价值观

• DOD

Scrum源自 Ken Schwaber 和 Jeff Sutherland 于1990年创立的主要敏捷管理方法。目前最为流行的敏捷管理方法之一，在超过50%以上的项目中被采用。

Scrum并不是一种用来开发产品的流程或技术,而是一个框架,在一个框架中人们能够整合各种流程和先进技术来应对复杂的自适应挑战.

Scrum以其简洁明了且可验证的结果著称，并整合了多种敏捷方法论。它注重小团队协作并赋予决策权，对需求变更具有开放性。Scrum支持由单个来源主导的工作项目，并定期召开状态会议作为其核心组成部分。此外，该方法ology确保团队在冲刺阶段能够实现一个明确的产品增量目标。

Scr遵循经验型流程控制学说，亦即经验主义学派。该学派认为知识来源于实践，并在其决策过程中依据既有的物质基础进行操作。

透明性：

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

通过这一机制向所有相关方提供透明的信息,包括产品待办事项列表、项目中的关键任务、潜在障碍以及项目进展等

检视：

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

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

调整：

依据观察时间段内的检视,遵循既定的改进程序,从而防止类似问题再次出现,确保项目按时完成的质量水平。

Scrum架构包含Scrum团队及其相关角色、事件、任务和规范要素。架构中各个部分各自具有特定的目标，在推动Scrum成功实施与应用中扮演关键角色。而规范则将事件、角色与任务整合起来形成有机整体

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

• 3个角色

• 3个工件

• 5个会议

• 5个价值观

有三种类型角色：

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

Scrum Master 是领导团队的关键角色。他们的主要职责包括有效识别并解决潜在问题，并通过其专业技能和对项目的深刻理解来协助团队成员达成产品负责人设定的目标。

开发小组：自我组织化且跨领域协作。他们紧密合作，并共同制定最佳方案来实现产品的高质量交付。

在团队中存在两种不同的职位类别，在这种分类中，“猪”的位置主要负责项目协调与规划工作以及对项目的全面把控；而另一种则被称为“鸡”型职位，在这种设定下，“鸡”型岗位的主要职责则是对外部事务进行协调与沟通，并且能够有效整合内外部资源以推动整体工作进度。”

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

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

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

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

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

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

实现产品待办列表对所有员工公开、明确且明了，并以展示Scrum团队的下一步工作任务。

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

理想规模应既小以维持敏捷性、又大以完成重要任务。通常在±2范围内（即5到9人）。建议避免规模过小或过大。较小规模可能导致技能限制、影响产品增量的交付。较大的团队可能面临过度沟通的问题（除非他们也被允许参与Sprint中的相关决策讨论）。

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

作为项目经理, Scrum 主导者负责确保所有相关人员都能正确理解和执行 Scrum 方法论. 因此, Scrum 主导者致力于使其团队遵循 Scrum 的理论、实践和规定.

作为 Scrum 团队的专业型指导者, Scrum 主管的主要职责是提供支持并促进团队协作. 通过帮助外部人员理解与 Scrum 团队交互的方式,能够带来积极的效果. Scrum 主管通过引导改进外部人员与 Scrum 团队之间的互动方式,从而最大化整个 Scrum 团队所创造的价值.

1**）Scrum Master的职责是：**

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

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

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

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

以连贯的单元模式工作；

对愿景给予承诺。

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

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

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

会议期间杜绝中断；

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

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

Scrum采用多种形式来展示工作任务与价值，并有助于提供清晰度，并为审视与优化工作流程创造了机会。Scrum中的工件设计旨在确保关键信息的高度透明，在此过程中所有参与者都应达成共同的理解。

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

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

增量产品（PSPI：可配送的拓展产品）-具体说明其定义

冲刺计划会议：

所有成员参与了本次会议，在会议上, 开发团队讨论了当前冲刺阶段的交付目标及相关的待办事项

这个会议日程旨在助力一个月的项目推进，在为期8小时的工作安排中主要用于故事筛选与资源分配估算。

包括敏捷项目经理和开发团队在内的参与者中,产品负责人可自主决定是否参与每日站会. 每日站会是一种高效专注型的会议,其主要目的是促进团队在项目周期内信息共享与协作.

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

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

“昨天做什么?”

“今天将做什么?”

“遇到了什么问题?“

每日立会仅限于某种特定角色可以发言，并非所有角色都可以。此次会议时长为15分钟，并固定在相同的时间与地点。

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

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

通过 Sprint 评审会议获得的结果是一份经过修订的产品待办列表，并确认可能成为下一个 sprint 的产品待办列表项。

该会议的时间安排系统设置为期一个月的版本更新周期，并采用4小时的工作时长配置方案；相较于 typical sprint meeting 的持续时长（通常为6-8小时），该方案显著缩短了会议时长

在迭代末期执行的时间盒会议（具备固定时间段），当项目进展到这一阶段时，会展示一系列不断更新的解决方案，并收集相关反馈信息。

该会议是：

针对冲刺末期召开；

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

冲刺评审会议由开发团队、产品负责人、Scrum Master以及企业的全体成员组成；这些会议通过录音和截图的形式展示产品状态。

由Scrum团队的所有成员参与了本次会议。本次会议的主要议题是回顾整个迭代过程。讨论内容涉及哪些方面能够顺利完成、缺少哪些关键点以及需要采取哪些优化措施等问题。各成员意见达成一致后确定未来改进计划。本次会议的时间安排为一个月周期内的一次迭代评审会时长仅需3小时比常规的迭代评审流程更为高效。

冲刺回顾是一种在迭代末期召开的具有明确时间段的项目回顾会议。其主要目标在于探讨团队如何能够进一步优化其工作流程，并就未来的预期改进计划达成共识。

针对冲刺末期召开；

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

由多角色组成的团队参加本次会议；在每日站会期间,参与者将识别出表现优异的领域以及需要优化的地方。

基于会议意见的反馈结果对于推行持续改进计划和提高团队产出效率具有重要意义。具体而言，哪些工作进展顺利？有哪些方面尚待补充？是否需要优化哪些环节？

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

分类处理待办事项的一种逐步优化方法不仅能够维持现有记录还充分考虑了相关方的需求

该会议有助于：

增加新用户故事；

丢弃不相关的用户故事；

估算新增加的用户故事；

重新估算用户故事；

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

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

需要记住的点：

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

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

已完成优先级排序及更新的产品待办事项应作为冲刺评审会议的一部分由利益相关方参与评审；来自运营与维护问题的反馈需予以考虑，并将新需求纳入产品待办事项列表；经分析确定的现有缺陷应在梳理会议上讨论。

开放Openness

专注Focus,

勇气Courage,

承诺Commitment,

尊重Respect

在团队内部预先达成关于"完成"的一致意见从而帮助团队与业务有效应对难度大、模糊不清或隐藏的问题能够节省大量时间

该定义也被用来帮助开发团队了解，在Sprint计划会议中确定或估算有多少产品待办列表项。

Sprint的目标是实现符合Scrum团队当前定义的价值增量

每个Sprint期间, 开发团队都会交付产品的功能增量. 这些增量均为可使用的状态, 并且因此可以由产品负责人立即发布. 若开发部门已制定了'完成'的标准作为指导方针或准则, 则所有Scrum组织内的开发团队均需遵循这一规定; 当'完成'的标准尚未确定时, 则需要由Scrum组织内的开发团队共同制定适用于该产品的'完成'标准. 若系统或产品涉及多个不同的组织进行研发, 则各相关的Scrum组织内的开发者需共同参与制定相应的规定.

每一个增量都被所有之前的增量所包含，并在经过全面测试后，并由此确保所有的增量均能正常运行

随着Scrum团队的成长，“完成标准”逐渐变得更加严格，在项目执行过程中为了确保项目的成功实施而被提出并不断优化完善。每个产品或系统都应当对其上的开发工作设定明确的“完成标准”，这是保障项目顺利推进的重要前提条件。

• 信息发射源

• 看板

• 燃尽图

• 障碍日志

• 可视化图表

• 速度

一种信息发布装置能够在任何一个人均可看到的地方呈现信息内容。通过使用这种信息发布装置，人们不再需要提出任何问题。

有效的信息发射源

简单： 易于掌握

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

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

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

影响： 授权团队做决定

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

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

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

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

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

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

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

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

卡的状态基于其在任务板上的位置进行表示，并随着项目进展从项目启动至完成的过程发生变化。

看板有助于展示团队的工作流程以及后续的重点任务是什么，并促进团队进行自我指证和反思。

看板卡片

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

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

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

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

相关人员应在用户故事定义完成之前对其目标客户体验的关键阶段进行审查。

及时制在制造行业中被广泛采用。该制度专注于仅生产、研发、交付和使用特定时间段内特定数量的产品，并非积累 workflow。

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

产品负责人可以通过利用可视化工具和突出显示在看板面板上突出显示的用户故事来确保所有用户故事都能够符合"及时制原则"下的"准备好定义"要求。

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

看板或任务板在项目实施期间作为信息发射源被运用，在此过程中它们有助于相关参与者去了解当前的状态

燃尽图

燃尽图

燃尽图能够呈现一次迭代或发布中的未完成工作量。这些图表用于观察实际速度与预期速度之间的差异，并评估项目的整体表现。

燃尽图可用于预测团队预期的工作节奏。团队将以该速度推进即将开展的冲刺或迭代交付物，并通过优化工作安排确保整体效率。

发布燃尽图

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

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

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

障碍日志的主要方面 有:

Scrum Master的核心职能是迅速应对各种阻碍，在项目管理中其重要性不言而喻；所有的阻碍均可在每日阻碍记录中得以记录，并且会详细列出已解决及突出问题。

可视化图表

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

这些图表的特征 有：

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

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

这些图表工作时 ：

团队停止阅读图表；

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

他们反映项目实际情况。

速度

速度是敏捷项目中的一个重要指标, 用于估算项目的交付周期. 在每个迭代周期中, 团队需要完成的任务会被分配并累积一定数量的故事点, 这一过程有助于估算项目的整体进度.

1**、需要记住的点：**

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

速度取决于估算时间和团队规模，并不依赖于时间或其他任何人的决定。

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

速度举例

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

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

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

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

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

速度测量单元

速度测量单元

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

工作分解单元 (WU)：当团队以项目规模为基础来规划提交用户故事时.目标交付周期 (TDP)：当团队以特定时间段为基础来规划提交用户故事时.需要注意以下几点：

1. 应采用*工作分解单元 (WU)*来进行项目分解.
2. 应采用TDP来进行资源分配.
3. 需定期跟踪进度并根据实际情况进行计划调整.
4. 要按时达成既定的目标.

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

• 速度纠正估算错误；

• 速度追踪客户满意度；

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

三、敏捷团队 干系人

• 干系人管理

• 沟通管理

• 敏捷建模

• 积极倾听

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

• 敏捷参与式决策

• 敏捷冲突与处理

• 敏捷团队

干系人管理

干系人是：

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

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

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

在项目成功的关键时刻起着核心作用的关系管理是项目能否取得最终成功的关键要素。在项目实施过程中通过建立顺畅和协调的沟通渠道能够确保目标顺利达成。

干系人管理10大原则

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

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

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

我们所做的所有方面都是为了致力于服务于干系人；我们始终不考虑任何其他一方的利益。

我们的行动旨在实现与相关方的承诺；我们满怀热情地致力于朝着目标前进。

我们的行动旨在实现与相关方的承诺；我们满怀热情地致力于朝着目标前进。

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

2. 干系人组成复杂；

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

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

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

沟通管理

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

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

敏捷沟通

敏捷识别有效沟通的需求，并为其中的关键环节提供多样化的工具与关键点。

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

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

每日站立会议；

评审会议；

回顾会议；

需求收集；

计划会议；

估算。

在项目推进过程中，在定期核查关键相关人员列表的基础上以确保其符合当前状态和有效性的要求显得尤为重要。

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

敏捷建模

敏捷建模指的是团队在实施之前对过程或产品的 workflows进行评估。模型可以是临时的、自主生成或基于原型的设计。

敏捷建模促进 ：

提升干系人之间的沟通；

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

模型仅需刚刚好 即可完成构建,它可能只是白板绘制的图形.实体模型或投影展示的形式,并非必须具备复杂的结构.

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

积极倾听

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

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

• 给予发言者反馈；

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

• 有效倾听的关键因素

• 集中注意力；

• 展示倾听手势；

• 提供反馈；

• 推迟点评；

• 做出适当反应。

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

随着越来越多的项目选择将业务外包至西方国家，在全球范围内建立并维持远程团队已经成为现代企业管理中的常见做法。这意味着需要妥善处理文化差异、人员多样性以及语言和非语言交流的特点。得益于通信技术和信息传播速度的加快，在此背景下协调各项任务变得愈发可行。

任何新成立的团队一般都会经历初创期（即形成阶段）、阵痛期（震荡期）、规范化阶段（即规范期）、成熟期以及退出期（解散阶段）。对于文化多样性问题，则可以从以下几个方面入手进行建议：明确组织目标与价值主张...

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

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

在项目周期初期阶段规划好差旅预算，则可以让团队成员在短时间内聚集于同一地点进行协作，并最大限度地减少意见分歧。

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

为促进团队有效沟通而组织实体化形式的会议是团队成员间的定期交流时间之一。

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

给每个团队成员提供前往现场的机会,让他们有机会参与结对编程和技术研究,并帮助他们提升技术水平的同时缩小跨文化交流的障碍

敏捷参与式决策

敏捷参与式决策是一种组织通过过程进行集体决策的机制。其目标是促进项目管理过程中各利益相关者对框架、问题及各类决策问题的研究与规划。

参与式决策的主要目标是

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

• 开放未开发的知识；

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

敏捷参与式决策模型

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

共享协作型： 参与者不仅提供咨询意见，并且积极地参与其中以达成决策的过程。

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

敏捷冲突与处理（一）

冲突的五层级

冲突难以被完全避免然而，在某些情况下 ，团队恰恰需要通过建立适当的冲突来促进效率和目标达成。根据5个不同的强度等级进行划分

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

该团队认识到存在尚未解决的问题，并持续关注相关情况的变化及其具体变化情况，并采取行动来弥补。

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

第三层级： 冲突转变为对抗关系。在这一阶段中，各方开始寻求合作伙伴以应对复杂的局势。诸多问题未能得到妥善处理。这一阶段的焦点不再在于通过和平方式解决问题或进行妥协谈判，而是必须采取积极主动的姿态以确保自身利益的最大化。

第四层级： 冲突被转化为一种运动形式。秉持着正义与纠正的理念，团队成员认为对方势力若不改变，则不得不予以打击。

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

敏捷冲突与处理（二）

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

​

敏捷团队-塔克曼理论

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/WQzYtdwr0GUlOnAiCuJN2cyIB5hx.jpeg)

​

敏捷团队-塔克曼理论

团队发展的五个阶段

发展周期中的不同历史时期（包括：发展初期、动荡期、规范期、成熟期和解散期）是团队成长过程中必须经历的关键节点

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

团队成员彼此相识，并掌握项目情况及他们在项目中的正式角色和职责；在工作方式上趋于各自负责。

定开诚布公。

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

团队启动了项目工作，并制定了技术规划和管理策略；若团队成员未能以合作与开放的态度参与，则可能导致项目进度受阻。

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

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

在规范化的过程中，团队成员逐步开展协作以促进团队协作，并不断优化工作方式和行为模式。

信任。

成熟阶段*(Phase)** 人际关系网络成为推动工作完成的关键，在此期间，团队成员的角色分工更加明确且具有适应性；与此同时，在这一关键节点上, 团队整体的能量逐渐提升

进入这一阶段后，团队就像一个协调的团队一样高效行动；团队成员之间密切配合，在稳定和高效的模式下处理问题。

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

当团队进入解散阶段时，在项目结束之前首先完成了所有的各项工作任务；随后才从公司中调出所有员工并解散团队

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

高绩效团队可被视为一组拥有辅助技能的个人，他们朝着共同的目标前进，并以实现绩效目标而自主承担共同的责任。

在组织发展中，高绩效团队（HPT）扮演着关键角色。其中，在高绩效团队中，团队会围绕设定的目标去努力，并致力于取得卓越的经济效益。

高绩效团队主要特点

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

• 承诺和有效授权；

• 建立信任；

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

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

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

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

• 具备良好的沟通技巧。

并非所有团队成员都具备多面手能力；然而团队协作能力能够显著地推动交付目标的提升。

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

高绩效团队之多面手专家

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

多面手专家不仅在各自的业务核心领域掌握专业知识，在商业与技术等其他相关领域也有广泛的涉猎能力。在项目执行的不同阶段或许会有对某一特定领域的专业人士的需求出现；然而敏捷方法论建议从单一专业人才转向培养多面手型人才的策略：例如同一人可以同时担任多个岗位职责：如项目经理、开发工程师以及测试工程师等职位。这种灵活的分工模式有助于实现人力资源的最佳配置与调配平衡从而推动形成高效协作型的跨职能团队。

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

• 参与式领导力；

• 有效的决策；

• 开放和清晰的沟通；

• 价值多样性；

• 相互信任；

• 管理冲突；

• 清除目标；

• 明确定义角色和职责

• 协调关系；

• 积极的氛围。

敏捷团队-授权团队

授权团队能够自主做出决策以便应对管理中的复杂多变环境。
敏捷方法重视拥有自主权及积极进取精神的团队组织。
这些团队对于项目的成果负有完全责任。

授权是：

• 责任和所有权；

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

• 理解为什么要做决策；

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

• 创造更多权衡。

授权不是：

• 抛弃规章制度；

• 淘汰任何说不的人；

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

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

敏捷团队-团队空间

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

糟糕的 团队空间迹象

坏掉的工作环境会直接导致团队效率低下 。常见的原因是缺乏有效的沟通 影响了项目的成功。

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

• 团队成员间缺乏互动；

• 根据职位安排座位；

• 墙上陈旧的设备；

• 团队成员戴着耳机；

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

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

• 缺乏吸引力的空间。

将焦点放在降低分散程度以消除沟通鸿沟，并确保持续交付预期成果同时创造额外价值。

敏捷团队-集中式办公

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

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

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

集中式团队

• 团队成员全部在一个空间内，创建 作战室 ；

• 问题得到非正式的及时解决；

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

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

• 他们采用 洞穴与共享 模式：

  • 洞穴：主要用于电话交流、简短的沟通以及组织团队讨论会；

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

渗透式沟通

渗透式的沟通机制是指信息在团队内部不同区域间流动。其中部分信息得以吸收和整合，在没有阻碍的情况下，整个工作区域的信息流动畅通无阻。因此，在这种环境下，渗透式的沟通机制能够自然形成和持续发展。

敏捷团队-敏捷领导力

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

• 行为模式 ：领导者应具备有诚信前瞻性竞争力激励性的特质；

• 树立并传递理念 ：一个领导者应当与组织的发展目标相一致地制定战略规划；明确阐述未来的发展方向，并为其制定清晰的战略目标。

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

• 突破现状 ：一个领导者应当通过设定新的挑战去探索创新的方法以实现变革与成长。

  • 识别人才并给予认可 ：一个领导者应识别适合的人才并给予他们相应的认可。

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

• 帮助团队；

• 移除团队面临的障碍；

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

敏捷 服务式领导力

服务式领导力对所有项目都具有重要意义，并不论采用何种方法。而且，在敏捷模式下它是不可或缺的。

原因如下：

敏捷坚定地相信自我管理型团队的存在，在这些团队中无需借助任务管理工具来辅助工作流程的设计与执行；然而需要通过相应的机制来整合现有资源并组织起来以形成有效的团队协作。

敏捷管理者通过自身的努力和行动来满足团队的需求，并始终致力于协助团队达成目标。

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

四、敏捷方法和工具

• 项目规模测量

• 不确定性椎

• 优先级技术

• XP

• 价值流图

• Timebox

• 累计流图

• 敏捷问题检测

• WIP

项目规模测量-故事点

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

1**）故事点：**

• 是相对测量；

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

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

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

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

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

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

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

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

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

3**）故事点估算的步骤：**

用户需求被划分为更小的功能模块，并且每个功能模块都具有重要的投资价值。在最佳情况下，一个团队成员应能够独立完成一个功能模块所需的工作量，在两到三天内即可完成。

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

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

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

4**）** 故事点之类比估算：

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

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

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

• 创建多层面基准

在设定2至3个不同规格作为基准时,一种可能的对比方式是: story A在规模上大于 story B,但不超过 story C的规模.若 story C较大、而 story B较小,那么 story A则接近中等规模.

项目规模测量-理想日

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

正在进行的唯一任务；

没有中断；

所有需要的信息都可用。

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

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

2**）将理想日转换为实际工作时间的过程中会面临诸多阻碍因素，请问您了解以下哪些影响因素吗？**

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

一名开发人员，在通常的8小时工作周期内可能会将大部分时间投入到非编程活动中。然而，在估算的8小时或1天工作时间内，实际所需的时间往往接近一天半。

故事点VS理想日（优点）

故事点

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

• 故事点估算不会衰变；

• 纯规模测量；

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

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

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

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

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

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

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

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

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

该方法的不足之处在于相比其他常见估算方法如主观判断法、类比估计法等，在使用时需要投入更多的精力以及进行协调。

2**）宽带德尔菲的步骤**

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

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

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

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

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

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

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

计划扑克是一种基于宽带德尔菲技术的协作估算方法，在整个团队协同合作下进行每个用户故事投入的评估。在这样的计划扑克会议上，

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

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

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

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

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

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

项目规模测量-亲和估算

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

1**）亲和估算的优势** ：

• 快速简单；

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

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

2**）亲和估算的步骤**

• 沉默 的相对尺码

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

• 故事水平排列在墙上

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

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

3**）编辑墙**

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

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

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

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

5**）产品负责人挑战**

一旦团队完成估算任务，并且产品负责人可能会对某些估算结果提出异议，在这种情况下，则可以通过以下步骤来解决：

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

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

6**）储备数据**

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

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

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

1. 操作简单；

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

3. 亲和估算非常有效

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

不确定性椎

不确定性椎的图示

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

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/AaUyXHpi3WGJsN7vrfS46Z5FYjTt.jpeg)

​

优先级技术

优先级排序的主要目标在于识别并提取出具有重要价值的关键功能或特性，并将其赋予更高的优先级处理或更快地投入实际应用中。这将能够最大限度地提升客户体验和满意度。

优先级排序同样有助于：

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

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

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

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

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

• 特征交付的财务价值

• 开发新特征的成本

• 开发新特征导致的风险

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

• 学习意义和新知识

优先级技术

产品负责人、商业干系人以及团队成员需对即将推行的技术方案以及所有与项目优先级相关的基础原则拥有全面的理解。

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

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

• MoSCoW技术

• Kano模型

• 相对量级

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

优先级技术-MoSCoW

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

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

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

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

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

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

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

在启动新一轮时间箱之前, 将会有新增的一个MUSTs加入. 这些MUSTs可能是新增的需求, 或者是原有需求因被重新排序而导致转移成为MUSTs.

优先级技术-Kano模型

由Noriaki Kano教授开发的Kano模型旨在满足客户需求并力求使客户满意。

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

基本需要

性能需要

愉悦需要

Kano模型类别

Kano****模型四个类别如下：

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

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

愉悦要求：这些特征（功能）带来显著的客户满意度并通常会增加产品的额外好处或价值；然而，在缺少这些特征（功能）的情况下，则无法将客户的满意度维持在正常水平以下。

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

优先级技术-相对量级

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

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

该技术的关键要素：

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

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

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

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

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

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

能）的实际成本。

XP

该编程法用于：

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

构建完善的工程体系以提高软件质量水平。
其中包含测试驱动开发（TDD）、持续集成（CI）、迭代模型以及用户故事法等关键实践。
这些创新性方法被广泛认可为现代软件工程的标准做法。

极限编程的5个核心原则

沟通

简单

反馈

勇气

尊重

极限编程实践

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

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

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

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

价值流图

价值流图的流程

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

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

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

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

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

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

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

价值流图的步骤

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

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

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

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

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

Timebox

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

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

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

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

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

时间箱的最佳实践

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

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

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

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

时间箱的优势

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

• 提升创造力： 制定固定时间段的工作计划并专注于核心任务能够显著提升工作效率，并且能够有效降低因帕金森定律而导致的任务拖延与因"学生小"定律导致的学习拖延现象；

时间价值的实现程度：确定固定时间段有助于辨别特定时间段内工作的有效性，并防止工作量降低。

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

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

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

累计流图

累积流量图

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

该累积流量图可被用作追踪与预测敏捷项目的重要工具；该图表能够从多个维度反映项目状况：整体规模、正在进行的工作以及已完成的部分；同一份报告则提供了关于燃尽进度、周期长度、在制品数量以及关键瓶颈信息的关键见解。

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

累积流量图能够辅助确定系统中的库存总量，在物流管理理论中存在一个小定理指出，在制品数量与其生产周期长度的比例等于系统的吞吐能力。

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/rLhIFt27R1yXu95z4QYSsqdGjnZW.jpeg)

​

敏捷问题检测

任何项目的成功都依赖于团队能够快速且高效地解决相关问题 。通常情况下,一个高度关注运营的组织难以发现并解决相关问题。

若缺陷未被及时处理，则其将随着时间的推移不断累积并引发延迟与返修工作,最终影响整体进度目标

敏捷中的各种仪式活动和会议都用于识别与解决问题；然而这些会议专注于问题检测。

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

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

问题检测技术：

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

敏捷问题检测-鱼骨图

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

这种技术是通过系统地识别问题根源并采取纠正措施来实现核心问题诊断手段；通常与5whys工具配合使用。

适用于各个问题类型，并有助于发现所有潜在问题的原因；用于改善过程领域中的改进措施；

在该技术体系中, 由主要类别构成, 由关键问题或效果驱动. 其合成图形呈现类比于鱼骨状

鱼骨图图示

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/5BN0A4PbJSrGR6pxTtXuvnel13WK.jpeg)

​

在制品（WIP）

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

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

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

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

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

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

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

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

该图表呈现了配置有在制品界限限制的任务面板。选择的类别配置为3，则表示在任何时候团队最多只能处理3张卡片任务。

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/yiGJU5AHF718MdgnCQqEjVxXRcfo.jpeg)

​

五、敏捷项目 项目群

• 敏捷项目管理

• 敏捷项目计划的多层面

• 敏捷项目向组合级看齐

• 发布计划

• 敏捷产品路线图

目管理（一）

这本《敏捷项目管理》是由Jim Highsmith所著的，并致力于扩展敏捷技术作为一项整体。

敏捷项目管理：

整合敏捷项目管理流程与PMI所采用的项目管理流程相辅相成；优化以价值和质量为核心的传统三要素，并创建敏捷三要素。

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

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

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

敏捷项目管理还强调产品的价值体现为外部可感知的功能,可以通过具体的功能实现;质量则体现在系统的稳定性和可靠性上。

敏捷项目管理还强调产品的价值体现为外部可感知的功能,可以通过具体的功能实现;质量则体现在系统的稳定性和可靠性上。

项目管理（二）

敏捷项目管理框架

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

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

深入研究： 系统分析重点方向以确保特性及时交付；同时致力于有效降低项目风险及潜在不确定性。

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

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

APM****和PMBOK

Michele Sliger通过整合敏捷项目管理框架与PMI项目管理知识体系实现了系统的协调。

启动过程组对应设想

计划过程组对应推测

执行过程组对应探索

控制过程组对应适应

收尾过程组对应结束

项目计划的多层面

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

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

第二层：产品组合层面。

第5层：项目进度安排。 项目进度安排将功能转化为具体的工作内容，并采用质量检测工具进行测试作为每个周期启动的重要环节。

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

向组合级看

敏捷项目促进项目组合的愿景和目标得以持续多年。这得益于：主题、史诗、发布、迭代以及用户故事 的实施。

主题和核心策略 作为支撑项目组合或产品路线图的长远愿景基础；发布阶段 作为支撑产品路线图的关键节点；

迭代和冲刺 支持版本；

用户故事 定义迭代内容。

​发布划

发布方案通过展示团队基于已识别的项目目标与限制条件下如何达成产品愿景。

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

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

• 传达期望；

• 作为路标服务；

对于缺乏历史速度作为参照的新项目而言，在制定发布计划时可采取以下几种方式进行估计：基于类比分析、采用估算方法类比应用以及逐步迭代的方法。

制定发布计划的目的在于确定产品发布的版本号以及新增的功能内容

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

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

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

​敏捷产品

产品路线图是采用预先规划好的方案促进战略性规划和计划中重要产品里程碑的沟通 。产品路线图：

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

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

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

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

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

• 敏捷宣言

• 敏捷原则

• 精益7个原则

• Kaizen

2001****年敏捷宣言：

我们在实践中不断寻求提升软件开发效率的方式，在坚持自身专业发展的同时, 我们也致力于帮助他人成长。基于此, 我们确立了以下核心价值观:强调个体与互动的重要性, 超出对流程和工具的依赖。

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

客户协作 重于 合同谈判

响应变化 重于 遵循计划

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

​敏捷原则

我们的核心任务在于，在持续不断的过程中提前提供高质量的软件产品以确保客户得到满意的体验。

从容应对需求的变化，在开发后期同样如此。为了以客户为中心实现竞争优势，敏捷流程必须确保其稳定性和可扩展性。

控变化

③ 定期地交付功能完善的软件，并非连续无间歇性交付；相反，在每隔几周至几个月的时间间隔内进行迭代开发

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

激发或唤醒个体的内在潜能与热情，并以他们为核心建立项目... ，辅之于信任基础。

从而达成目标

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

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

敏捷方法强调可持续性原则，在此过程中, 责任人、开发人员与用户必须协同配合以确保工作节奏一致.

延续

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

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

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

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

​精益7原则

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

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

馈会议增强学习。

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

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

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

效的决策制定。

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

了解最佳选择和成本。

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

测试，安装和持续集成。

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

​kaizen

**Kaizen-**介绍

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

用来进行竞争策略开发。

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

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

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

为了促进持续改进理念的实施, 组织应当在培训、学习资料和持续监督方面做出投资

**Kaizen-**主要方面

战略眼光得以树立。
资源优化举措到位。
高品质服务可达标准。
低投入方案可行。
赋予权限方能操作。
弹性执行策略可循。
快速响应机制建立。
服务意识强之公司具优势。
团队协作能力强之组织具优势。

​七、风险管理

• 风险管理生命周期

• 风险日志

• 风险燃尽图

• 逐步减少风险

• 小试验-探测

​风险管理生命周期

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

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

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

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

​第一步-风险

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

需求收集：团队和产品经理探讨新的创意方案采用价值最大化风险最小化的方法来分析并优化需求。

计划扑克： 采用计划扑克法时，团队会通过相对规模评估每个用户故事，并将其归类为特定的方法论名称。避免接受过于庞大的用户故事能够有效降低潜在风险。

迭代或冲刺计划： 团队通过筛选潜在问题、审查当前状况并及时应对挑战来制定策略；团队将与产品负责人密切合作以最大限度地推动项目进展

化产出，降低失败风险。

组织团队在Scrum会议上识别潜在的风险与问题，并将这些信息更新至风险登记表中。随后由相关责任人确认并记录各方的意见

的响应计划。

迭代或冲刺评审： 团队面临潜在风险进行讨论。要求团队成员详细记录成功机会降低及需避免的相关活动，并与相关方进行分享以确保信息透明度。

会议回顾： 团队已在本次会议期间讨论并解决了当前存在的各项风险问题，并明确了未来可能再次发生的风险及其概率，在迭代阶段和冲刺阶段分别采取哪些措施来降低这些潜在风险。

​第二步-风险评估

风险评估**-风险板**

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

风险板提示了以下信息：

已识别的风险；

概率；

影响；

风险响应。

风险管理列表应作为日常Scrum活动或冲刺迭代末期回顾中的一个重要部分进行定期评估和审查。

风险板举例如下：

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/VhTQ51ND90cUrpSCa4KnzevGHJ8g.jpeg)

​

​第三步-风险响应策略

1**）回避：**

调整项目计划以消除潜在风险及其产生条件、防止项目目标因相关因素而受到影响以及对于面临威胁的目标则适当放宽控制标准

部分风险事件可能在项目的初期阶段发生。为了应对这些情况, 可以采取明确需求、收集数据以及保持与相关方的联系等措施来解决问题。

2**）减轻：**

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

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

3**）转移：**

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

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

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

4**）接受：**

项目团队已确定为了规避某类风险而不更改项目管理计划 ，或者找不到任何其他可行的方式来应对这类风险。

可以是被动或主动的。

以一种被动的方式来对待风险，则只需将该策略记下来即可；无需采取任何其他措施；当风险确实发生时，则由项目团队负责处理。

最常采取的主动应对策略是设立应急储备金,适当的时间间隔、一定的资金投入或资源配置以防范潜在风险

​第四步-风险评审

在风险评估阶段,团队将面临突显的风险挑战,需进行再次审查承受能力水平,并探讨应对措施的有效性

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

风险评审核心关注点是：

每日采用Scrum方法对积极风险进行评估；团队需收集风险管理流程的相关反馈信息；当前实际项目的风险情况受到评估风险的影响。

该方法的主要目标在于使潜在风险得以识别并被关注。通过定期进行监控和分析活动结果，并对相关数据进行详细追踪以及妥善处理相关事项。特别关注可能导致公司陷入困境的风险因素，并采取措施加强责任追究机制以确保及时发现并解决问题。通过持续改进管理流程来避免潜在的问题发生，并维持所有事务处于良好状态。

​风险燃尽图

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

燃尽图的特点是：

该表基于测绘迭代的方法构建了基于时间相关风险所承担总金额和风险普查预期货币价值的数据模型。

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

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

![(https://ad.itadn.com/c/weblog/blog-img/images/2025-01-21/J1pxhTOWGkn5Ul3iAvgF0XZeCsu7.jpeg)

​

​小试验-探测

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

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

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

性或修复缺陷。

探测：

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

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

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

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

​8、答题技巧

• 答题技巧

在考试环境中建立的敏捷团队是一种理想化的集体（其成员充满活力、具备多项技能，并且表现出高度的积极性）。每个站会都积极参与其中，并且能够主动承接任务并迅速完成。该集体内部关系融洽，在组织结构下避免对团队进行惩罚。通过非严厉的方式进行调整，并借助肯定和激励促进其发展。

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

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

3**、团队可以决定很多事**

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

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

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

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

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

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

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

注意

注意

注意