Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述

Scrum框架及其背后的原则（上）——Scrum 框架的伪代码描述

Scrum是应用最广泛的敏捷开发方法。同时，它的失败率却非常高，其创始人之一Ken Schwaber 估计75%尝试Scrum的组织无法获取他们预期的效果

（/interview-with-ken-schwaber）。对此，通常的解释是“对Scrum 框架的错误应用，和对其原则的错误把握。”Ken Scheaber 在“Scrum Guide”一文中对这两方面都提供了权威的阐述。本文的目的是在此基础上，提供更加明确的操作性的指导和检查工具。本文分成上下两个部分，分别讲述scrum 框架本身和其背后的原则。

第一部分：Scrum 的框架

Scrum并不是一个特定产品开发的流程或技术，而是一个容纳其它流程和技术的框架。作为一个迭代和增量的产品开发框架，Scrum本身十分简单和明确。下面的一段伪代码，是对Scrum 框架的完整表述。

这就是Scrum的完整框架，只有这些，很简单，我们下面将逐行解释。

Scrum是一个迭代开发模型。每一个迭代周期，团队完成一部分产品需求，交付可工作的软件。在Scrum中，迭代被称为sprint (本意为冲刺跑，一般不作翻译)，典型的sprint长度是1到4周。值得强调的是，对于同一团队，sprint的长度是固定不变的。

Sprint_Length -- Sprint长度：这里以10个工作日（两周）为例，const常量修饰符，强调了其不可变性。

Velocity -- 团队开发速率：也即每个sprint 团队能完成多少量的用户需求，它是Scrum中计划和承诺的最重要依据。开发速率来源自过去实际产出结果，并在产品开发过程中不断修正。

以上的实体定义是Scrum 中的三个关键角色，在Scrum框架中也仅仅定义了这三个角色。

Team -- 团队：团队负责产品交付，规模一般为5～9人，Scrum强调团队的多功能（cross functional）和自组织。多功能指的是，团队应该整体具备各个职能所需的技能，如系统，开发和测试技能，同时也具备各个组件的技能如数据库设计、协议开发和UI设计等。团队的多功能是短迭代开发的基础，只有做到这一点，独立的团队才可能在一个sprint 中交付对用户有意义的产品增量。自组织指，在目标清晰的前提下由团队自主决定完成目标的具体方法。

Product Owner –产品负责人:多直接称为PO。PO 负责把握产品的方向，包括需求的收集、定义，优先级设定等。PO通过这些活动以及和团队的合作，最终确保产品ROI（return of investment, 投资回报）的最大化。

ScrumMaster: 一般不作中文翻译，ScrumMaster并不直接负责产品交付，它向团队负责，确保团队按照Scrum的框架工作，具备良好的外部和内部工作环境，顺畅地交付产品，并不断的改进，提升交付的效率和质量。与传统意义上的管理者不同，ScrumMaster更多是起服务、协调和引领的作用。如果注意观察会发现，在这段程序中，ScrumMaster 是一个定义，但从未使用的变量，这也正反映了ScrumMaster的协调和支持的作用。

上面的结构变量是Scrum 中的核心制品，它们贯穿整个Scrum 操作过程，分别是：

Product backlog -- 产品待办事项：很多时候直接用英文表示，简称PB，是一份用户需求列表。其中的每一项都是一个具体的端到端的用户需求，如“用户可以完成登录”等等。Scrum 产品开发过程就是，通过一系列的sprint，每个sprint完成一部分“产品待办事项”，交付包含这些需求实现的产品增量，直至完成所有“产品待办事项”。Product backlog 的责任人是Product Owner，它在产品开发的初期生成，并在开发过程中不断更新完善。

Sprint backlog -- sprint待办事项：是一个sprint 中要完成的任务列表。其中的项目是为完成特定用户需求而要进行的设计、开发、集成、测试等具体任务，如“为模块A添加外部接口”等。完成sprint backlog中的所有任务，也意味着sprint 开发任务的完成，对应的用户需求可以交付。Sprint backlog，在spirnt 计划会议上生成，在开发过程中，可能会有所调整。

Sprint burndown chart – sprint 燃尽图：以坐标图表示团队在一个sprint中工作进展情况，横坐标是sprint 已进行的实际天数，纵坐标是还剩余的任务需要的时间的总和。它直观的反应了sprint 实际执行与计划的比较，以及团队离sprint 的目标完成的距离。

Release burndown chart –发布燃尽图：以坐标图表示当前版本的需求完成进展情况，横坐标是已经进行的sprint 的个数，纵坐标是待完成的用户需求的多少。它直观的反应了产品需求的完成情况，以及团队离完成版本完全发布的距离。

Product increment -- 产品增量：Scrum 要求每一个sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI），事实上交付与否还要受用户习惯的约束。能否每个sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。

上面代码中的三步操作是Scrum 执行开始的准备条件。

Setup Team –创建团队：创立和建设适合的团队是Scrum实施的第一步工作，团队应该满足上面定义的Scrum团队的基本属性，并形成自己的目标和愿景，理解Scrum工作模式。

Define Definition of Done –定义完成标准：完成标准，是指一个用户需求完成应该满足什么样的标准。它是Product Owner 和团队之间的一个约定，有了这个约定，当团队说，这个需求完成了的时候，Product Owner 将明确知道这意味着什么，比如是否包含了针对这个需求的性能测试，或是否包含相应的用户使用手册等。在实际运用中，由于条件限制，团队在一开始可能无法做到sprint 结果可交付，而会剩余一部分工作在交付前完成，如性能测试等，这一部分工作被称为“undone”的工作。完成标准在特定时间是固定的，但随着团队成熟度提高，团队应逐步扩展自己的完成标准，使其逼近向客户交付的条件，undone的部分越来越少。

Initial Project –启动项目：项目启动，是项目进入开发阶段前的一系列准备工作，如：项目目标的设定，项目初始需求的定义和澄清，工作量的估计，风险的识别，关键设计决策的产生，开发基础设施的选择和构建等。一般由客户（如果可能），PO，团队以及相关干系人共同参与项目启动。项目启动最重要的是输出一个初始product backlog，它应该包含对其中条目的大小的估计和优先级别的设定。

上面三个操作的结果是，有了合适的Scrum团队，团队和PO之间就需求完成的标准达成一致的定义，并生成了一份初始的product backlog。有了这三个条件便可以正式进入迭代开发了。

每一次while循环代表一个sprint周期，直至product backlog中所有的需求被开发完成。

Run sprint planning meeting –进行sprint计划会议： sprint 规划会议规划这个sprint 目标和具体任务安排，它标志着一个sprint 的开始。在sprint计划会议上要依次完成以下的内容：

1. 团队决定在接下来的的sprint 中要完成的用户需求，如过对需求存在疑问，团队应和

PO进行澄清和确认。团队必须按照PO设定的product backlog的优先级别，从高到低选择，如因实现上的依赖关系，要调整需求选择的顺序，也需要和PO进行确认，以确