在中国软件技术大会和中国软件工程大会上也专门做过一次敏捷本质的主题演讲，我用了一个模型图来表示：

上面的图是我建的一个敏捷相关模型，模型看似简单，就几个文字和图形，但一般简化的背后其实都是有复杂的东西作为背景的，看似简单却不容易。

而我们怎么去理解这些简单却不容易的事情呢？按照自我导向型学习的方法，我们先从流程和术语开始。

什么是Scrum？

Scrum是一个迭代性、增量性的流程，适用于任何的产品开发以及工作管理。 在每个迭代结束后，Scrum都会产生一套可以交付的功能性产品。（来源：Scrum Alliance Scrum联盟）

Scrum的特点

• Scrum是一个敏捷的流程，可用于管理和控制研发工作。
• Scrum是现有设计流程的总结。
• Scrum以团队为基础，是一种在要求迅速变化情况下迭代地、增量地开发系统和产品的方法。
• Scrum是一个控制由利益和需求冲突导致的混乱的流程。
• Scrum是改善交流并最优化合作的方式。
• Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
• Scrum是最大化生产率的一种方法。
• Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多件具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
• Scrum能让每个参与者都对自己的工作以及自己做出的贡献感到满意，并让他们感觉自己的工作已经达到最佳的水平。

Scrum人员角色

任何人力流程都离不开人来执行，所以在讲解Scrum流程之前，有必要先把Scrum中的角色讲一下。

全身投入项目和Scrum过程的人，有三种角色：

1. 产品负责人（Product Owner），负责业务概念与想法（例如backlog）
2. ScrumMaster，负责领导Team执行与质量，关注于及时完成Sprint
3. 团队（Team）

Decomposing Agile 中也对职责进行了介绍：

在知道Scrum的主要角色后，我们看看下图中的过程图：它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。

第一次听到以上术语的可能不能很好的理解backlog和spring之类的东西，大家不用着急，以后会慢慢对每一个过程进行仔细讲解。

以下将对一些术语进行简单介绍，以便大家现在开始逐步了解Scrum。

Backlog

Product Backlog

在项目开始的时候，Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。

在下一篇我将着重讲解如何制定Product Backlog，怎么写故事，如何拆分和合并故事，以及如何确定优先级和进行估算。

Sprint Backlog

Sprint Backlog 是Sprint规划会上产出的一个工作成果. Sprint英文指短距离疾跑，就是说集合精力在短时间内（一个迭代）完成一些价值。当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum team和Product Owner 协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。

会议

Sprint Planning Meeting（Sprint规划会）

根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景，规划出今后一段时间产品发展的路线图，以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。

当为一个Sprint定义好足够多的Product Backlog，并且排列好优先级后Scrum就可以开始了，Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候，Product Owner会和Scrum team一起评审版本，路线图，发布计划，及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum Team按照优先级的高低来确定开发的先后是很重要的。

当Sprint backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。

Daily Scrum Meeting（每日站会）

一旦计划阶段结束，30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上，每个团队成员需要问3个问题：我昨天做了什么，今天做什么，遇到哪些障碍。谁都可以 参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的依赖，定位项目成员的要求，实时的调整当天开 发计划.

Sprint Review Meeting（Sprint评审会）

在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务，市场，技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分，是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。

在Scrum之 流程和术语介绍了流程，这里主要介绍第一个最重要的工件 Product Backlog。它是Scrum的核心，也是一切的起源。它是由Product Owner负责制定的一个按照重要性的级别排序了的故事列表。 

• 什么是Prodcut Backlog
  

backlog英文意思为“积压的工作”。 product backlog是一个具有优先级的需求列表， 并对每个需求进行了粗略的估算。在Scrum中表示可以预知的所有任务，包括未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。Prodcut Backlog永远处于不完整状态，它随着产品及其使用环境的变化而变化，它是动态的，管理层不断对之做出改变，确定产品需求，保证产品适用性、实用性和竞争性。

1. 在列表上层的故事首先被团队完成
2. Product Backlog不是制定一次就完了的，它是动态的，需要持续的被修订，可能会出现故事的增加、删除和修改、合并或者拆分
3. 任何一个Backlog的目标都是：它应该足够短、级别足够高，无特殊情况不需要修改。如果Backlog改变了，那么我认为你应该假设你的 Backlog错了，而不是需求变更了。变更需求通常意味着Backlog太长或者太详细，比如把复杂算法和逻辑也写入了backlog中了，要不就是写 的太含糊不清了，需要花费太多的时间猜测它究竟讲的是什么。

这里有一个别人做的，大家可以参考一下 product sprint示例

Make the Product Backlog DEEP

• Prodcut Backlog有什么用 

