SCRUM精髓

目录

• 引子
• Scrum框架
• 敏捷原则
• 冲刺(迭代)
• 需求与用户故事
• 产品列表
• 估算与速率
• 技术债
• 产品负责人
• 敏捷教练
• 开发团队
• 职能经理

引子

什么是Scrum

Scrum是一种用于开发创新产品和服务的敏捷方式，在敏捷方式中，首先要建立产品列表，在产品列表的指导下，我们总是先做最重要或优先级最高的条目。在每个迭代中，自组织、跨职能的团队完成所有必须的工作。

在每个迭代开始时，团队需要制定计划，在迭代结束时，团队和利益干系人一起评审已经完成的特性，获取他们的反馈。根据反馈，产品负责人和团队既可以对下一步工作内容进行修改，也可能修改以前的工作方式。

在每个迭代结束时，团队应当得到一个潜在的可发布产品。

为什么要用Scrum

我们构建的是开创性的产品，我们需要一种开发方式，能够让我们快速探索新想法和新方法，快速了解哪些解决方案可行、哪些不可行。

我们还想避免实现进行大量架构设计，我们需要采取另外一种更均衡的设计方法，开始时做一些设计，再结合进行适量、适时的设计。

团队也需要采取进一步跨职能，我们的目标是每天都能做到协调一致。

Scrum框架

概述

Scrum不是一个标准化过程，Scrum是一个用于组织和管理工作的框架。Scrum框架建立在一套价值观、原则和实践之上。

Scrum以人为中心，以诚实、开放、勇气、尊重、专注、信任、授权和合作八大价值观为基础。

Scrum角色

Scrum角色组成：产品负责人、敏捷教练和开发团队。

产品负责人负责敲定要开发什么、以什么顺序开发。

敏捷教练负责指导团队在通用的Scrum框架上建立并遵循自己的过程。

开发团队负责确定如何交付产品负责人要求的产品。

产品负责人

产品负责人是有授权的产品领导力中心。他是唯一有权决定要构建哪些特性并以何种顺序构建这些特性的人。对于Scrum团队要实现的目标，产品负责人要保持一个清晰的构想并把它传达给每一位参与者。产品负责人还有责任确保总能完成价值最高的工作。

敏捷教练

敏捷教练帮助每个参与者理解并乐于接受Scrum的价值观、原则和实践。在过程方面发挥教导作用。作为辅助者，敏捷教练要帮助团队解决问题和改进Scrum的使用状况，清除阻碍团队生产率的障碍，敏捷教练没有权力控制团队，他是领导者，但不是管理者。

开发团队

Scrum定义的开发团队的角色，是一个由几种职位的人组成的多样化、跨职能团队，负责产品的设计、构建和测试。开发团队进行自我组织，确定采用哪种最佳方式来实现产品负责人设定的目标。开发团队一般是5到9人，作为一个整体，必须具备多种技能以构建高质量、可工作的软件。

Scrum活动

产品负责人建立产品愿景，通过梳理活动分解为一组特性并收集到列表按优先级排序的列表中。

在每个冲刺(迭代)开始的时候，开发团队必须把自己认为能够完成的PBI的子集确定下来，这个活动称为冲刺(迭代)计划，这个子集被称为冲刺(迭代)列表。

接下来是冲刺(迭代)执行，冲刺(迭代)过程中的每一天，团队成员都要进行同步、检查、与调整计划，通过每日例会这种活动来帮助管理工作流。

Scrum团队在冲刺(迭代)结束时要执行两个活动，第一个活动称为“冲刺(迭代)评审”，利益干系人和Scrum团队回顾正在构建的产品，第二个活动称为“冲刺(迭代)回顾”，Scrum团队在这个活动中回顾构建产品时所用的Scrum过程。

产品列表

在使用Scrum时，我们总是先做最有价值的工作。产品负责人结合Scrum团队其他成员与利益干系人的意见，最终负责确定和管理工作顺序。

产品列表包含新特性、对现有特性的变更、需要修复的缺陷以及技术改进点等。

产品负责人与内外利益干系人合作收集并定义PBI。建立和优化PBI、估算并确定他们的优先顺序，这样的活动称为“梳理”。

除了排序外，还需要知道产品列表中每个条目的大小，大小等同于成本，为了合理确定条目的优先级，产品负责人需要知道条目的成本，在实践中，很多团队使用相对大小测试，如故事点数，或理想天数。

冲刺(迭代)

每个冲刺(迭代)完成的工作应当创建一些对客户或用户来说具有明确价值的东西。

冲刺(迭代)是有一定时间范围的，总是有固定的开始和结束日期，而且一般来说冲刺(迭代)的持续期应当是相等的。

制定冲刺(迭代)计划

为了确定下一个冲刺(迭代)要构建的PBI最重要的子集，产品负责人、开发团队、敏捷教练需要做冲刺(迭代)计划。

在做计划期间，产品负责人和开发团队要对当前冲刺(迭代)准备实现的冲刺(迭代)目标达成一致意见，确定在以可持续的节奏工作时根据实际情况在当前冲刺(迭代)中能够完成高优先级的条目。

接下来，开发团队给出完成每项任务所需工作量的估算值。

大多数Scrum团队在执行一个两周到一个月的冲刺(迭代)时，都尽量在大约4到8小时内完成冲刺(迭代)计划。我常用的方法是遵照一个简单的循环：选择一个PBI（已排序的），把条目分解成任务，确定把所选择的项目放到冲刺(迭代)中是否合适。如果合适并且还有更多的能力完成工作，可以重复这个循环的过程。

冲刺(迭代)执行

执行为了完成特性而所需的所有任务级的工作，此处所说的“完成”指的是非常有信心的认为对于产出高质量特性所需的所有工作都已完成。

团队成员要定义自己的任务级工作以什么顺序、什么方式，然后按照自认为最好的方式进行自组织并实现冲刺(迭代)目标。

每日例会

在冲刺(迭代)期间的每一天，理想的做法是在每天同一时间，开发团队举行一定时间范围内（不超过15分钟）的每日例会。

敏捷教练要确保会议顺畅，每个成员要轮流回答三个问题，让其他成员了解情况。

• 在上次每日例会之后我完成了什么？
• 在下次每日例会之前我计划做什么工作？
• 有什么障碍让我无法取得进展？

每日例会不是用来解决问题的。具体的问题会放到每日例会之后和一小部分感兴趣的人讨论。

完成

“完成”的最低限度的定义是应当产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档。

“潜在可发布”并不是说构建的东西必须实际交付。交付是一个业务上的决策，经常受其他因素的影响。

冲刺(迭代)评审

这个活动很重要的一点是相关人员都要参与，包括Scrum团队、利益干系人、发起人、客户和其他感兴趣的成员。

评审的重点是把刚刚做完的特性放到整体开发工作的背景下进行讨论。成功的冲刺(迭代)评审会议可以促成双方充分交流信息。非Scrum团队的人员能够跟上开发工作并帮助指导开发方向。

冲刺(迭代)回顾

冲刺(迭代)回顾是总结并调整过程的时机。重点关注的是必要的持续过程改进，团队应当找出数量适中的过程改进项并在下一个冲刺(迭代)中采用。

