确实存在一种用于软件开发的可重复和可定义的过程吗？一部分人认为这不仅可能的，而且是必须的，比如那些赞成将CMM（Capability Maturity Model，能力成熟度模型）方法（Approach）用于软件开发的人[Paulk1995]。

译注：Approach，国内有研究复杂系统的学者将其译为“趋法”，个人觉得比较贴切，但因软件业界多将其译为方法，故仍将其译为“方法”。CMM定义了5个过程成熟度阶段：初始级（Initial）、可重复级(Repeat)、定义级(Defined)、管理级(Managed)和最优化级(Optimizing)，并让它的用户来定义18个KPA（Key Process Areas）的过程。SEI在2001年推出了CMMI，Capability Maturity Model Integration，其描述有2种方式：连续与等级，CMM于2005年12月已正式停止。

然而，很多在此领域第一线的人随着时间的推移逐渐发现，可重复或可定义的过程方法做出了很多不正确的假设，比如：

可重复的/可定义的问题。 可重复的/可定义的过程假设，存在一个步骤或数个步骤来捕获需求。但是在大多数情况下，却不能像那样（使用一个或数个步骤）来定义一个应用程序的需求，因为它们要么是无法明确定义的，或者是持续地变化着。

可重复的/可定义的解决方案。可重复的/可定义的过程假设，一个体系结构能够被完全地规定。但实际上它是逐渐演进的，部分原因是由于未捕获的或者是变化的需求（正如前面所述的），部分原因是由于创造性的过程包含设计新的软件体系结构。

可重复的/可定义的开发人员。 软件开发人员的能力相差很大，以致对一个开发人员起作用的过程可能对其他人却没有效果。

译注：在IT早期的日子中，评估生产力的比率，即在最好的个体生产力和最差的个体生产力之间的比值，最大可以达到 5:1。换句话说，最好的职员能够做5倍于最差员工的工作。现在，生产力比率可以达到40:1。一般业界认为1:20~28倍。

可重复的/可定义的组织环境。 进度的压力、优先级（例如，质量、价格、人力）、客户的行为等这些都是不可重复的，因为它们是高度主观的，所以很难去定义它们。

以上假设的问题在于这些变量具有很大的差异。在现实项目中，经常出现大的动态变化，会很大程度地影响整个项目。例如，在应用程序的实现阶段，由于假设了所有需求都被事先捕获，所以新的需求改变将对项目进度造成彻底的影响。几乎所有需求发生改变的普遍性根源都在于：业务需求驱动的改变、可用性驱动的改变、重新确定优先级驱动的改变、实验性驱动的改变等，消除这一不确定性几乎不可能。这个问题不能简单通过改进确定用户需求的方法来解决，而是需要一种更加复杂的过程从根本上产生全新运作的替代方法。

换句话说，一旦我们承认这些动态变量确实存在，我们就需要更具适应性的方法来构建软件。我们担心的是大多数当前的方法不能使我们构建出具有足够弹性的软件，现在的方法和设计范型似乎都阻碍软件都适应性。

很多软件从业者倾向于相信存在一种能够计划优先级的最优解决方案，能够实现详述所有需求。与此相反，Scrum从允许我们构建更具弹性的软件出发，认为没有必要预先写出全部的需求。可能用户也不知道什么是需要的，他们将在此过程中寻找他们认为可能的、未写入计划的需求。甚至软件开发人员预先也不完全知道究竟如何能够被构建出来。因此，用户在他能够感受到或接触到之前并没有非常明确的概念。就这一点而言，在此陈述的Scrum模式提供一个经验技术的集合，这些技术预先假设不确定性的存在，而不是提供实际的和特定的技术来驯服不确定性。这些技术扎根于复杂性管理，即自组织、经验过程管理以及知识创造。

从该意义上说，Scrum不仅是一种“迭代和增量并行的”开发方法，它也是“适应性”的软件开发方法。

