敏捷开发精要-优快云博客

本文链接：https://blog.youkuaiyun.com/HT329952053/article/details/94738723

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

Scrum理论以及三大支柱

Scrum框架组成3355

三个角色

三个工件

五个会议

五个价值观

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