敏捷原则

对于明确定义、可预测且不可能发生任何重大变更的问题，计划驱动开发方式是很适用的。问题是，大多数产品开发工作根本就不可预测，刚开始的时候尤其如此。

Scrum则奉行另一套不同的理念，该理念很好地处理了高不确定性而导致很难作出宏观预测这个问题。

积极采用有帮助的可变性

产品开发和制造业完全不同，在软件产品开发行业，我们的目标不是制作产品，而是创造产品的单个实例。

采用迭代和增量开发

迭代开发承认我们在把事情做对之前有可能做错。可以先创建原型以获得重要知识。

对冲刺(迭代)思想的一种误解是，每个冲刺(迭代)只集中做一种类型的工作，例如，冲刺(迭代)1（分析），冲刺(迭代)2（设计），冲刺(迭代)3（编码），冲刺(迭代)4（测试）。

在Scrum中，并不是每次做一个阶段的工作，而是每次做一个特性。

在冲刺(迭代)结束时，可以把新近完成的特性与已经完成的特性放到一起并获得反馈，这有助于我们纵观全局，获得其他方法可能得不到的见解。

通过检视、调整和透明充分利用可变性

计划驱动的顺序开发过程假设产出物的可变性很小或不存在，Scrum假设必然存在一定的可变性，产品创建过程很复杂，无法事先给出详尽、严密的完整定义。尽早频繁的反馈过程，可以确保构建的产品是正确的，构建方式是正确的。

不确定性包括：结果不确定性，方法不确定性，特定环境或特定产品还可能有客户不确定性。

不到最后时刻，不轻易做决定

Scrum认为，不该单单因为通用过程要求此时作出决定，我们就得做出不成熟的决定。我们应该在掌握更多信息后再做决策，推迟作出承诺，直到最后责任时刻再做出重要的、不可逆转的决定。

承认无法一开始就把事情做对

计划驱动的过程不仅要求有完整的需求和全面的计划，还想当然地认为事先就能“把事情做对”。更糟糕的是，一旦需求有变，还得根据当时实际情况修改需求和计划

在Scrum中，我们承认自己不可能事先确定所有需求或计划。我们也预先产生需求和计划，但原则是够用就好，一旦了解更多在建产品的相关知识，我们就会填充需求和计划的细节。

偏好适应性，探索式的方法

Scrum更倾向于恰当运用探索式方法，在此基础上采用适应性的试错法，面对不确定，我们通过探索来获取更多可用信息。

现在的工具和技术越来越好，探索成本也随之下降，快速构建少量内容并根据用户反馈进行调整，其成本往往低于事先投入精力试图一次性做对所有事情。

在面对不确定性时，不要一厢情愿的预测，要用低成本的探索方式来换取相关信息，并综合利用这些信息得出明智、合理的最终解决方案。

用经济合理的方法接受变化

我们都知道，使用顺序开发方式时，后期变更成本比早期变更成本高很多。

为避免后期变更，顺序开发过程的做法是设法提高预测的准确度，力求最小化需求和设计变更。

不幸的是，早期活动阶段的过度预测往往适得其反。

在Scrum中，我们认为变更是很正常的，必须准备好主动迎接变更。

在使用Scrum时，很多工作产品都是以刚好及时的方式产生的，以免发生变更时，不必丢弃或重新修改。

平衡好事前工作和及时工作之间的关系

在Scrum中，我们相信前期工作有帮助，但不宜过度。

快速验证重要的假设

在Scrum中，任何时候的重要假设都要力求最少，我们不想重要的假设久久得不到验证。

利用多个认知循环并行的优势

在Scrum中，我们知道持续获取认知是成功的关键，在这种产品开发方式中，有一个反复出现的模式，即提出一个假设，构建一些东西，针对构建成果获得反馈，然后利用反馈，对我们提出的假设来评估工作成果。

妥善组织工作流程以获得快速反馈

容忍假设长期存在，也造成计划驱动过程容忍认知到后期才获得，所以说计划驱动过程并不注重快速反馈，在Scrum中快速反馈对较早截断错误路径有非常重要的帮助作用。

批量大小要经济合理

在Scrum中，我们认为虽然规模经济的思想已经成为制造业的基本原则，但把它生搬硬套到产品开发中，会造成重大的经济危害。

在产品开发中采用小批量的方式，甚至一次只处理一个需求，有人将这个过程称为“单件流程”。

识别并管理库存以达到良好的流动

制造业有一个值得软件开发行业借鉴的教训，就是库存的高成本。精益产品开发社区早在很多年前就懂得WIP的重要性。

一般情况下，软件开发企业根本意识不到自己时有WIP的。在开始开发时，确实需要有一些需求，但并不需要全部需求。

如果太多，在需求发生变化时，很可能造成库存浪费。

我们还要认识到，需求只是产品开发中的一种库存。

关注闲置工作，而非闲置人员

在Scrum中，我们深信闲置工作比人员更浪费，经济危害也更大。

很多软件开发企业更关注如何消除闲置人员所造成的浪费，而非闲置工作所造成的浪费。

在Scrum中，我们敏锐地认识到：需要找出工作流的瓶颈并集中精力消除它，相较于努力让每个人都100%连轴转，这样做更加经济合理。

考虑延期成本

延期成本是工作延期达成所产生的财务成本，不幸的是，85%的组织都没有对延期成本进行量化。

在产品开发过程中，我们会持续面临这种权衡：要想作出经济合理的决定，延期成本是一个需要考虑的、最重要的变量。

根据实时信息来重新制定计划

在Scrum中，我们的目标不是满足某个计划或者某个事先认为事情如果进展的预言，相反，我们的目标是快速地重新制定计划并根据开发过程中得到的信息进行调整。

通过验证工作结果来度量进度

在使用Scrum时，不是用既定计划的执行情况来衡量进度，也不是看某个特定期间的工作有多大的进展，而是用已交付且验证过的结果来衡量。

完全按计划制造出来的产品可能与客户期望得到的交付价值相去甚远，这算得上成功吗？

在Scrum中，重要的不是开始了多少工作，而是完成了多少对客户有价值的工作。

聚焦于以价值为中心的交付

Scrum是一种客户价值为中心的开发方式。它是基于优先级排序的增量交付模型。价值最高的特性持续构建并在下一个迭代中交付。这样一来，客户就可以尽快且持续获得高价值特性。

快速前进，但不匆忙

在Scrum中，虽然时间很重要，但并没有要我们匆忙行事。人们应该以长期稳定的节奏工作，而且匆忙还可能付出牺牲质量的代价。

以质量为魂

计划驱动的开发过程秉承这样的理念：小心、顺序地执行工作以得到高质量的产品。但是只有对集成后的产品进行测试，否则不能真正验证质量，然而，集成测试在整个流程中是滞后的，如果测试结果表明质量欠佳，就必须进入高成本的“测试——修复”阶段，通过测试来改进质量。所以测试团队常常被认为是产品质量的最终负责人。

在Scrum中，质量并不是测试团队在最后阶段“测”出来的，而是由跨职能的Scrum团队负责并持续内建于每个冲刺(迭代)中。

采用最小够用的仪式

