Scrum要素读书笔记

Scrum是一种迭代增量式的软件开发过程，用于敏捷软件开发。Scrum是一个包括一系列实践和预定义角色的过程框架。

Scrum要素包括角色、周期、工件，以及如何确定用户故事、如何估算工作，如何召开每日站立会议。

当前，Scrum方法在国内已经逐渐普及，为众多知名IT公司和软件开发团队采用。 本书是帮助软件开发人员认识、初步了解Scrum方法的佳作。通过本书可以理清Scrum的相关知识和概念，为采用和实践Scrum方法做好充分准备。

Scrum团队周记

工作项目的候选列表，新特性和错误修复的工作都有，这些都是项目上最重要的代办事项。

白纸板是用来文字记录的，例如，团队都认可的故事“完成”定义。

Sprint燃尽图，用来监测下一周任务完成过程中的速度变化。

Scrum日会是一种短会，用于团结和协调团队 。为了鼓励大家都简洁点，这个会是站着开的。它因此而得名“每日站会”。

团队成员轮流分享信息：前一天完成了什么任务，明天的Scrum日会前打算做哪个任务，有没有碰到什么障碍或是受到了什么拖累。

第一部分：敏捷力介绍

瀑布模型将开发和交付且软件项目的流程分割为相互独立的阶段：

• 需求收集
• 设计
• 编码
• 测试

唯一能够指望的只有变化。所有种类的敏捷流程都有一个共同点：拥抱变化，视变化为成长的良机，而非障碍。

简单地看，敏捷开发和瀑布开发之间差别在于：瀑布开发必须先完成当前步骤之后才能头也不回地迈向下一步骤。这不是敏捷团队的方式。敏捷团队会一点点需求收集，一点点设计、编码、测试，最后交付一点点价值给客户。接着团队再重复此过程……周而复始，工作推进过程中不断改善、调整流程，一直到项目完成为止。

敏捷迭代（在Scrum中称为“Sprint”）可不是微型瀑布，敏捷流程可是真的没有什么步骤之说。敏捷开发是一个整体流程，即测试、设计、编码、和需求收集是完全整合彼此依赖的流程。

敏捷提倡的良好实践：

• 边做边测试
• 及早且频繁地交付产品
• 文档边做边写
• 构建跨职能团队

敏捷方式的核心思想在于迅速交付商业价值，体现维可工作的软件，还要以定期增量的形式持续地交付价值。

敏捷宣言

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

遵循尽早且频繁交付软件的敏捷框架可以带来高效率，因而保障了客户可以实现所投入时间和金钱的最大化价值回报，进一步也排除了对前期合同洽谈的需要。

敏捷原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几个星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自组织团队。
• 团队定期地反思如何能提高成效，并依次调整自身的举止表现。

早交付，频交付。

第二部分：Scrum

Scrum是一个基于团队进行复杂系统和产品开发的框架。

选择最佳方法以达成目标是团队的责任。

任何时候都可以决定是否要交货，或者再继续做一个sprint以便完成更多功能。

Scrum角色

Scrum只承认三个互不相同的角色：产品负责人、Scrum master和团队成员。

角色：产品负责人

产品负责人的责任在于，帮公司得到最高投资回报。做法是指引团队做最有价值的作业，并远离不那么有价值的作业。也就是说，产品负责人控制着团队列表上那些条目的优先级顺序。

在Scrum中，产品负责人是唯一有权要求团队做事以及改变列表条目优先级的人。这必然也就意味着，产品负责人需要和干系人密切地合作，判别需要何时构建何物，从而交付最多业务价值。

产品负责人是产品愿景的监护人。愿景包括，产品为谁而建、他们为何需要、如何使用。

产品负责人角色概要：

• 持有产品愿景
• 代表业务
• 代表客户
• 拥有产品列表
• 划定故事优先级
• 设立故事的接收标准
• 有空回答团队成员们的问题

角色：Scrum Master

Scrum Master担当教练角色，引领团队达到更高级的凝聚力、自组织和表现。团队的交付物是产品，而Scrum Master的交付物就是自组织团队。

Scrum Master角色概要：

• Scrum专家和谏言者
• 教练
• 阻碍推土机
• 引导者

角色：团队成员

Scrum团队是高度协作的，也是自组织的。

做具体实现工作的团队成员们，同样也需要负责估计实现特性需要的工作量。产品负责人可以决定故事的顺序，但完成特性或任务需要多少时间是开发人员说了算。

作为Scrum团队成员，要完成的不是你的工作，而是这份工作。

团队成员角色概要：

• 负责交付用户故事
• 做所有的开发工作
• 自组织地交付用户故事
• 支配估算流程
• 支配“如何干活”的决策
• 避免“与我无关”

Sprint周期

Sprint规划会议