产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。产品backlog可以帮助我们对将要做的事情有个整体的认识，以及可以知道我们现在的状态。如果没有backlog，我们将不知道现在和将来产品做成什么样子，由于对产品目标的不明确，当然也不知道什么时候可以发布产品，或者发布的产品能给客户带来什么价值。

• 谁提供product backlog的需求

产品负责人与客户最近，他最清楚产品应该做什么样子，所以product backlog应该由Product Owner来制定。里面的需求由产品负责人或者客户制定，有时候Team里的需求分析人员可以和产品负责人或客户一起定义需求。制定后，由Scrum master和Team协助产品负责人修订并进行初始评估，里面的需求在sprint计划会议将进行更进一步的讨论。

• 什么时候会修改product backlog

如果一个列表太长或者内容陈旧，product backlog的浪费远大于价值本身，所以我们必须不断的维护产品backlog。产品backlog由产品负责人提供，与Team进行规模估算时，可能会拆分合并或者添加删除故事，初始估计也由Team进行评估提供估计值。产品所有者通常会向开发小组提出自己确定的优先级顺序，而小组也可能会请产品所有者根据他们对主题的评估对这个顺序作出少量调整。

• 怎么写故事

一般按照轻量级的故事来进行描述需求。用户故事是最基本的设计单元，它是从系统用户或者客户的角度出发对功能的一段简要描述。用户故事的形式很自由，没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑 用户故事是比较有益的：“作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到…的结果】以便【业务价值】。”以这样的模作为例子，可以得到一个用户故事说：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而且每个用户故事的开发周期不要太长（1－5天）

我们不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。可以按照硝烟一书中的表格来写backlog的故事：

• ID为一个唯一标识，确定后最好固定不变，在其他工作或者文档中想引用故事就使用这个ID来引用
• Name2到10个字，通过简单的描述来说明故事，如果要很多字才能表达这个故事，那很有可能这个故事太大，或者不清楚
• 重要性 这个优先级决定了sprint选择的故事，优先级越高的越早实现
• 初始估算 这个由Team来根据故事描述内容来估算，产品负责人讲解完故事后，Team对不清楚的进行询问，大概了解后进行粗略估算。从估算的角度出发，故事不应该太短，但也不能太过于详细，不需要把具体的规则和算法写进去。
• How do demo 从用户视角，从操作层面进行讲解这个故事如何通过软件来演示，也可以作为一个简单的测试用例了。重要性高的backlog条目都要填写”如何演示“。
• Notes相关信息、解释说明和对其他资料的引用等，一般都非常简短。

有时我还会增加一个分类列来标识出故事的主题，通过主题来从更大视角来查看需求主要内容，后期也可以根据主题的优先级来初始确定故事的优先级。

INVEST in Good Stories, and SMART Tasks

如何沟通故事

“方法”这个词很常用，但并不简单。大部分会出现一种现象，做了一些事情，解决了很多问题，但是当别人问自己是采用什么方法来指导自己工作时，我们并不能清楚的说出来。大部分工作是被事情推着走，而并没有在“方法”的指导下有序的进行工作。从精益开发角度来看，缺少”方法“，摸着石头过河，这势必造成很多浪费，所以我一直比较关注如何总结出适用的方法来支持团队的工作。

软件开发中有很多过程方法可以使用，下图为Forrest Research 2009年调查的方法采用率对比，其中可以看到Scrum方法明显占有优势。本篇我将从IT方法论的角度来谈Scrum。

方法定义

在需求过程中对新事物沟通时很重要的一个就是对术语的解释，这样大家知道谈论的不会有偏差，所以我们首先需要清晰的定义出什么是方法。在《软件工厂应用》一文开头指出，方法论是基于大量实践的高度抽象之上，加上理论的加工后才形成的一套体系。这个说法有点太抽象，所以我准备再借用一篇论文《Method Engineering: Engineering of Information Systems Development Methods and Tools》里的概念来说明。原文如下：

A method is an approach to perform a systems development project, based ona specific way of thinking,
consisting of directions and rules, structured in a systematic way in development activities with
corresponding development products.