计划驱动的开发过程倾向于重仪式、以文档为中心、重过程的方法。

在Scrum中，我们的目标是消除可有可无的繁文缛节，因此我们为仪式设定了一个较低的标准，也就是“基本够用”。

Scrum关注最小够用仪式，这常常被曲解为“Scrum是反文档的”，Scrum并不反对文档。相反，在使用Scrum时，我们是从经济角度仔细审查需要创建哪些文档。

尽量避免不增加任何短期和长期经济价值的工作。在Scrum中，我们深信，时间和金钱最好用于交付客户价值。

冲刺

冲刺是在时间盒内完成的，持续时间短并且长度一致，冲刺开始后就不能再改目标，必须达到团队的完成定义中要求的最终状态。

时间盒

每次冲刺都发生在一定的时间期限之内，有明确的开始日期和结束日期，称为一个时间盒。

团队应该只开发自己认为在一个冲刺内能够开始并结束的工作条目。

时间盒强制我们按照优先级排序并执行最重要的小批量工作，这样一来，我们的注意力可以更集中于快速完成有价值的事情。

时间盒能帮助我们确保每个冲刺都能产生有价值的、可度量的进度。

时间盒为冲刺设定了一个固定的结束日期，通过这种方式来强制结束由于不必要的完美主义导致的无休止的工作。

当团队有一个确定的结束日期时，事情更有可能做完，如果没有确定的结束日期，人们就不会有完成工作的紧迫感。

使用时间盒可以增强可预测性。虽然我们不能准确预测从现在开始一年内要完成哪些工作，但预测在下个冲刺中能够完成的工作是完全可以做到的。

持续期短

持续期短的冲刺更容易规划。

持续期短的冲刺可以产生快速的反馈。

持续期短的冲刺还可以更早、更频繁地交付。

能够进行频繁的改进，即使出错，也是小错。

如果做的项目持续期非常长，不仅失败的可能性增加，还可能最终失去工作热情。

一致的持续期

冲刺中稳定的节奏感使单调而必要的活动成为习惯，从而留出心力，集中做有趣、增值的工作。

以稳定的节奏执行冲刺也能大幅降低协调成本。

使用长度一致的持续期还可以简化计划活动。

衡量进度变得容易。

锁定冲刺目标

Scrum有一条重要的规则：一旦制定冲刺目标，在冲刺执行开始后就不允许有任何变更。

冲刺目标描述当前冲刺的商业目的和价值。冲刺目标通常有清晰而单一的重点。

团队承诺在当前冲刺结束之前完成目标，产品负责人承诺在冲刺执行过程中不更改目标。

通过定义和遵循冲刺目标，Scrum团队能够一直高度关注一个明确定义的、有价值的目标。

虽然冲刺目标不该有实质上的变更，但是允许澄清这个目标。

澄清是在冲刺执行期间提供更多的细节来帮助团队实现冲刺目标。例如：“你对列表排序方式有什么偏好吗？”，产品负责人说：“有，按照姓氏字母顺序排序”

”锁定目标“这个规则看似有悖于Scrum核心原则所说的”接受变化“，我们确实要乐于接受变化，但要用一种平衡的、经济合理的方法。

变更的经济后果随着我们在变更工作中投入的增加而增加。除了浪费这样的直接经济后果，变更还可能损害团队的士气和信任关系。

”锁定目标“只是一个规则，并不是铁律。Scrum团队要注重实效。归根结底，注重实效胜于”锁定目标“这个规则。

提前终止冲刺，除了对士气有负面影响外，还会使快速、灵活的特性流混乱。终止冲刺应该是不得已而为之的最后手段。

完成的定义

为了确定开发出的东西是潜在可发布的，Scrum团队必须有一个明确定义的、大家一致同意的完成的定义。

在大多数情况下，完成的定义至少要产生一个产品功能的完整切片，即经过设计、构建、集成、测试并编写了文档，能够交付已验证的客户价值。

如果一个团队构建软件而没有在实际的硬件测试，是不能声称在每个冲刺结束时产生的结果是潜在可发布的。

需求与用户故事

Scrum项目跟传统项目对于需求的处理方式不同，顺序开发中，需求不可协商、早早地就已细化并且是独立的，Scrum中，需求细节是在开发期间持续不断的对话中商讨出来的。

顺序产品开发对待需求的方式跟制造业很像：需求是必需的、不可协商的规格说明书，产品必须与之相符。

Scrum则认为，可以自由掌控需求是达成业务目标的关键。例如：如果缺乏时间和资金，可以放弃低价值的需求；如果有新的高价值需求涌现，而且我们也有能力把它加入产品，就可以考虑放弃一个低价值需求为它留出空间。

因此，使用Scrum时，我们不会在前期就投入大量的时间和成本详细描述需求，因为我们认为，等过段时间进一步了解特性之后，细节是会变的，所以要避免在今后可能丢弃需求上投入太多精力和时间。

最开始的时候，PBI(产品待办项)的个头很大，相关细节很少。随着时间推移，经由干系人、产品负责人、及开发团队围绕这些PBI所进行的一系列对话，他们被修订成了更小、更详细的PBI，最终，一个PBI应该够小且足够详细，可以放入一个冲刺，完成设计、构建与测试。

就算是进入了冲刺，也还会有更多细节在产品负责人与开发团队之间的对话中冒出来。

在这本书里，我采取用户故事的形式来表现PBI。

利用对话

需求是一种沟通工具，可用于引导大家对特性达成共识。

顺序产品开发严重依赖于书面需求，他们看着不错，但很容易被误解。

在Scrum中，我们将对话用作确保需求可让妥善讨论与沟通的关键工具。口头沟通具有高带宽和可提供快速反馈的优势，能够更简便地取得共识。另外，对话使双向沟通成为可能，可以激发与问题和机会相关的想法，阅读文档可没有这种效果。

不过，对话也只是个工具而已，他并不能代替所有文档。

产品列表是产品开发期间一直存在的“活文档”。只需收集PBI及所有相关细节，将它们放入一个文档。

逐步细化

并非所有需求都必须在相同时间做到同样详细。即将要做到的需求比一段时间内不准备开发的需求更小更细。

用户故事

用户故事是可用于陈述业务价值的一种简便格式。

用户故事的结构：卡片、会话、确认

卡片

写用户故事有一个通用模板，即写明用户种类(角色)，这类用户想要达成什么目标，以及用户为什么想达成此目标(价值)。

用户故事模板：

用户故事标题
作为<用户角色>，
我想<目标>，
这样可以<价值>

用户故事示例：
作为一名典型用户，
我想看到某地址周围餐馆的公正评论，
这样可以帮助我决定去哪里吃饭

卡片不是为捕获需求的所有组成信息而设的。实际上，我们故意使用空间有限的小卡片，目的就是让用户故事尽可能简洁，它存在的意义是提醒利益关系人、产品负责人及开发团队进行更深入的讨论。

会话

开发团队、产品负责人和利益干系人会在对话中发现并探讨需求的细节。

会话不是一次性事件，而是持续的深度交谈，在设计、构建、并测试用户故事的时候都有持续对话。

