Scrum知识点

Posted 2023-04-09

参考技术A Scrum是敏捷开发模式的一种。在Scrum模式下，团队通过不断迭代来对产品进行增量交付。

一个典型的Scrum团队有5-9个成员，分3种角色：

ScrumMaster协调团队的工作，为团队选择最佳的工作模式，保护团队减少外界的打扰，帮助团队解决阻塞工作进行的问题。

Product Owner负责产品的方向，制定产品路线图和发布计划，定义产品功能优先级，为团队澄清需求。Product Owner和ScrumMaster不能是同一个人。

团队成员不分开发和测试，是全功能型的开发实现团队，在任何产生瓶颈的地方，所有成员全力以赴解决。

一个迭代也叫一个冲刺（Sprint），一般周期长度为1-4周。在一个迭代里，成员全力交付承诺的需求。如果任何需求没有完成，则移到下一个迭代继续实现。

迭代规划会的目的是为本迭代安排需求，定义需求的优先级，澄清需求。迭代规划会在迭代的第一天举行，需要整个Scrum团队参与，业务方和用户代表也可能参会。在迭代规划会上，Product Owner对需求Backlog按优先级从高到低进行讲解，每个需求讲解完毕后，现场解答团队的问题，澄清需求，然后团队一起对需求进行快速评估。不断重复这个过程直到需求工作量到达团队在本迭代内可交付的最大值。团队随后对规划到本迭代内的需求进行分配和任务拆解。

每日站会的目的是为了团队了解彼此的进展和是否有阻塞工作进行的问题。每日站会从迭代的第二天开始召开，需要整个团队参加。每日站会要求尽可能简短（所以要站着开），一般不超过15分钟。如果有需要解决的问题，会后跟进，而不要在站会中解决。

迭代评审会的目的是为了验收产品。迭代评审会不需要固定的时间和地点正式召开，而是团队任何成员如果有可验收的功能，就叫上Product Owner和业务方或用户代表进行验收。

迭代回顾会的目的是对本迭代进行回顾，发现改进机会，让团队持续改进。迭代回顾会一般在迭代的最后一天召开，整个Scrum团队参与。迭代回顾会建议使用积极的语言，每个成员对三个问题进行反馈，以找出改进机会：

    在本迭代中，有哪些方面做得好的，团队需要继续保持？

    在本迭代中，有哪些方面可以做得更好的，团队需要改进？

    在本迭代中，有哪些事情团队不应该再重复了？

知识共享 主流敏捷开发方法介绍：Scrum与极限编程（XP）

一、Scrum

Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

1.1、Scrum 理论基础

Scrum 采用迭代、增量的方法来优化可预见性并控制风险。Scrum过程框架的基石包括如下三个方面：

• 透明性（Transparency）

透明度是指在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。

• 检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

• 适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

1.2、Scrum的四大支柱

• 迭代开发

在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

• 增量交付

增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。

• 自组织团队

Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。

• 高优先级的需求驱动

在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

二、极限编程

极限编程（ExtremeProgramming，简称XP）是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

2.1、XP核心实践

基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践：

• 短交付周期

极限编程和Scrum一样采用迭代的交付方式，每个迭代1-3周时间。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

• 计划游戏

XP的计划过程主要针对软件开发中的两个问题：预测在交付日期前可以完成多少工作；现在和下一步该做些什么。不断的回答这两个问题，就是直接服务于如何实施及调整开发过程。

• 结对编程

结对编程是指代码由两个人坐在一台电脑前一起完成。一个程序员控制电脑并且主要考虑编码细节。另外一个人主要关注整体结构，不断的对第一个程序员写的代码进行评审。结对不是固定的：我们甚至建议程序员尽量交叉结对。这样，每个人都可以知道其它人的工作，每个人都对整个系统熟悉，结对程序设计加强了团队内的沟通。这与代码集体所有制是息息相关的。

• 可持续的节奏

团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

• 代码集体所有

代码集体所有意味着每个人都对所有的代码负责；集体所有制的一个主要优势是提升了开发程序的速度，因为一旦代码中出现错误，任何程序员都能修正它。在给予每个开发人员修改代码的权限的情况下，可能存在程序员引入错误的风险，他／她们知道自己在做什么，却无法预见某些依赖关系。完善的单元测试可以解决这个问题。

• 编码规范

XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是实现代码集体所有的重要前提之一。

• 简单设计

XP要求用最简单的办法实现每个小需求，前提是按照这些简单设计开发出来的软件必须通过测试。这些设计只要能满足系统和客户在当下的需求就可以了，不需要任何画蛇添足的设计，而且所有这些设计都将在后续的开发过程中就被不断地重整和优化。

• 测试驱动开发

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

• 重构

开发人员虽然对每个用户故事都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫设计的重构。XP强调，把重构做到极致，只要有可能，程序员都不应该心疼以前写的程序，而要毫不留情地改进程序。当然，每次改动后，程序员都应该运行测试程序，保证新系统仍然符合预定的要求。

• 系统隐喻

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。

• 持续集成

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

• 现场客户

在极限编程中，“客户”并不是为系统付帐的人，而是真正使用该系统的人。极限编程认为客户应该时刻在现场解决问题。例如：在团队开发一个财务管理系统时，开发小组内应包含一位财务管理人员。客户负责编写故事和验收测试，现场客户可以使团队和客户有更频繁的交流和讨论。