我还是很认可这个定义，因为它定义得比较丰富，指出来方法应该包含哪些主要内容，我从中用黑体字标识出了我认为重要的部分。它指出方法（method）是一个基于理论和思想（way of thinking），包含一套指南和规则的 approach (针对某一问题的解决处理方法），并且这个方法结构化为一套系统化的开发活动。

方法框架

Aydin从通用方法工程理论出发提出了一套通用框架，这个框架包括三个元素：a philosophy, a framework and supporting tools and techniques. Aydin的论文我以前找过，但没有找到，只能从《A method for Requirements Management and modeling》 的一些介绍来理解了。如果有人找到了希望共享一下：）

价值观（philosophy）部分包含所有基本的原则、假定和约束，这些部分关注需求方法，定义范围并且决定了方法的组成。框架（framework）包含一些模板、规则和样式来展现案和归类不同的方法元素（例如产品、交付物和流程步骤）。工具和技术（The tools and techniques）支持特定方法步骤来实现最终产品。

Aydin方法框架在初始阶段能够用来结构化方法，但是由于还是比较抽象，所以仍旧比较难以实施。所以有其他方法研究者提出另一套框架，这个框 架用来开发（developing）、理解（understanding）和结构化模型方法（structuring modeling methods）。这些研究提出了六种思路（six way）： the way of thinking, the way of working, the way of modelling, the way of supporting, the way of communicating and the way of controlling.

The way of thinking

思考方法是一些范式、基本观点或者价值观，它能够回答“为什么”的问题。

在 Agile Software Development with Scrum一书中指出，Scrum的核心价值观是：承诺、专注、公开、敬重和勇气。它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则。

1.  承诺（Commitment）：承诺不只是把一项工作分配给团队，也不是简单的答应去完成。它是建立在目标之上的来自内心的接受和应许，这里只有“做”和“不做”，没有“让我试试”  
   
2.  专注（Focus）：像邮件和不相关的会议就是很常见的一些分散注意力的事情，我们需要做得是不转移注意力，把精力全部集中在承诺的事务上
   
3. 公开（Openness）— 保持一直让任何有兴趣的人员都可以在墙上、wiki页面或者仪表盘工具上获知项目当前状况，能够了解多少功能已经完成，哪些正在做，每次迭代和发布的目标是什么
   
4. 尊重（Respect）— 每个团队成员都必须被尊重的看待，大家一起指定工作规范（working agreements）
   
5. 勇气（Courage）— 为了接受并负责任的交付产品，团队成员必须有足够的勇气来对大家说“不”，比如不能承诺时，对纳入sprint的故事说“不”等
   

《Scrum敏捷项目管理》前言二最后指出，Scrum的运作原理同丰田公司持续成功的原因一样，包括三个方面：企业哲学基础、管理文化和技术工具。其哲学基础是授权于项目开发团队，以及满足客户需求。软件开发是一种脑力投入，如果不能保证开发人员的自愿投入，产品则肯定会打折扣，有研究证明一个愿意投入的开发人员和一个不愿意投入的开发人员效率相差在三 倍以上，对组织的贡献更是在十倍以上。在团队从里到外深刻理解集体负责和自组织后，Scrum方能有效运作。团队成员只有实现集体负责，承诺在固定时间内 交付实际产品后，才能算真正掌握了Scrum。其管理文化植根于“帮助他人完成目标”这一理念。敏捷方法尊重人，强调效率。敏捷方法强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。其主要技术工具是通过学习过程作出基于适时的决策。 沟通和反馈是一切的基础，即时的反馈是拥抱变化的前提条件。

The Philosophy of Scrum

Scrum是敏捷方法中的一种实践框架，所以敏捷宣言的价值观也是它的价值观。

敏捷开发之 4句敏捷宣言

The way of working

工作方法描述了如何应用方法，它包含一些在开发过程中可能采用的一些任务，包括任务的分解和排序，以及对任务的执行和决策的制定提出正式的指导和建议。

Scrum 本身并不是方法论，它只是一个框架，它只定义了高层次的管理流程，如下图所示。它并不涉及具体开发方法或者人员的有效沟通技巧等。这些没有涉及的领域需要桶其他理论和技能互为补充，以确保项目的成功。

Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队 所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。

启动Scrum项目所需的最简约计划包括：一份愿景及产品Backlog。愿景描述项目开发原因和预期目标。愿景可能描述商业运作方式将发生哪些改变，主 要特性和功能如何为客户创造收益，以及对市场的预期影响。产品backlog将定义交付愿景时，系统应满足的功能性和非功能性需求，它需事先划分优先级并经过初始预估（预估的目的是了解每个需求自身及相对与其他需求的规模）。

在Sprint第一天召开sprint计划会议，这个会议分为两部分，计划会议1由PO、SM和Team参加，主要是从产品backlog中挑 选出需要放 到当前sprint下的既定产品backlog，然后由SM、Team参加计划会议2，把既定产品backlog的故事拆分成任务进行估算，PO也可以一 起参加这个部分来了解具体的开发细节。sprint周期在spirnt计划会议2正式开始。开发过程中，团队每天召开每日站会（Daily Scrum），沟通团队成员间工作进度和进行任务协调。Sprint周期结束时，需要召开Sprint评审会议，由团队向产品负责人和其他利益相关者展示 当前sprint周期内的产品开发情况。产品负责人根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。评审会议结束后会进行回顾会议，通过总结以往的实践经验来提高团队生产力。

• Software Development Theory
• Scrum’s Implementation
• Scrum之 流程和术语
• Scrum 之 product Backlog
• Scrum之 Sprint计划会议
• Scrum之 站立例会
• Scrum之 评审会议
• Scrum之 回顾会议

The way of controlling

控制方法解决项目开发的管理方面的问题，提供一种机制来管理工作方法（way of working），它包含计划和计划评估。基于检查点和基线，计划和计划评估被划分为多个阶段。控制方法和模型方法和工作方法互相联系，不能单独来看每个方法。

软件开发对于管理存在两个极端：一个是没有任何的管理成本，所有的工作都是为了软件的产出，这种方式往往导致软件开发过程的混乱，产品质量低，士气 也很低落。另一个是大量管理活动的加入，评审、变更管理，缺陷跟踪，虽然管理活动的加入能够在一定程度上提高开发过程的有序性，但是成本却因此提高，更糟 糕的是，很容易导致团队的低效率，降低创新能力。因此，敏捷方法视图寻找一个平衡点，用低成本的管理活动带来最大的产出，即软件的高质量。 系统越复杂，集权管理导致失败的可能性越大，Scrum应用自组织、自管理原则，授权于项目开发团队 ，通过频繁运用“检查－调整“周期加速创造更具价值的软件，它带来较低的管理成本和高质量的产出。

《过程动态学，建模及控制》指出，“在过程运行根本机制相当简单易懂的情况下，典型做法是采用预定义的（理论的）建模方式。若过程复杂程度超出预定义方式的能力范围，便应选用经验性方式。”Scrum承认软件开发的复杂性（需求、技术和人），实施经验性方式。实施经验性过程控制方法时，有3大支柱：可见性、检查及适应。可见性是指对过程控制者来说，过程中对最后结果有影响的方面必须清晰可见，而且必须真实可信，例如Scrum中对于完成的定义必须团队都有清晰的认识。过程中的各 个方面必须频繁检查，例如进行代码评审等。适用就是经过检查后，调整工作需要尽快展开，以减少进一步的偏差。Scrum会进行每日站会，沟通每日进展情况 以作调整，每个sprint后还会进行回顾会议，以便反馈到下一个sprint中。

Scrum方法中没有传统意义上的项目经理，取而代之的是Scrum Master，他承担领导、指导和教练工作。软件开发工作的性质决定了会有大量复杂问题的出现，Scrum Master无权直接命令开发团队，他有责任讲授怎样使用Scrum来处理项目中遇到的每个新的复杂问题，解决这些问题离不开努力工作、智慧和勇气。

Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。但自组织团队不是无管理团队，它必须制定计划并有针对性的进行报告，才能管理自身工作。sprint backlog是团队履行职责的可视表现。

• Scrum and Process Improvement
• Development: Empirical or Planned?

The way of modeling

模型方法定义了一些模型语言，使用符号，结合文档进行分析，并可以可视化的来描述架构需求。

Scrum中可以有一些基本概念，如backlog、Story、Task，Story有优先级、Task有估算时间等，这些在开发过程中都需要使用一种方式表达出来，以下为别人使用Excel对产品backlog和sprint backlog进行描述的两个示例：

• Simple Product Backlog Example
• Simple Sprint Backlog Example
• Scrum Rules

The way of supporting

支持方法寻找有用的工具、培训、文档来协助支持信息系统的开发。

“项目快速启动”方案是为期两天的培训，确保缺少Scrum经验的新团队能启动项目。

以下为别人对Scrum工具的描述：

• Scrum工具大比拼—流行Scrum工具一网打尽
• 推荐三款Scrum项目管理工具

The way of communicating

沟通方法描述了对开发过程中的各个环节、工作成果等如何进行沟通，也包含在模型方法中定义的抽象概念如何通过文本或者图形符号来表达清楚。

Scrum通过任务看板来查看任务，通过燃烧图来查看项目进展情况。

• 用“看板图”实现敏捷项目的可视化
• Scrum之 站立例会

其他链接

• 流程 － 什么是真正的Scrum？
• FAQ’s

• Scrum intro

• What is SCRUM?
• Scrum Checklist – version 2.0
• http://www.implementingscrum.com/
• http://agile.alltop.com/
•  www.controlchaos.com/
•  http://www.jeffsutherland.com/
•  www.mountaingoatsoftware.com/scrum/
•  www.scrumalliance.org
•  www.agilealliance.org
• http://groups.yahoo.com/group/scrumdevelopment/
•  www.xprogramming.com
• Scrum In A Nutshell