用户故事的一大好处在于它能把关注点从写作转移到会话。对话开启了一个更丰富的信息交换与协作形式，从而确保正确描述需求并使每个人都能理解需求。

尽管会话主要依靠口头交流，但仍然需要借助于文档。会话可能得出可以记下来的一张用户界面草图或业务规则的一份详细阐述。

确认

用户故事还要包含确认信息，他体现为满意条件的形式，是验收标准。利用它们，开发团队可以更好地理解要构建和测试什么，产品负责人可以确认用户故事的实现是否符合预期。

这些满足条件也可以看作是高一级的验收测试。

详细程度

如果用户故事大小都一样，就很难做好概要计划并体会到逐步细化的好处，例如：在冲刺级使用的故事太小太多，是无法为概要产品规划和发布规划提供支持的。

可以编写不同抽象层级的用户故事来捕获客户及用户需求。

最大的故事约为一两个到好几个月的大小，可跨越一整个或多个版本。许多人称其为“史诗”。我们永远不会把史诗放入冲刺。史诗是一个很好的占位符，等将来到合适的时间再创建大量更加详细的故事。

第二级别故事的大小通常以周为单位，对单个冲刺来说还是有点大。许多人称之为“特性”。

最小的用户故事我们通常称之为“故事”，他们的大小以天为单位，可以放入一个冲刺做完。

任务位于故事下面一级，通常是一个人独立完成的工作。

史诗、特性、故事等术语不过只是为了方便而使用的符号，重要的是意识到故事在多个抽象层级上都是存在的。这样做正好支持我们在多个不同抽象层级进行计划并随时间推移逐步将大的条目细化成小的条目。

好故事的INVEST原则

独立

用户故事应该是独立的，至少是相互间松散耦合的，这样才实用。相互依赖程度高的故事会使估算、排优先顺序和规划复杂化。

可协商

故事细节应该是可协商的。好故事能够清晰地捕获哪些业务功能是用户想要的，他们为什么想要。产品负责人告诉团队如何实现故事，这是违背可协商性的常见例子。用户故事关心的是做什么以及为什么这么做，而不是如何做。如果如何做变得不可协商，就会减少团队创新的机会。由此而导致的创新浪费可能造成毁灭性的经济影响。

并非所有故事都完全可协商，但大多数故事都应该如此。

有价值

有价值的标准的关键在于，列表中所有故事都必须由产品负责人以客户与用户代言人的身份认可他们的价值。

不是所有的故事都是独立的，也不是所有的故事都是可协商的，但它们必须都是有价值的。

大多数技术故事实际都不应该纳入产品列表，相反，这类故事应该属于完成业务价值故事所涉及的任务。

可估算

故事应该是做设计、构建及测试工作的团队可以估算的。

产品负责人知道故事成本之后才能最终确定优先级。

如果团队无法衡量故事的大小，原因可能有两个：这个故事太大或太模糊。

如果故事太大，就需要大家一起把它拆分成更容易管理的故事。

如果是团队缺少知识，就需要通过某些形式的探索活动来获取信息。

大小合适

已计划开工的故事应该是大小合适的。

相反如果我们今年都不打算做掉它，如果我们现在就花时间把它拆成一堆更小的故事，很可能是白白浪费时间。

可测试

可测试意味着故事要有明确的验收标准。要是没有可测试的标准，冲刺结束时我们怎么知道故事有没有做完呢。另外因为这些测试往往提供重要的故事细节，所以团队很可能需要这些测试来估算故事的大小。

非功能性需求

非功能性需求代表了系统级约束。作为系统级约束，非公能性需求很重要，因为他们会影响产品列表中绝大部分或全部故事的设计和测试。

所有非功能性需求都是团队应该纳入完成定义的主要目标。

知识获取型故事（技术调研）

有时，我们需要创建一个专注于知识获取的PBI，我们或许会因为缺乏足够的产品或产品构建流程相关知识而驻足不前，这种探索有很多情况：原型、概念验证、试验、学习。

这个特殊的知识获取型故事看起来就是一个技术故事。任何技术故事的业务价值都必须能向产品负责人清楚说明。Scrum团队则需要考虑，信息的价值是否值得我们付出精力和时间。

收集故事

让用户当评论家远比当作家好得多。

更好的方法是让用户也作为团队的一员，一起判断要构建什么并持续审视构建的特性。

用户故事写作研讨会

用户故事写作研讨会的目的在于，集体进行头脑风暴，讨论预期的业务价值。

参加研讨会的通常是产品负责人，敏捷教练，和开发团队。还有内外部利益干系人。

绘制故事地图

好的故事地图从用户的视角展示活动流，并为理解单个故事及其与整个客户价值之间的关系提供背景信息。

他们让我们专注于探讨如何在交付完整用户价值流的上下文中写故事。我们可以进一步确定自己是否遗漏与工作流有关的重要故事。

故事地图提供的是产品列表的二维视图，以替代传统的线性产品列表。

我们使用史诗、主题、冲刺故事来描述故事地图，最高级的是史诗，代表对于用户有着重要经济价值的大型活动。

接下来我们再探讨组成该史诗用户任务的顺序或通用工作流（主题），把主题沿着时间线展开，将工作流中通常较早的发生的主题置于较晚发生的主题的左侧。

接着再把主题逐个分解成一套可实现的故事，按照优先级顺序垂直排列，不需要把主题内的所有故事都放入同一个版本里。

产品列表

概述

产品列表是一个按优先顺序排列的、预期产品功能列表。产品列表是Scrum框架的核心部分，非常重要，项目所有参与者都能看到。

产品列表由各个待办事项组成，我们称之为：PBI(Product Backlog Item)，或简称条目。

产品列表的四大特征（DEEP）

• 详略得当
• 涌现的
• 做过估算的
• 排列好顺序的

DEEP标准有助于判断产品列表的结构是否恰当。

详略得当

马上要做的PBI应当放在列表顶部，工作量小，内容非常详细，可以在最近一个冲刺中实现。

在马上要做的大的PBI的时候，我们会把它分解为一组小的、可以在一个冲刺中处理的故事，这是实时进行的。

涌现的

只要有正在开发和维护的产品，产品列表就永远不会完成或冻结。它会根据不断涌入的、具有经济价值的信息持续更新。随着时间的推移，产品列表渐渐变得有条理。在增加新条目或细化现有条目时，产品负责人必须考虑新涌现的信息，让产品列表重新保持平衡并重新排序。

做过估算的

产品负责人把这些估算纳入考虑范围以帮助确定PBI的优先级。

排列优先顺序的

对接下来几个冲刺中确定的要做的近期条目，排好优先顺序很有用。远期条目排列优先顺序，真的是浪费时间。

梳理

为了得到一个良好的、符合DEEP原则的产品列表，必须积极主动地管理、组织、监督或者叫做“梳理产品列表”

什么是梳理？

梳理指三大重要活动：

• 确立并细化PBI
• PBI进行估算
• 为PBI排列优先顺序

由谁来梳理？

梳理产品列表是一个持续不断、合作完成的活动，由产品负责人牵头，包括内外部利益干系人中的主要参与者，还包括开发团队。

梳理活动有一个最终决策者：产品负责人