Sprint规划会议标志着Sprint的开始。通常来说这个会议分为两个部分。第一部分的目标是，团队要选择一组交付物作为当前Sprint的承诺。会议的第二部分，团队要罗列出交付用户故事所需完成的所有任务。

第一部分：要做什么？

Sprint规划会议第一部分的目标在于，团队要找出他们有信心在Sprint结束时交付的一组“已承诺”故事。产品负责人引导这一部分的会议。产品负责人按照优先级顺序，逐个地介绍他希望团队在当前Sprint完成的那些故事。

团队成员们要和产品负责人探讨所有故事，审查其验收标准，确保大家对预期结果有一致的理解。团队成员协商解决依赖性问题，一般还会讨论实现故事要做哪些事情。接着团队成员就要决定他们是否承诺这个故事。

团队的速率（velocity）指的是每个Sprint团队所完成故事点数的平均值，它是一个有效的工具，可以帮助团队选择承诺适量的工作。

第二部分：要怎么做？

会议的第二部分，团队卷起袖管就开工，把选定的故事分解成任务。要记得故事是交付物，他们是干系人、用户和客户想要的东西。团队成员需要完成这些任务才能交付故事。

Scrum日会

Scrum日会有时候也被称为站立会议：

• 每天：大多数团队选择在一天工作刚开始的时候开这个会。
• 小：只有开发团队的成员们可以参加。
• 简要：这个会不是用来解决大问题的，而是用于保持交流渠道的畅通。站立的意义在于阻止各种离题跑调的情况发生，避免开会变遭罪。
• 直截了当：参会者轮流快速地分享：
  • 在上一次Scrum日会之后，我已经完成的内容
  • 到下一次Scrum日会之前，我期望完成的内容
  • 导致我慢下来的障碍

故事时间

也被称为“列表修整”会议

Sprint评审

也被称为Sprint演示。即便是这个Sprint什么也没有完成，也要坚持召开Sprint评审会议，得让干系人了解情况，因为Scrum靠透明度而活。

回顾

Scrum就是为了帮助团队持续地进行检验和适应而设计，能够带动绩效和幸福感不断提升。每个迭代都要召开回顾会议，在迭代最后才举行，是专门留给团队的时间，专注于讨论他们当前Sprint的心得体会，并用于继续改进。

检验和适应

归根结底，我们以短周期形式做开发工作的原因在于，学习。经验是最好的老师，而Scrum短周期的设计家就是要为我们提供多方位接收反馈的机会，包括客户、团队和试吃昂，并从中学习。

检验和适应也被称为“持续改进”。

Scrum工件

Scrum工件是可用于实现进度可视化的工具。

• 列表
• 燃尽图
• 任务板
• 完成之定义

产品列表

产品列表是产品预期交付物的累积清单。这包括了特性、缺陷修复、文档变更和任何值得创建的东西。列表上的所有内容都能以某种弄方式帮助用户。

产品列表不断地改变。

列表的优点在于，绝不会浪费时间给那些可能永不见天日的特征写详细规格书。列表上的故事都是按照优先级排序的，可以说是精确排序。

产品负责人拥有列表，只有产品负责人可以增加、减少列表中的条目，或是进行优先级排序，尽管他也必须借助于和业务干系人、客户和团队成员的紧密配合才能做到。

Sprint列表

Sprint列表是团队当前Sprint的任务清单。它只存活一个Sprint的时间。里面包括所有已承诺的故事以及相关联的任务，以及此外的附加工作。

Sprint列表在Sprint规划会议中产生，一旦Sprint规划会议结束，，产品负责人就不可以再修改Sprint列表的故事清单。这是Scrum中业务方和开发团队之间的基本协议，每次Sprint开始前，业务方都可以改变方向，然而Sprint开始后，则允许团队只专注于他们所承诺的故事。改变这个已承诺故事清单有一个方式，就是由干这个活的团队成员提出变更请求。

信息辐射器

任务板贴满了便事贴，分为待办、进展中、已完成三种状态。

重要的是这些东西要做得大，而且要放在所有人都能看见的地方。要努力在墙上留住尽可能多的信息。

燃图

燃尽图描述了剩余工作随时间变化的轨迹。纵坐标绘制剩余量，横坐标是时间。

发布燃尽图：产品负责人以此为工具追踪剩余工作随时间变化的过程。图表中有不同斜率的下降趋势线，反映了单位时间段内所完成点数的变化。

Sprint燃尽图：显示当前Sprint剩余工作量的变化。Sprint燃尽图的目的在于，能够让团队看清楚情况，知道自己能够交付迭代中已经承诺的全部。

燃耗图：团队的速率就是团队每个Sprint所完成的工作单位数量（例如故事点）。燃耗图绘制出已完成故事点随时间的变化的情况，是团队速率的可视化指示器。

任务板：最简单的任务板由待办（todo）、办理(doing)和已办（done）三部分组成。

完成之定义