译注：迭代（iterative）与增量 （incremental）是两个截然不同的概念，很多人常将两者混为一谈，但两者都被敏捷团队用于交付价值（deliver value）。迭代意味着“Rework”，增量着意味“adding”。两者的具体区别与联系，请参见：http://www.agileproductdesign.com/blog/dont_know_what_i_want.html及http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=108

Scrum是如何工作的？

Scrum的目标是在一系列（3～8个）短期的时间框（time box）内交付尽可能多的优质软件。其中时间框（固定时间间隔）被称为Sprint，典型地，其将持续大约一个月的时间。

开发周期（包括需求、分析、设计、演进和交付）中的每个阶段都映射到一个Sprint或者一系列Sprint。传统的软件开发阶段仍将保留，主要是为方便跟踪里程碑。举例来说，需求阶段可能使用一个Sprint，包括原型的交付。分析和设计阶段可能各自占据一个Sprint，而演进阶段可能占据3～5个Sprint。

近年来，对于大多数的软件产品而言，发布周期已缩短至3个月或以内。在开始Sprint周期前，需求被规格化为足够和及时准备好即可。在Sprint结束时生成可运行软件以供评审。

因此，分析、设计与演进发生在每一个Sprint。在许多公司Sprint周期已缩短至2周或更短。在最好的公司，交付（Delivery）包括在每一个Sprint中 。

与可重复的和可定义的过程方法不同，Scrum中的Sprint没有预先定义的过程。取而代之的是，Scrum会议（Scrum Meeting）驱动分配行动的完成。

每个Sprint运作在很多工作项目(work items)上，这些工作项目成为一个Backlog。通常，在一个Sprint里，没有项目（item）从外界添加到Backlog中。最初预先分配的Backlog产生的内部项目则可以添加进来。Sprint的目标是完成尽可能多的优质软件，但一般情况下，实际交付的软件会少一些。

译注：Backlog有译作待办事宜，这里保留英文。随着Scrum发展现细已分为Product Backlog、Selected Product Backlog、Sprint Backlog、Impediment Backlog等Backlog。本文的Backlog大致等同于前3者。

最终的结果是每个Sprint交付的都是非完美的发布版本。

在一个Sprint期间，每天举行Scrum会议来确定如下议题：

• 自从上次Scrum Meeting以来所完成的项目。
• 需要解决的问题或障碍（Scrum Master是团队的领导角色，负责解决障碍）。
• 团队应该在下次Scrum会议之前完成的新任务。

Scrum Meeting能够使开发团队中成员的知识社会化”，同时产生更为深刻的文化上的超越。这种“知识社会化”（knowledge socialization）可以在日常的开发过程中促进自组织的团队结构。

译注：Nonaka与Konno两人共同提出SECI模型，藉以解释知识创造与不断累积的过程。他们将知识转化的步骤或程序分为4个阶段：（1）社会化（Socialization），（2）外表化（ Externalization），（3）组合（Combination），以及（4）内化（Internalization）。通常知识在每个阶段的转化过程中，须不断的自我突破与超越，且会像滚雪球一样，越滚越多，不断增加，并显现螺旋式的演进轨迹。社会化（Socialization）是指让许多的个体（individuals）共同在一起生活、工作，而非只靠书面教导，使大家相互了解彼此的思想与感觉，因而促使个人之间彼此交换及分享其隐性知识。

在每个Sprint结束时用一个演示来：

• 向客户展示进展情况。
• 给开发人员一种成就感。
• 集成和测试正在开发的软件的适当部分。
• 确保真实的进度，即Backlog的减少不是用文档来衡量。

在收集残留的和新的业务并重新确定优先级以后，形成一个新的Backlog，并开始一个新的Sprint。很多其他的组织和过程模式（Organization and Process Pattern）可以与Scrum模式联合使用。

下图展示了Scrum模式之间的关系。

Scrum模式

Sprint模式

环境