让各种各样的团队成员都参与梳理活动，可以确保每个人更清晰、更一致地理解产品列表，减少因为信息错误传达或交接而浪费的时间，还有助于消除业务人员和技术人员的隔阂。

何时梳理？

在Scrum中，我们假定环境是不确定的。因此必须准备好随时检视和调整。我们预计产品列表会不断演变，而不是早早固定下来。

最开始的梳理活动是纳入版本规划活动进行的。

每周一次或每个冲刺一次的梳理活动研讨会。

有时候团队喜欢把梳理活动分摊到冲刺中，他们在每日例会后拿出一点时间来做增量的梳理活动。

就绪的定义

梳理产品列表时，应当确保列表顶部的条目已就绪，可以放入冲刺列表中。

“就绪”和"完成"是PBI在一个冲刺周期中的两种状态。

就绪定义检查表

工作流管理

理想情况是存量中只保留足够的PBI，保持工作流稳定，但又不至于因为条目太多而造成浪费。

产品列表有哪些，应该有多少？

一个产品，一个产品列表，即每个产品都应当有自己单独的一个产品列表

估算与速率

概述

在规划和管理产品开发过程中，我们需要回答一些重要的问题，例如：“将要完成多少个特性？”，“我们什么时候做完？”，“这需要花多少钱？”

为了能回答这些问题，我们需要估算产品的工作量大小并测算工作速率。

何时估，估什么？

在整个生命周期中，需要在不同粒度级别上进行评估，因此，我们会使用不同的单位。

产品列表条目的估算

估算PBI是整个产品列表梳理活动的一部分。

估算的首要价值之一是在估算交流过程中获得的认识，要求大家进行估算，立刻就会有不一致的意见浮出水面，暴露假设，这样做最能激发有益的讨论，如果不做估算，则需要另外一种有效的替代方法。

任务估算

冲刺列表中最详细的条目就是任务。

任务按照理想工时来排列大小，它只说明团队完成这个任务需要多少工作量，实际可能需要的工时会更多，因为有其它干扰会占用一部分时间。

PBI估算的概念

团队估算

在传统组织中，项目经理、架构师或主程序员可能负责预估，在Scrum中我们遵循一个简单的规则：大家一起估算。

产品负责人负责阐述PBI，并回答团队要求澄清的问题。敏捷教练的目的是帮助指导和引导估算活动。

最终目标是开发团队能够集体确定每个PBI的大小。根据专业领域不同，每个人理解故事的视角也不同，所以让开发团队的每个成员参与估算非常重要。

估算不是承诺，如果估算变成承诺，那估算值很可能会被放大。

估算应该准确，但不必过分精确。

估算单位

估算没有标准单位，不过目前常用的两个单位是故事点和理想天数。

故事点用于衡量PBI的大小和数量。

故事点受很多因素的影响，如复杂度和实际大小。

理想天数是很常见的单位，理想时间和实际时间不一样，实际时间可能受到一些会议、假期、或临时任务影响。

如果在你的组织里不会误解理想时间，理想时间可能会好一些，如果觉得有人会误解理想时间，最好采用故事点。

估算

为了进行估算活动，团队必须用一组数字给估算结果赋值。

最常用的数值范围是由Mike Cohn提出的，部分基于修改过的斐波那契数列：1，2，3，5，8，13，20，40，100。

在进行估算活动时，整个Scrum团队都得在场。

在这个会议上，产品负责人介绍、描述和澄清各个PBI。

敏捷教练引导团队使用规划扑克，如果哦发现人们的身体语言或沉默不语好像不赞成估算结果，就要帮助他们参与估算过程。

规划扑克牌的一般性解释

什么是速率

速率是每个冲刺完成的工作量。在冲刺结束时由已完成的所有PBI大小之和来衡量。速率不包含未完成的PBI。

速率衡量的是产出，而不是价值。

使用速率有两个目的，一个是版本大小除以团队的平均速率，就可以算出需要多少个冲刺才能完成这个版本。还可以用来帮助确定团队在下一个冲刺中能完成多少工作量。

团队还可以使用速率作为诊断性指标，用来评价和提高使用Scrum来交付客户价值的能力。

计算速率范围

为便于做计划，速率用范围来表示往往最有用，例如：这个团队通常每个冲刺能完成25到30个故事点。

在产品开发早期，我们对产品知之甚少，不可能给出特别精确的答案。通过使用范围，我们可以传达出这种不确定性。

为了计算这个范围，需要知道团队的两个速率。如果版本的工作量大小除以团队较快的速率，我们就得到最少冲刺数。如果将版本的工作量大小除以团队的较慢速率，就得到最多冲刺数。

预测速率

如果团队有历史速率数据，不需要预测就知道团队的实际速率。当然前提是有一个稳定的团队。

如果是新组建的团队，就需要预测速率。第一次冲刺团队可以根据经验选择适量的PBI，冲刺完成后，再计算速率。

一旦团队做过一个冲刺，我们就可以得到一个实际的速率，此时应该丢弃预测速率而使用实际速率。

影响速率的因素

如果团队一直坚持持续改进，团队速率也会变得越来越快。

团队的速率趋于平稳，并不意味着没有上升的空间。Scrum团队和经理有许多方法能帮助团队把速率提高一个台阶。，如引入新的工具或加强培训。

当然我们还可以做一件事来试着提高速率：加班。连续加班在一开始可能会提高速率。但经历这样的提高后，几乎都会经历一次陡降，同时还伴有质量的下降。最后的结果是，过多加班虽然可以得到一些短期收益，但是和长期的后果相比，常常没有价值。

速率的误用

速率是一种计划工具，也可以作为团队诊断指标。它不应该作为一种绩效指标来判断团队的生产率。

技术债

代码写好就交，意味着欠债的开始。稍微欠点儿技术债的确可以加快开发速度，
但前提是事后及时重写代码，如果只借不还，后果很危险。
在不准确的代码上所花的每一分钟，都算是技术债的应付利息。
不稳固、脆弱的代码实现所引发的债务负担，会使整个工程组织陷入裹足不前的艰难境地......

团队和组织在深入了解业务领域的同时，还要注意偿还技术债。

技术债既指我们有意选择的捷径，又指许多损害软件系统的不良实践。

有些技术债是由于团队成员或业务人员设计粗糙、工程实践糟糕和测试不足导致的，这些技术债时可以消除的。

还有一种不可避免的技术债，通常无法预测，也无法预防。例如我们无法事前完美预测产品和设计随时间的推移需要如何演进。如此一来，随着我们完成重要的认识循环并获得经验认知，可能需要修改早期做出的设计和实现决策。这种受影响而必须做的改动就是不可避免的技术债。

最后一种技术债是策略性的技术债。这种技术债可以作为一种工具，帮助组织从经济角度更好地量化和权衡重要的决策。

无论技术债是怎样产生的，技术债都是一个很形象的隐喻，因为它提高了人们对重要无奈替的认知度和可见性。

就像财务债，最重要的是技术债也要支付利息，通常以将来额外再补做开发工作的形式。

技术债的后果

技术债日积月累，造成的后果会越来越严重。

技术债有一个重要的特质，它是以不可预测的非线性方式增长的。这种非线性特征是一个不容忽视的业务风险，因为我们不知道最后一根稻草何时会压垮骆驼，然而一旦发生，后果不堪设想。