完成之定义和验收标准是有区别的。验收标准属于产品负责人或客户的领域，明确定义了被视为“可接受”产品必须满足的条件并记录在案。完成之定义归开发团队所有，关注的不是产品面向用户的功能，而是产品要可交付必须要做完的那些任务。

用户故事

用户故事是产品列表的基础构件。用户故事通常都是手写在索引卡上的。

作为<某类用户>
我想<做某事>
从而<创造出某些价值>

基于上述版本，又演化出了聚集目标的用户故事模板

为了<达成某类目标>
作为<某类用户>
我想<做某事>

和聚焦价值的用户故事模板

为了<创造某价值>
作为<某类用户>
我想<做某事>

用户故事是交谈的敲门砖。用户故事不是完整的需求或说明书，它们是占位符。它们的信息量足以提醒团队有东西要完成，但我们刻意地不过多探讨细节……直到必需之时。

用户故事、交谈和接收标准结合起来组成了完整的需求规格说明书。用户故事让我们可以快速且完全地捕获想法。在交谈中，我们可以阐述所需完成的细节，并达成一致且可实现的理解。最终，我们用明确的、可测试的接收标准来记录共识。

用户故事大小估值工作

生成估值的真正目标是要提供进度的可预测性度量。、

第三部分：辅助性实践

Scrum是轻量级框架，它不告诉你如何规划发布，或开发产品原型，或编写及测试代码。

发布规划

发布规划是为产品发布挑选故事（特性、功能增强、缺陷修复等）的流程，以及应该如何进行发布。

• 固定范围
• 固定日期
• 固定日期且固定范围

速度、成本和范围，这是项目管理周期中著名的“铁三角”。在软件项目中，速度指的是构建和发布系统所需的时间，成本通常受项目上人头数的影响，范围涉及所包含的故事数量。三者组成一个平衡方程式，改变其中任何一个，必然都会导致另外一个或两个相应地产生变化。

用户角色人物

用户角色人物是整理妥当的简要档案，用作参考时方便手持。研究自然环境中真实用户的习惯、态度和行为，虚构人物往往是它们的混合体。

绘制故事地图

绘制故事地图是另一种组织用户故事的方式，能够提供比传统产品列表更丰富的上下文，也有助于进行发布规划。

尽管故事地图并不完全是产品列表的替代品，但对照比较一下还是很有好处的。本质上来看，产品列表是唯一的，用户故事按优先级从最高到最低的顺序排列。故事地图是二维的，不仅指示了故事的优先级，也指出了它们彼此的关系和用户更高层次的目标。地图能帮助团队理解故事是如何组装起来形成可发布产品的。

纸上原型

纸上原型并不是Scrum的一部分，但它具有敏捷的本质，是充实产品负责人工具箱的上佳之选。

这种低科技、高参与度的方式能移除障碍，让客户也可以参与到设计与开发流程中，还能让学习成效最大化，因为它的反馈循环快得只在转瞬间。

项目微章程

微章程就是明确记载了项目关键信息的概要项目。项目伊始只不过是一个想法，而微章程就是有效捕获想法的一种方法。捕捉到之后，想法就会变得更易于分享、讨论和修订，这会极大地帮助你发现并排除掉范围及使命蔓延。

基础微章程包含如下元素：

• 代号：给项目取个名字
• 使命宣言：表达项目的目的
• 愿景宣言：描述项目想要创建的未来
• 电梯演讲：关注项目要解决的问题，以及公司或客户将由此获得的好处。
• 商业价值：项目对业务而言在金钱或其他方面的价值是什么
• 客户和用户：做购买决策的人
• 度量指标：讲清楚计划如何去度量之前所描述的那些价值
• 里程碑：重要的时间点
• 资源：完成如下描述的项目必须或必需用到的资源
• 风险：可能危害或颠覆项目的事情
• 权衡：现实地评估团队运作环境中的各种约束。

重构

敏捷宣言声明：最好的架构、需求和设计出自自组织团队。

重构就是，在不改变代码外在行为的前提下，对代码做出修改，以改进程序内部结构的一种有纪律的方法。核心是通过一连串的小行为实施转变。每次转变（称之为一次“重构”）都只做一点点，但一系列的转变就能带来显著的结构重组。由于每次重构都不大，也就不容易出错 。每次重构之后系统也依然运作良好，减少了系统在重组过程中严重受损的几率。

把设计工作内置于开发流程之中，这就是敏捷开发迭代复迭代不断前行的方式。

测试驱动开发

测试驱动开发的目标在于快速地开发出设计精良、正确性已获证实的代码。

通过先行测试，可以把注意力集中于开发人员需要让代码展现的外部行为。一旦开发人员切实地理解了代码需要做什么，就已经准备周全可以妥善地设计代码实现了。

结对编程

结对编程更加快速地产出设计更精良、整洁的代码。它还能消灭知识简仓。