你是一名软件开发人员或者一名管理软件开发团队的教练。在此团队中，发现、创造或者实验创新占有很高比例。你正构建或者扩展系统，允许使用清晰的接口、构件（Component）或者对象来划分工作。

问题

你想在开发人员不受打扰工作的需要、管理需要，以及客户要看到真实进展的需要之间进行平衡，同时还要贯穿项目始终地控制发展的方向。

作用力（Forces）

开发人员需要时间来不受干扰地工作，他们需要后勤支持，也需要使管理者和用户确信正取得实质性的进展。

首先，到了系统交付的时候，产品已经过时或者需要做较大的改动。问题来源于需求信息大多数在项目开始时收集而来，而用户通过使用系统或中间的发布版本了解大部分情况。

假设开发过程是一个被明确定义的方法，它能够进行规划和估计。如果项目失败，理所当然地认为开发过程需要更加慎密。然而，这些一步一步的方法并不起作用，因为它们不能应对人员和技术上的不可预见性。因此，由于包含很多的不确定性因素，在项目之初就做出完整的、详细的规范说明、计划或者进度是不可能的。

过程自动化为管理人员和开发人员增加了管理工作（administrative work），常常导致开发过程和结果并不一致。项目计划展示了活动，但是却不能确保实质性进展或者结果。

解决方案

用Sprint划分项目。一个Sprint是大约30天的时间段，在这段时间内将执行经过协定的工作量，产生一个可交付的产品。每个Sprint完成Backlog预先分配的工作量，工作量是根据优先级和在Sprint的时间长度内能完成工作量的近似值分配的。通常，选择高内聚、低耦合的块（chunks）——或者水平的或者垂直的“包”（Packets），确切地说，就是垂直的或水平的构件。

一般来说，在一个Sprint期间，没有从外界添加到已分配好的Sprint Backlog里的。外界所添加的只是加入到Global Backlog中。但是源自Sprint的障碍（未解决的问题）可以添加到已分配好的Sprint Bcaklog中。Sprint以一个新功能的演示作为结束（Demo After Sprint）。

这就给了开发人员发挥创造力、通过探索设计空间和做出实际工作来学习的空间。不受外界干扰的影响，他们利用机会和洞察力自由调整他们的工作方法。同时，这也通过展示实质性的进展而不是以文档和报告作为进展的证据，来保持管理人员和其他的项目相关利益方的信心。

译注：在Sprint期间，selected product backlog是保持不变的，仅在Sprint结束后进行调整。在前进过程中，团队可以在Sprint期间自主改变途径和他们工作的方法。

最终结果是，每个Sprint都产生出一个可见的、可用的交付产品，并向用户进行展示。一个增量可能是中期的，也可能是可交付的，但是它应该是独立的。Sprint的目标是完成尽可能多的优质软件来确实质性进展，而不是用纸上里程碑（paper milestones）作为托辞。

译注：迭代式开发，以及尽早地以可运行软件进行及时反馈，以便实时纳入用户的反馈意见的战略对软件开发产生了良好的效果。2007年Standish Group发布的报告“There’s Less Development Chaos Today”表明业界项目成功率由1994年的16.2%提高到2006年的35%。

基本原理（Ratioanle）

• 没有项目从外界添加到Backlog的事实使开发进展能够“全速前进”，而不需要考虑方向的改变。
• 在Sprint期间，不对开发人员进行“测试”而是完全授权。信任开发人员完全有能力自主完成工作。
• 开发团队可以在Sprint期间自主确定软件过程，并且能够适应变化的环境（不同的开发人员、不同的项目阶段、更多的知识等）。
• Sprint时间间隔短，因此，完成一个Sprint的问题要比完成整个项目的问题简单得多。接受较小的挑战更容易。译注：Sprint的短迭代，往往会主动采用“治而分之”的策略，将项目大问题分解为Sprint小问题，使得容易解决问题，这样使得挑战较小，而较小的挑战容易战胜。
• 开发人员能够经常得到反馈（在Sprint结束时）。因此，他们能够认识到项目的实际情况，而不会危及到整个项目。
• 管理者具有完全的控制力，能够在每个Sprint结束时彻底地改变方向。
• 最终用户通过Sprint结束时的演示，使得密切地参与到整个应用程序的开发中来，但是不允许他们干涉日常的活动。因而，所有权和方向归属于用户，但是又没有他们的持续干涉。
• 因为Sprint产生可运行的代码，所以项目状态具有可见性的。