承担技术债意味着现在向未来申请借用工作时间。今天的债务越多，明天的速率就越慢。

技术债务状况严重的产品变得越来越复杂，因而也更难把事情做对。一旦到达某个时间点，我们就会开始被此起彼伏的缺陷淹没，疲于奔命，根本无法走出困境。

技术债一增加，开发和支持成本也会开始增加。在债务状况越来越差的情况下，即使是小改动，也会涉及很高的成本。

而且技术债上升的成本还会影响我们做出继续开发特性还是修复缺陷时的经济决策。

如果产品确实已经债台高筑，基本上不太可能进行任何形式的预测了。即使一个经验丰富的团队，面对一个负债累累的产品，需要花多少时间才能完成工作，未知数实在太多。

而且随着技术债越积越多，人们开始预计工作表现越变越差，价值链中的所有人都因此而备受挫折。

随着挫败感增强，客户的满意度也会下降。

技术债的起因

技术债有三种主要形式，他们的根源各有不同。

不可避免的技术债，不管采取什么预防措施，都会积累。

低级技术债是团队成员、组织及过程不成熟所造成的。

策略性技术债则是在债务累计收益大大超过债务成本时可能选择承担的债务。

我们希望按预计的速率开展工作及时完成高质量的特性，同时还要尽量避免积累技术债。然而在我们开工后发现，产出高质量结果的实际速率低于预计开发速率。此时此刻，我们需要做出一个业务决策。不幸的是业务人员往往是强令团队必须在理想的发布日期交付所有特性。在这种情况下，负责干活的团队就会被要求提高速率，争取在理想的发布日期之前完成所有特性。这时就会积累下技术债。

一个普遍的迷思是，测试属于额外的开销，只要减少测试，我们就可以提高速率。

现实是减少测试既增加债务又减缓速率。因为问题潜伏得很深，越晚发现，修复成本越高。

技术债必须加以管理

技术债和财务债一样，必须加以管理，没有哪个产品能做到“无债一身轻”，认识到这一点很重要。

技术债的管理要求综合考量技术和业务因素，因此离不开技术人员和业务人员的参与。

让产品负责人作为团队成员，可以做到在讨论中兼顾业务和技术因素，做出经济效益更好的折衷方案。

管理应计技术债

首先我们需要停止向产品增加低级技术债务。使用良好的技术实践是一个非常好的开端。据我所知，所有成功的Scrum团队都会采用简介设计、测试驱动开发、持续集成、自动化测试和重构等技术实践。

对于积累下来的技术债，代码重构是一个非常重要的减轻债务的工具。重构用于改变既有代码主体的一种规范技术，在不改变软件外在行为的前提下调整其内部结构。力图通过重构改善可维护性和扩展性，同时降低复杂性。

有些工作本来应该在构建特性就做，结果却拖到了后期才做，他们是产生技术债的重要根源。完后定义检查表中包含的技术细节越多，积累技术债的可能性就越少。

技术债触及并影响到整体经济核算的许多不同层面。如果不考虑最重要的因素，就无法确保正确量化承担技术债所涉及的经济效益。以我的经验，大多数组织都过于看低承担技术债的实际成本，而且基本上都不像他们想象的那样勤于偿还债务。

让技术债可见

很多组织存在的问题是，开发团队多少还能看出产品技术债处于什么状况，业务人员却是一问三不知。也就是说，让业务人员看见产品的技术债状况是很关键的。

技术人员往往都具备隐性知识，知道最严重的技术债在产品中的哪个地方。然后这种理解可能不可见。

具体方法：

首先，可以把技术债当作缺陷录入缺陷跟踪系统

另一种让技术债可见的方法是为技术债创建PBI

第三个方法是创建一个特殊的技术债列表

偿还技术债

1. 确定已知技术债是否应该偿还，如果应该，则转到第2步
2. 如果是在编码工作时发现的偶发技术债，就立刻偿还，如果数量超过某个合理的阀值，清理到阀值附近即可。
3. 每个冲刺都要考虑指定一定数量的已知技术债作为目标技术债，在当前冲刺中偿还

并非所有技术债都应该偿还

如果产品价值不高，就让产品退市，将资源投到价值更高的产品

原型的价值不在于代码，而是我们得到的经验认知

如果是构建一个短生命期的产品，经济因素可能支持不偿还技术债

偿还策略

在每次改动产品时，我们都要尝试让产品设计和实现更好，而不是更差。发现后不及时偿还的所有偶发技术债，都要归为已知技术债，并通过团队确定的任何可视化方式使其可见。

原则上讲不应该为技术债单独安排冲刺，因为偿还债务应该分期分步骤进行。

在维护技术债时，我们应该始终先锁定高息技术债并加以维护。

更好的做法是，在做PBI的同时，维护已知的技术债。

产品负责人

概述

产品负责人是有授权的产品领导力核心，至少需要同时面对两个方向。

一方面，产品负责人担任的是产品经理的角色，确保能开发出正确的解决方案。

另一方面，对于要构建的特性及其构建顺序，产品负责人必须和开发团队进行交流。产品负责人还必须保证特性的验收标准已有明确的说明，并且已满足后续需要运行测试验证的标准，以确保特性完成。产品负责人不需要写详细的测试用例，但要保证完成验收测试用例的编写。

主要职责

产品负责人要负责确保在版本、冲刺和产品列表层面都能够持续做出良好的经济决策。

产品负责人一直需要在版本级别综合考虑范围、日期、预算和质量。

除了版本级别的经济效益，产品负责人还要管理冲刺级别的经济效益，确保每个冲刺都能带来良好的投资回报(ROI)。

产品负责人要负责排列产品列表的优先顺序。

产品负责人是做产品规划和冲刺规划的重要参与者。

在做版本规划时，产品负责人与利益干系人及团队一起确定下一个版本的内容。

产品负责人负责管理产品列表的梳理活动。包括PBI的建立、细化、估算和排列优先级。产品负责人不会自己执行所有的梳理工作。但在估算期间要负责解答问题，澄清疑问。

产品负责人负责为每一个PBI定义验收标准。并最终负责确认PBI是否满足验收标准。

产品负责人要在执行冲刺的过程中验证，而不是等到冲刺评审时再验证，这一点很重要。

产品负责人必须经常与开发团队保持紧密合作。产品负责人得积极投入，尽心尽力，每天都要参与团队活动。

在使用Scrum时，我们一次构建一个特性，而不是一次按一个阶段构建。

在短期，时间固定的迭代中进行如此紧密的交流互动，产品负责人不太可能与开发团队脱节。而且一个附带的好处是，如果Scrum用得好，大家就不会再相互指责了。

产品负责人是内外利益干系人团体的唯一代言人。产品负责人必须与整个利益干系人团体紧密合作，集思广益，形成一个统一的愿景来指导产品开发工作。

特征/能力

产品负责人要有预见性，能够构思产品的愿景并带领团队实现这个愿景，为了更有效地建立并实现愿景，产品负责人必须具备适当的业务和领域知识。