已知应用

在Argo，Flemish教育部，自从1997年7月开始，就开始在大量最终用户项目、数据库框架开发、文档管理和工作流中使用Sprint。用持续大约一个月的Sprint来划分Backlog。在每个Sprint结束时，提交一个与所有当前应用程序集成在一起的可运行Smalltalk图像。团队每天在Scrum Meeting上碰面，并且在与规划指导委员会的每月例会演示之后，重新确定Bcklog的优先级。

译注：Smalltalk被公认为历史上第二个面向对象的程序设计语言，和第一个真正的集成开发环境(IDE)。Smalltalk由Alan Kay，Dan Ingalls，Ted Kaehler，Adele Goldberg等于70年代初在Xerox PARC开发。Smalltalk对其它众多程序设计语言的产生起到了极大的推动作用，主要有：Objective-C，Actor，Java和Ruby等。90年代的许多软件开发思想得益于Smalltalk，例如设计模式、敏捷编程和重构等。

应用结果

结果是参与者得到高度的“有效所有权”（effective ownership），其中包括通过演示和确定Backlog优先级进行参与的用户。

在Sprint结束时，对开始时所做的计划有了最佳的估计。在评审期间，管理者有机会改变将来的计划。此时，项目是完全灵活的。目标、产品、交付日期以及成本都是可以重新定义。使用Scrum，让我们获得了大量计划之后（post-planning）的灵活性（包括客户和开发人员）。

在整个Scrum期间每天例行的Scrum Meeting上，可能会发现某些团队成员把时间浪费在不具有或者较低生产力的任务上。相反，同样也可能发现人们需要比管理者最初分配的更多时间用在他们的任务上。开发人员可能表现得没有预想的那么熟练或者有经验。然而，Scrum的高可视性使我们能够处理这些问题。这是Scrum方法通过Scrum Meeting和Sprint清晰表现出来的优点。

而将Backlog分组到Sprint的困难则揭示出管理者或者客户对于优先级还不够清楚。

Bakcklog

环境（源自：Sprint）

你与一个软件项目或者其他任何项目相关，项目在本质上是不甚清晰的，需要知道下一步该做些什么。

问题

用来组织下一步以及在项目任一阶段该完成的工作的最佳方法是什么？

作用力

传统的规划方法，比如计划评价与审查技术（PERT）和甘特图（Gantt），都假设事先已经知道所有的任务、它们之间所有的依赖关系、所有的任务持续时间以及所有可用的资源。假如项目中包含任何学习、发现、创造或者适应性改变，那么这些假设就是错误的。

解决方案

使用Backlog组织Scrum团队的工作。

Backlog是一个具有优先级的清单。优先级最高的Backlog项目将首先投入工作，优先级最低的Backlog项目将最后投入工作。产品中没有什么特征、增加或者增强值得争论。

Backlog是实现产品需要执行的工作。完成这些工作就会将其从当前的情形转化为产品的愿景。在Scrum中，Backlog随产品和环境的变化而发展变化。Backlog是动态的，进行动态管理，以确保完成的Backlog使产品具有竞争力成为可能。

Backlog清单有很多来源：产品营销部门加入实现他们对于产品愿景的工作；销售部门加入在已有的基础上增加新的销售额或者扩展有效性的工作；技术部门加入确保产品使用最具创新性和生产力的技术工作；开发部门加入增强产品功能的工作；客户支持部门加入纠正潜藏的产品缺陷的工作。

只能有一个人确定工作的优先级，这个人负责满足产品的愿景目标。其头衔通常是产品经理（目前在Scrum中正式定义为Product Owner）或者市场营销经理。如果任何人想改变工作的优先级，他们不得不说服这个人去改变优先级。优先级高的Backlog具有最清晰的说明，其优先级的确定同样也要考虑依赖关系。

当有Scrum团队可用（新成立或者刚刚完成一个Sprint）的时候，这个团队与产品经理见面。集中注意力在最高优先级的Backlog上，团队选择一个自己认为能够在一个Sprint迭代（30天或更短）内完成的Backlog。（目前在Scrum中将此定义为Selected product backlog。）这样，Scrum团队可能通过选择一个相互支持的Backlog，也就是能够立刻开始而不需要等待的Backlog，从而改变这个Backlog的优先级。

团队选择一组内聚的、高优先级Backlog项目，它们一旦完成，就将达到一个目标或者一个里程碑，这正是Sprint的标所陈述的。在Sprint期间，团队可以有不同工作的自由，只要这个目标达到即可。

现在，团队将选择的Backlog分解成任务（目前在Scrum中将此定义为Spint backlog）。这些任务是工作的离散部分，由各个团队成员签约完成。执行任务完成Backlog，以便达到Sprint的目标。在Scrum中任务是由团队成员领取的，责任只能接受而非指派，这充分体现Scrum的重要特征——自组织团队。

应用结果

动态地确定项目工作和其优先级，根据：

• 客户的要求
• 团队所能做的

Scrum Meetings

环境（源自：Backlog）

你是一名软件开发人员或者一名管理软件开发团队的教练，在此团队中发现、创造或者实验创新占有很高比例。一个例子就是首次交付，在这里必须详细说明问题、必须创建对象模型等。

在诸如科学研究、创新、发明、体系结构、工程以及其他的活动中同样可以展示这种行为。

问题

什么是用来控制一个不可预知过程的最佳方法，例如软件开发、科学研究、艺术项目或创新设计，在这里很难定义所产生的产品和获得它们的过程？

作用力

估计

对于包括发现、创造或者实验性活动的精确估计是困难的。一般来说，它们包括大量的变化。这些不确定因素至少来自5个特性：

1. 需求未被很好地理解。

2. 体系结构方面的依赖关系不容易理解，并且持续变化。

3. 技术上可能有不可预知的挑战。即使事先知道这些挑战，他们的解决方案和相关的工作量也是不可知的。

4. 在软件中可能存在难以解决的Bug。因此，可能会看到对于项目的估计相差了几个数量级。

5. 另一方面，估计是重要的。必须能够确定在将来某个时间范围内的任务是什么，并且事先准备好资源。

规划

• 规划和重新确定优先级需要时间。工作人员参加时间计划会议降低了生产力。而且，如果系统是混乱的，没有什么能够减少不确定性因素。例子：因计划而导致瘫痪。某些项目把个人的时间浪费在计划每件事情到极端详细的程度上，但是永远也不能实现这些计划。
• 然而，一个过于详细的计划将变得庞大而且很难去遵循。计划越庞大，它所包含的错误越多（或者至少是证实其正确的成本将增大）。例子：总体规划是一个极大的谎言。很多项目试图遵循一个总体规划，实际上，却落入了相信他们的不准确的陷阱里，通常在他们的期望落空时感到失望。
• 没有任何规划增加了团队成员间的不确定性，最终损害士气。例子：愿景迷失。没有任何安排的项目往往失去对它们期望的控制。没有一点进度压力，将没有人去做任何事情，更糟糕的是，将很难把独立开发的不同部分集成在一起。

跟踪

• 过多的监视浪费时间，使开发人员感到压抑。例子：度量致死。项目把每个人的时间浪费在跟踪每件事情的极端细节上，但是永远也不能实现计划。
• 由于系统混沌的本质，跟踪并不能增加指示器的确定性。
• 过多的数据毫无意义。
• 不足的监视导致障碍及任务之间可能的停顿时间。例子：这里发生了什么？没有跟踪任何事情的项目往往失去对正在进行工作的控制。最终，没有人真正知道完成了什么。