产品负责人是处于利益干系人团队和Scrum团队之间的关键人物。需要有良好的沟通技巧，能够和双方的成员合作并以简单明了、易于理解的方式进行沟通并且值得信任。

必须放权让产品负责人制定决策。在制定决策时，产品负责人必须在业务需求和技术现实之间保持适当的平衡。

产品负责人有责任确保从经济角度合理利用资源，如果做不到这一点就必须承担责任。

产品负责人、敏捷教练和开发团队是一个整体，有共同的目标。

日常工作内容

在第一周和第二周，产品负责人参与产品规划，产品负责人与合适的利益干系人及其他人一起构思新产品。

在第三周，产品负责人参与制定计划草案。这个活动一般包含一个PBI写作研讨会，在参加完PBI写作研讨会之后，产品负责人要参与估算研讨会。

接下来，产品负责人要协助召开一次计划草案会议，在这个规划会议上，工作重点是排列产品列表的优先级，取得范围、进度、和预算等约束条件的平衡。这个活动的目的是制定足够的版本计划。得到一个足够清晰的整体版本，并对交付什么、何时交付之类的业务问题给出初步解答。这个活动一般在一两天内完成。

在确定版本计划后，Scrum团队就要执行第一个冲刺了。产品负责人要负责制定冲刺计划。在执行冲刺时，产品负责人要尽量参加团队的每日例会。在例会上，产品负责人听取情况，充分了解当前冲刺的进展情况，确定需要想开发团队提供哪些方面的协助。 如果很快就能澄清，就可以立即解答。如果三言两语解释不清楚，产品负责人要明确表示，例会结束后留下来一起讨论。

产品负责人每天必须能够解答问题并在特性等待评审时对其进行测试。

在执行冲刺时，产品负责人还要与内外部利益干系人会面，确保为新一轮冲刺设置正确的优先级，还需要对产品列表进行梳理，包括写新的条目，细化现有条目，与团队一起对条目进行估算，并排列优先级。

在冲刺结束时，产品负责人要参加冲刺结束时进行的两个总结活动，冲刺评审和冲刺回顾。

在完成这些活动后，再次执行冲刺循环过程。

谁来担任产品负责人

产品负责人吸收了产品经理，产品市场人员，项目经理、业务分析师和验收测试人员这五个角色的要素。

究竟谁最适合当产品负责人，取决于开发工作的类型和特定的组织。

敏捷教练

概述

产品负责人主要负责构建正确的产品，开发团队主要负责以正确的方式构建产品，敏捷教练则主要负责帮助每个人理解并乐于接受Scrum的价值观、原则和实践。

主要职责

类似于运动团队的教练，敏捷教练重点观察团队使用Scrum的过程，全力帮助团队表现达到更高级别的工作效能。

敏捷教练是Scrum活动的过程权威，在这个身份上，敏捷教练需要被充分授权，只要有可能，敏捷教练就要持续帮助Scrum团队改进过程。实现交付的业务价值最大化。

敏捷教练的权威不同于职能经理或项目经理。敏捷教练不招人或裁人，也不命令团队做什么任务或怎么做这些任务，敏捷教练也不负责确保工作一定能完成。相反，敏捷教练帮助团队定义并遵守自己的流程。

敏捷教练保护开发团队免受外部干扰，让团队可以集中精力在每个冲刺交付业务价值。

敏捷教练还要承担“清道夫”的职责，扫清妨碍团队生产效率的一切障碍。

敏捷教练必须积极推动变革。优秀的敏捷教练能够帮助大家转变思维。确保组织的各个层面都发生有效的变革。

特征/技能

为了做好一个有效的过程教练，敏捷教练必须精通Scrum方方面面的知识。适当的技术知识和业务领域的知识对于敏捷教练很有帮助。

敏捷教练要运用他们的教练技能，结合流程、技术和业务方面的知识，提出重要的问题。优秀的敏捷教练几乎从来不会直接回答问题。

敏捷教练不倾向于公开答案，所以他们需要很有耐心，留时间让团队自己找到合适的答案。

通过定期向团队提出启发性的问题而一路指导。让团队找到解决方案。

敏捷教练始终要想方设法找机会帮助Scrum团队成员彼此之间高度合作。

日常工作内容

敏捷教练每天要花时间组织并推进Scrum活动，包括冲刺规划、冲刺执行、冲刺评审、冲刺回顾和每日例会。

敏捷教练每天还要花时间指导团队成员，帮助他们提高使用Scrum和技术实践的能力。

在整个冲刺过程中，敏捷教练需要花时间和产品负责人一起执行产品列表梳理活动。关于重要的可变因素，敏捷教练还要和产品负责人一起做出权衡，以确保经济上可行。

扫清障碍在敏捷教练日常工作中是一个很大的可变因素。

履行角色

我见过优秀的敏捷教练来自现有的很多不同角色。一些敏捷教练之前是项目经理或者产品经理，其他敏捷教练来自开发、测试或者其它有技术背景的人。

只要一个人具有之前我提到的六大特征并且愿意接受这个角色，就可以成为一个高效的敏捷教练。

一些组织认为技术主管或开发主管应该是敏捷教练。但是让他们做敏捷教练，可能会对技术方面的产出造成影响。

职能经理或人力经理如果具备敏捷教练的技能，也会很成功，但这样的经理最好不要保留管理职责。因为敏捷教练是没有管理权力的。容易导致团队成员角色混乱。

优秀的敏捷教练需要具备一系列有价值的独特技能。我倾向于让具备这些技能的人在多个团队中发挥作用，而不是让他花时间做一些非敏捷教练的工作。

最不鼓励的角色组合就是同一个人即担任敏捷教练又担任产品负责人。

开发团队

概述

Scrum定义了开发团队这个角色，它是设计、开发、测试等几类人的跨职能集合。

专职团队

只要可能，我们就要建立跨职能团队，把工作分配到多个专职团队是靠不住的，并且可能严重阻碍Scrum取得成功。

主要职责

开发团队的大部分时间都花在冲刺执行上。

每个开发团队都应该参与每日站会。

开发团队每个冲刺最多分配10%的可用生产能力来协助产品负责人梳理产品列表。

每个冲刺开始的时候，开发团队参与冲刺规划会。对于两周的冲刺，规划会通常要花半天时间。

每个冲刺结束的时候，开发团队都要参加两个总结活动：冲刺评审会和冲刺回顾会。

在冲刺评审会上，开发团队、产品负责人、敏捷教练，利益干系人、投资人、客户和其它团队中感兴趣的成员，一起评审当前冲刺刚刚完成的特性，并讨论下一步改进措施。

在冲刺回顾会议上，Scrum团队调整自己的Scrum过程和技术实践。进一步改善团队使用Scrum来交付业务价值的方法。

特征/技能

自组织

团队成员自组织决定实现冲刺目标的最佳方式。

跨职能的多样化和全面化

开发团队成员应该是跨职能多样化的，他们共同拥有必要的、足以完成工作的技能。

技能单一的人组成的团队最多只能完成工作的一部分。所以一个职能团队做完自己的工作后，工作产品就被移交给其他职能团队。 移交代表着极有可能产生误解和高成本的错误。

我们还应该通过在同一个团队中合理搭配资深员工和资历浅的员工实现团队的多样化。资深员工太多可能引起不必要的振荡，就好比厨房里的大厨太多。