解决方案

为正确地估计、计划和适当地跟踪做好准备。在每天例行的Scrum Meeting上花费短暂的时间（大约15分钟）与团队成员见面，唯一的活动是询问每个参与者下面三个问题：

（1） 自从上次Scrum Meeting以来，你都做了哪些工作？Scrum Master将已知完成的任务和那些还未完成的任务记入日志。

（2） 在刚刚过去的24小时中，你在执行任务中发现了什么障碍，如果有的话？Scrum Master将所有的障碍记入日志，过后寻找解决这些障碍的方法。

（3） 在未来24小时中，你将做什么工作？在架构师的帮助下，Scrum Master帮助团队成员选择合适的任务。因为任务的安排是以24小时为基础的，任务一般都是小规模的。

译注：Craig Larrman在此基础上增加了2个有用的问题。

（4）有没有任务添加到Sprint Backlog中？注意是指遗漏的任务，不是新的需求。

（5）相对于其他团队成员，你是否学到了一些东西或者做出了一些新的决定？（技术方面、需求方面）最后一个问题为持续进步和学习的团队提供了一个有效的讨论会，这对于敏捷开发是相当重要的。

这将提供给你更准确的估计、短期计划、适当的跟踪和纠错机制，来对变化做出反应，每24小时做出适应性改变。

每天的Scrum Meeting一般在相同时间和地点举行，所以它也可以达到创造浓厚文化的目的。同样，Scrum Meeting也是为团队增强社会化状态、问题和计划的仪式。Scrum Master主持会议，把来自每个团队成员的所有任务记入日志，作为全局的项目Backlog；他还将每个障碍记入日志，并在开发人员从事其他任务时解决这个障碍。

Scrum Board已经成为管理任务的最佳实践。团队在多栏Scrum Board前碰面讨论。第一栏为以大卡片形式的选自Product Backlog的按业务价值排序的用户故事（User Story）。在Sprint开始时，把从用户故事扩展而来的任务以小卡片的形式放在左栏中。每天软件开发人员将任务移至“处理中”（In Progress）一栏，然后是“验证”栏（Validation），之后是“已完成”（done）栏。每天更新任务的估计和Burndown Chart，容易计算，并在板上公布。

需要优先予以考虑的由Scrum Master记录的障碍日志，现在被称为障碍清单（Impediment Lis或Impediment Backlog）。 阻塞（block）是制约系统吞吐量的关键因素，应是Scrum Master优先关注的工作。校正开发项目类似于微调计算机系统。关键约束可能并不会明显存在，可能需要仔细分析才能得出。主要的瓶颈必须发现并第一时间修复它。开发系统作为整体应该允许稳定和可度量。

重新稳定后下一个关键阻塞可能在意想不到的地方出现。非瓶颈活动中的人员工作效率即使不高，也不会影响整体项目，使用关键资源来加速瓶颈活动中的工作。

Scrum Meeting不仅为开发人员安排任务，还可以并且应该为所有参与项目的人安排活动，比如从事配置管理的集成人员、架构师、Scrum Master或者QA团队。

Scrum Meeting也可以由自引导的团队举行。在这种情况下，需要指定一个人作为记录员，将Backlog中已经完成的和计划的活动以及现有的障碍记入日志。来自Backlog的所有活动以及障碍都将分发给团队成员来解决。

Backlog和障碍的格式可以有所差别，从写在纸上的项目清单到通过Internet/Interanet的软件表示法[Schwaber 1997]。Scrum Meeting的频率可以调整，一般可以定在2～48小时之间的任何位置。

Scrum Meeting通常站着举行会议，这确保了会议简短而且切中要害。

基本原理

由于非常容易产生高估或低估，这会导致闲置开发人员的时间，或者延误任务的完成。因此，最好经常对小规模的任务状态进行取样。具有高度不确定性的过程不可能仅用像甘特图（Gantt）或者计划评价与审查技术（PERT）图这样的传统项目计划技术，因为正在进行分析、实现或者创造的变化速率是非常高的。相反，对任务的持续重新确定优先级提供了一种适应性机制，这种机制提供了在短时间内对系统知识的采样。

同样，Scrum Meeting也能够帮助创造一种“参与的文化”（anticipating Culture）[Weinberg1997]，因为他们促进这些建设性的价值：

• 他们增强了全面的紧迫感。
• 他们促进了知识的共享。
• 他们鼓励了密集的交流。
• 他们促进了开发人员之间的诚实，因为每个人不得不汇报每天的状况。

这一机制鼓励了团队成员在发展的基础上社会化（Socialize）、外表化（Externalize）、内化(Internalization)并整合(Combine)技术知识，因而使技术的专业知识成为实践团体的共同财产[Nonaka1995]。因此，Scrum Meeting是具有深厚文化超越性的仪式。在相同地点、相同时间与相同的人会面增强了归属感，培养了共享知识的习惯。

已知应用

Mike Breedle，在位于芝加哥的Nike证券工作。自从1997年2月开始使用Scrum Meeting来运作我们所有的项目，包括企业过程重组（BPR）和软件开发。参与这些项目的每个人会接受为期一周的Scrum技术培训。

Yonat Sharon，在Elementrix Technologies工作。有一个项目在开发大约5个月后延期。它只完成了一小部分（大约20%），即使这部分也存在特别多的Bug。项目经理开始每2天举行一次短暂的状况会议（当时我们中没人知道Scrum这个词）。在接下来的一个月里，整个项目都完成，并且质量急剧上升。2周后，beta版发布。会议就此中止，之后这个项目就几乎没有什么进展。我不认为这个项目的成功应该全部归功于Scrum Meeting，但是它们在取得的这一成就中发挥了重要的作用。

在RAFEAL，软件团队中的一名团队领导实施了Scrum Meeting的一种变体。他每天都去每个开发人员那里，问那三个问题；同时他也管理Backlog。这没有团队建设的效果，但它的确提供了经常的采样。

C3和VCaps项目也做了这些工作。他们称之为“站立会议”（Standup Meeting）。实际上，极限编程XP（Extreme Programming）的站立会议正是Kent Beck从Scrum得到的启发。

应用结果

这个模式的应用导致：

• 高度可视的项目状态
• 高度可视的个人生产力
• 浪费在障碍上的时间减少
• 浪费在等待其他人上的时间更少
• 增强的团队社会化

结论

Scrum是一种在整个周期和工作期间具有高度信息共享的知识创造过程。

Scrum的关键就是确定我们想完成产品或者版本发布的日期、确定功能的优先级、确定可用资源以及做出体系结构方面的主要决定。与更传统的方法学相比，Scrum计划阶段比较短。Scrum使用一种用于开发的经验方法，在此法中不仅允许而且鼓励与环境进行交互。改变范围、技术和功能是在意料之中的，而持续的信息共享和反馈保持了高度的性能和信任。Scrum的应用同样也产生了一种具有良好定义的角色和关系的浓厚文化。

参考文献

[Goldrat1990] E. M. Goldratt, Theory of Constraints. Burlington, MA: North River Press, 1990.
作者为约束理论创建者，该书是原创性著作，深入阐述约束理论，解释如何寻找瓶颈及管理瓶颈。论述约束理论的5个步骤，如何推行约束理论、开发简单而有效的解决方案、推动变革。

[Holland1995] J. H. Holland, Hidden order : how adaptation builds complexity. Reading, Mass.:Addison-Wesley, 1995.
作为遗传算法之父和复杂性新科学的先驱者之一，Holland从一开始就处于复杂自适应系统(CAS，Complex Adaptive System)这一新兴研究领域的中心。该书展示了Holland的独特洞见。强调寻找支配CAS行为的一般原理，注重扩展众多科学家的直觉。其基本观点是个体的适应性导致了系统的复杂性。该书被誉为具有突破性贡献。