T型技能

灵活的开发团队是由T型技能的成员组成的。

T型技能的一个意思是一个团队成员在他喜欢的职责、学科或者特长方面造诣很深。但又可以做超出其核心特长的工作（一专多能）。

团队中不可能每个人都可以做每项任务，这只是一个崇高目标。

经理应该专注于把现有人员组成最好的T型团队。

团队成员拥有合适的技能，覆盖各个专业领域，并且总体上技能有一些重叠。团队有额外的灵活性。为了达到这个目标，许多团队成员应该具有T型技能，不过我们仍然会搭配一些专家。

火枪手态度

团队成员共同承担完成工作的责任，成败是整个团队的事情。

让有技能的人教没有技能的人一起做，使团队以后总体能力更强。

沟通广泛

广泛沟通提高了信息分享的频率和质量。最后，Scrum团队有更多机会进行反思和调整，从而做出更快更好的决定。

敏捷宣言提出面对面沟通是首选方法。只要有可能，我就会让团队成员坐在一起。

打造跨职能团队是迈向高带宽沟通的关键。

如果团队成员在和真正的客户和用户交谈之前，必须经过三层传递，这种“与客户谈话”的流程可能就是高效沟通的一个严重障碍。不得不写低价值或毫无价值的文档或需要冗长的可有可无的审批签字流程，这些都降低了沟通的带宽。

透明沟通

除了广泛沟通，团队内部沟通也要透明。沟通透明能够使所有成员都清楚现状，不会觉得意外，另外还有助于建立互信。

规模适中

Scrum推崇小团队，一般规则是团队最好有5到9名成员，以我过去25年的经验，5到7人的团队对快速交付业务价值最有效。

专注、有责任感

每个团队成员都会致力于完成团队共同的目标。

如果一个人只做一个产品，就更容易做到专注、有责任感。

团队成员如果必须在多个产品之间切换，就很难做到保质保量。

大量数据表明一个普遍的共识：做多个产品或项目，或跨多个团队会降低生产力。

同时做三个以上的项目经济效益最差，因为更多时间被花在协调、回忆和查找信息上，真正花在有价值的工作上的时间却减少了。

工作步调可持续

团队成员必须以可持续的节奏工作。高工作强度期间的象征是超级英雄通宵熬夜和周末加班工作，力争发布新版本。有些人以此为乐，喜欢受人关注，想通过加班获得奖励。然而这种工作强度会把其他人压垮。

团队人员稳定

原则上来讲，团队应该保持稳定。稳定团队是有经济优势的。稳定团队比新组建的团队生产力更高。

我看到很多组织都没有意识到团队也是一种资产。大多数组织都习惯于临时抽调专业人员组成“团队”，依我之见，这样的实践错失了Scrum的关键——价值在于团队。团队才是敏捷的价值源泉。

在不同团队之间借调人员会破坏团队的完整性。

整体调移稳定的团队在经济效益上几乎总是高于移动个人。

当然，如果有一个团队确实不能像我们希望的那样有凝聚力，那么解散团队通常危害更小。

职能经理

概述

虽然Scrum框架中并没有明确提及经理的角色，但是，经理在敏捷组织中依然发挥着重要的作用。

根据2011年行业内的一项敏捷调查，采用Scrum最大的顾虑就是感觉管理失控。

Scrum组织中的职能经理负责塑造团队、培养团队、调整并适应环境，并且管理价值创造的流程。

塑造团队

经理塑造团队，这个过程包括定义边界、提供一个清晰而鼓舞人心的目标，组建团队，改变团队成员组成以及授权。

自组织团队自行决定想做什么产品或项目，这是非常罕见的。经理要定义团队允许自组织的边界。

经理还要给每个团队提供一个清晰而鼓舞人心的目标。这个目标就是团队的目的和方向。

团队一般不是自己组建的，而是由经理来组建。

在Scrum环境中，代表不同专业领域或实践团体的职能经理一起物色跨职能的Scrum团队成员。

经理还负责改变团队的人员组成，前提是他们相信这么做能够提高团队和整个组织的整体健康情况和绩效。

为了让团队能够自组织，必须授权团队，也就是需要经理放权和信任。

经理还要帮助团队成员建立互信。使他们相信每个人都真的承诺齐心协力实现团队目标。

培养团队

Scrum团队一旦形成，经理就应该好好培育。培育并不是说由经理来管理团队。相反，经理应该激励成员，关注他们的能力发展，建立职能领导力，保持团队的完整性。

提供一个清晰而鼓舞人心的目标是激励团队成员的基础。

经理需要培养一种环境是大家能够坚持学习和提升技能。

经理还必须经常给团队和个人提供反馈。个人绩效考核，由于鼓励个体行为而导致人们牺牲团队利益而使自己的指标最优化，因而也会干扰团队的出色表现。但这并不意味着在Scrum组织里不评估个人表现。一种方法是经理每个冲刺都提供反馈。

职能经理通常有丰富的领域工作经验，因此能在这个领域提供思想领导力。这种领导力不包括直接给下属分配任务或者指导具体工作。这么做只会弱化自组织团队的能力。但制定规范，分享最佳实践等可以进一步确保产生高价值、连贯的结果。

敏捷的精髓在于团队。作为生产能力的单位，团队代替了个人，所以经理应该积极保持团队的完整性，即不能在冲刺执行过程中，从团队抽调人员去支援更受关注的项目，不能也不必把一个人分配到多个团队。

为了充分落实Scrum的好处，从供应商到客户整个价值链都需要拥抱敏捷。经理有责任调整和改造环境，可以采取的方式有传播敏捷价值观、移除组织层面的障碍、协调内部多个团队的工作以及与外部合作伙伴协作。

首先，经理必须接受敏捷价值观和原则。他们要理解、真正相信并付诸实践，然后鼓励其他人一起做。

整改环境

如果要成功，团队最终离不开管理层的支持。

为了移除障碍，经理还需要和敏捷教练紧密合作。特别是组织问题，需要经理介入才能真正移除。

管理价值创造流程

总的来说，Scrum环境中的经理负责设定战略方向，同时确保以经济合理的方式配置管理组织资源以实现战略目标。

组织期望经理在组织的更高层面监管经济状况。他们决定应该投资哪些开发工作、投资多少以及投资的先后顺序。而且一旦开发工作开展起来，经理就要对增量迭代开发所产生的持续实时反馈进行回顾与响应。并在适当的时间点终止投入其经济效益已不值得追加预算的项目。

许多指标和报告都是应经理的要求而收集和产生的。对经理来说，正好趁此机会确保只采集和报告与价值创造流程相关的指标，确保指标和报告坚守Scrum核心价值和原则即可。

创新核算使用可行指标作为创造商业价值结果进度测量的关键。

创新核算基于以下三个步骤：

• 创建一个最小可行产品（MVP），对组织或产品目前状况可实施的基准测量指标。
• 一系列产品改进增量，使指标在基准线向着理想或期望的价值进展。
• 如果可实施的测量显示产品正向着期望目标有明显的进展，就坚持走当前的路；否则，转到新的策略并重新开始这个过程。