[Holland1998] J. H. Holland, Emergence : from chaos to order. Reading, Mass.: Addison-Wesley, 1998.
Holland的另一重要著作，该书也是对涌现现象进行深入探索的第一部著作。涌现的概念(即整体大于其各部分之和)简单得令人惊讶，然而它在科学、商业以及艺术等诸多领域中都具有极深的寓意。作者用深入浅出的描述向我们生动地阐明：涌现的理论能够预言许多复杂的行为，同时也给予我们关于生命、智慧和组织的很多启示。英国政府首席科学顾问，混沌理论创始人之一Robert May评价作者“极富有的想象力，带领读者穿越从简单性到复杂性的旅程，时而让人惊奇，时而让人迷醉”。作者也因此而获得当代“最具创新思想者”的声誉。

[Nonaka1995] I. o. Nonaka and H. Takeuchi, The knowledge-creating company : how Japanese companies create the dynamics of innovation. New York: Oxford University Press, 1995.
作者是提出Scrum开发方法的两位日本学者，该书是知识管理领域的原创性著作，融合了东西方精华。1996年，该书荣获美国出版学会“年度最佳管理类图书”大奖，该书也是被引用最多的知识管理类专著。

[Paulk1995] M. C. Paulk, C. V. Weber, B. Curtis, and M. B. Chrissis, The Capability Maturity Model?: Guidelines for Improving the Software Process. Boston: Addison-Wesley, 1995.
1993年美国卡内基-梅隆大学(Carnegie Mellon University)软件工程研究所(SET)以两份技术报告的形式发表了 The Capability Maturity Model: Guidelines for Improving Software Process (Addison-Wesley, 1995)。1995年，将一些介绍性的材料和软件CMM的当前版本合并在一起，SEI发表了能力成熟度模型：改进软件过程的指南(Addison-Wesley,1995)。该书为早期能力成熟度模型的重要参考文献。

[Schwaber 1997] K. Schwaber, "Ken Schwabers's Scrum Web Page," http://www.controlchaos.com, 1997.
Scrum创始人之一Schwaber关于Scrum的网站，学习和获得Scrum资源的重要来源之一。

[Senge1990] P. M. Senge, The Fifth Discipline: The Art and Practice of the Learning Organization, New York: Doubleday, 1990.
学习型组织之父senge的开拓性地倡导学习型组织管理思想的巨作，出版后连续3年荣登全美最畅销书榜首，1992年荣获世界企业学会（World Business Academy）最高荣誉的开拓者奖（Pathfinder Award）该书被评为“世界上影响最深远的管理书籍”之一，被誉为学习型组织必读的“圣经”。

[Sutherland1997] J. Sutherland, "Jeff Sutherland's Scrum Log," http://jeffsutherland.com/scrum/index.html,1997.
Scrum的创始人之一Sutherland提供各种与软件编程和技术相关的内容，特别是对象、构件和Scrum。该网站时常更新，具有教育意义。Scrum理论与实践的重要基地。

[Weinberg1997] G. Weinberg, Quality Software Management Vol. 4: Anticipating Change: Dorset House,1997.
美国计算机界的泰斗Weinberg，该书为其包含4本独立分卷的系列丛书进行了总结，为软件企业变革过程中的管理工作提供注重实效、内容详实的最后交待。

[Wiki1999] W. Cunningham, "Wiki Wiki Web," http://c2.com/cgi/wiki, 1999.
XP创始人之一和Wiki之父Cunninghan，该系统集中了数千人的知识于一个（半）连贯的整体之中。从一个设计模式的目录系统，Wiki已经成长为包含了数百页XP相关页面的系统。http://c2.com/cgi/wiki?ExtremeProgramming是XP的讨论与演进的最重要的基地。