• 作者：杨蕾，郑江著

• 推荐值：76.7%

• 微信读书：天天学敏捷：Scrum团队转型记

阅读目标：提前明确目标，有助于提升阅读效率

学习目标

1. 学习敏捷和Scrum基础知识

1. 分析在项目实施中经常遇见的问题

1. 问题的处理方式

【实施Scrum对组织和项目的好处】

• 更高的生产力和更低的成本。

• 员工的参与度与工作满意度增强。

• 更快的产品上市时间。

• 更高的质量。

• 项目干系人的满意度提升。

【知识小结】

• 敏捷方式的核心思想在于迅速把产品投放给用户来为公司带来盈利，敏捷的特点是迭代和增量。

• 对于公司来说，敏捷开发的目的就是尽早开发出可以工作的产品给用户来赢得市场带来利润。

• 在产品投放市场以后，通过客户的反馈，公司可以继续改进产品功能。而实现这一目的的过程就是，项目被分成若干个迭代（迭代），每段时间里开发出一部分产品功能（增量），并且按照计划将这些功能（增量）投放到市场成为为公司盈利的产品。

• 与传统管理方法提前做好计划，尽量规避变化的管理方式不同，敏捷拥抱需求和技术的变化，认为需求和技术的不明确和变化是必然的。

敏捷宣言:

• 个体和互动高于流程和工具。敏捷强调‘人’，人最清楚如何完成任务，要尊重人的意见和想法

• 工作的软件高于详尽的文档。这里强调的是要把重点放在工作的软件上，让文档服务于软件，而不能把工作的焦点放在文档上

• 客户合作高于合同谈判。和合作方创建良好的合作关系共同解决问题要比逐条谈判合同的细节更重要

• 响应变化高于遵循计划。我们认为变化是一件好事，项目是流动的，因此项目有变化是正常的，必须随时调整

【知识小结】

• 按照敏捷之伞的划分，可以将敏捷的各种方法分为两个部分。一部分是轻量级的方法（可以简单地理解为服务于单个团队的方法），另一部分是服务于多个敏捷团队的方法。

• 在轻量级方法中，又可以从方法解决的问题这个角度将它们分为两类，其中，Scrum、Kanban都是生产产品的框架，用于产品开发或工作管理。而XP（极限编程）、FDD（特征驱动开发）则是工程实践类的方法。

• 敏捷之伞的另外一部分是服务于多个团队的方法，根据不同的项目规模和团队之间工作的耦合度，有多个方法来协调多个敏捷团队的协同工作（如SAFe、Scrum-of-Scrums、LeSS等）。

【知识小结】

• Scrum：作为最受欢迎，使用最为广泛的敏捷方法，Scrum是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可集合各种开发实践的经验化过程框架。Scrum项目中发布产品的重要性高于一切。接下来的章节中将仔细介绍Scrum。

• Kanban：Kanban是一种源于丰田精益化管理的方法，它是仅次于Scrum的另外一种敏捷软件开发的框架方法。它有以下特点：流程可视化，限制WIP（Work In Progress，在制品数量），度量生产迭代（没有固定时长的迭代）。相对于Scrum更适于开发新产品，Kanban则更加适合于运营维护团队实施敏捷时使用。

• XP：XP（极限编程）的思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无须开发人员在软件开始初期写出很多的文档。XP提倡测试先行，为了将以后出现bug的概率降到最低。在XP的12个团队实践中，TDD测试驱动开发（Test-Driven Development）是其中之一。它的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码，即通过测试来推动整个开发的进行。

• FDD：FDD（Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

• Scrum-of-Scrums：SoS（Scrum of Scrums）是一种管理大型Scrum团队的技术（团队多于12人，被划分为5～10人一组的Scrum小组）。每一个小组都选出一名代表成员去参加所在团队的每日会议（也叫作Scrum of Scrums会议）。根据不同团队的需求，这些代表可以是工程师或ScrumMaster。通过Scrum of Scrums会议达到小组之间的信息同步，解决问题的目的。

• SAFe：SAFe（The Scaled Agile Framework）是一个企业级的敏捷管理框架，适用于管理大型的Scrum团队。SAFe框架提供了三层管理模型，分别由项目组合、项目集、实施团队构成。

【知识小结】

• 创建一个任务列表。项目组需要和产品负责人一起讨论，并且由产品负责人创建一个关于‘Scrum电子任务板’应包括的功能列表。在这里我们使用用户故事技术来描述这些功能，我们称每一个要完成的功能为一个故事。

• 给任务标记工作量大小。使用敏捷的估算技术，给这些故事标记彼此之间相对的任务量大小并且估算完成这些故事需要的时间。

• 给故事设置优先级。和其他工作列表一样，我们似乎总是有很多的工作要做，而时间却总是不够用。因此，项目组需要和产品负责人确认每一个故事的优先级，以便保证一直处理高优先级的任务。

• 开始执行。然后，团队就开始工作了，他们从优先级最高的任务开始，逐个向下，一个接着一个做。他们计划，开发，然后从客户那里收集反馈。

• 根据项目实际情况更改计划。在项目进行中，团队先后碰到了以下两种情况。（1）项目进行得比预期中要快。（2）有太多事情要做，时间不够用。此时，团队可以有以下两个选择。（1）少做一些，缩减一部分功能范围（推荐的做法）。（2）加紧做，加班也要做完。

瀑布模型是一个迭代模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的迭代是环环相扣的。每个迭代中交互点都是一个里程碑，上一个迭代的结束需要输出本次活动的工作结果，本次活动的工作结果将会作为下一个迭代的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。

传统的瀑布模型项目面临着质量、可见性不高而风险太多，无法应对变化的问题。与之相比，敏捷的方法持续地迭代，更加灵活且拥抱变化。

• 质量不高。当发现项目已经没有钱和时间的时候，测试已经成为唯一剩下的还没做的事儿。这就意味着项目必须剪掉测试的时间和预算，因此，产品质量就必定出问题。

• 可见性不高。因为直到项目最后才能看到产品，在瀑布模型的项目里，你永远不知道你真正在哪儿。项目的最后20%经常会花费80%的时间。

• 太多风险。在项目一开始你就有风险：首先，你有时间安排上的风险，因为你永远不知道项目会在什么时候完成；接下来，你有技术上的风险，因为你只有在项目最后的测试阶段才会知道你的设计和构架问题；最后你还有产品上的风险，因为你根本不知道你是否开发出了一个正确的产品，直到项目后期无论做任何变更都已经太晚了。

• 无法应对变化。最重要的一点，瀑布模型无法应对变化。瀑布模型是一个迭代模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的迭代是环环相扣的。每个迭代中交互点都是一个里程碑，上一个迭代结束时输出的工作结果是下一个迭代活动的输入，本次活动的工作结果将会作为下一个迭代的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。

敏捷有以下特点：

• 需求分析，设计，编码和测试的工作是持续进行的。

• 产品开发过程是迭代的。

• 计划更加灵活，可以调整。

• 项目成员为了同一个目标努力，做出力所能及的奉献；而不强调‘角色’的分工和明确的职责划分。

• 拥抱变化，及时调整。

• 交付可工作的软件是最重要的衡量项目是否成功的标志。

• 《Scrum指南》中对于Scrum给出了这样的定义：Scrum是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。

• Scrum作为一个框架，它的最大特点就是迭代和增量。项目以一个迭代接着一个迭代的方式运转，每个迭代的产出就是产品增量。在迭代当中，项目组每天都进行检查和调整。每个迭代的工作内容就是实现产品列表上的功能。

• Scrum的工作方式：在每个迭代开始的时候，Scrum团队找出他们要做的产品列表条目。然后开始在这些条目上工作。并且在迭代结束的时候完成这些条目成为潜在可发布的产品增量。

• 在日常开发中，我们经常定义迭代名为Sprint 1、Sprint 2、…、Sprint N，这里Sprint的英文原意是冲刺的意思，所以对应的Sprint 1、Sprint 2中文称呼就是冲刺1、冲刺2。

Sprint是受时间盒限制的，无论工作完成与否都会在特定日期结束，并且不延长。

• Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。每个迭代不超过4周（通常2周），并且无间歇地相继进行。

• 在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。

• Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。

SCRUM框架包括3个角色、3个工件、5个活动、5个价值

3个角色

• 产品负责人（Product Owner）

• Scrum Master

• Scrum团队

3个工件

• 产品Backlog（Product Backlog）

• SprintBacklog

• 燃尽图（Burn-down Chart)

5个活动

• Sprint计划会议（Sprint Planning Meeting）

• 每日站会（Daily Scrum Meeting）

• Sprint评审会议（Sprint Review Meeting）

• Sprint回顾会议（Sprint Retrospective Meeting）

• 产品Backlog梳理会议（ Product Backlog Refinement）

5个价值

• 承诺 – 愿意对目标做出承诺

• 专注– 把你的心思和能力都用到你承诺的工作上去

• 开放– Scrum 把项目中的一切开放给每个人看

• 尊重– 每个人都有他独特的背景和经验

• 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

Scrum并不是构建产品的一种过程或一项技术，而是一个框架，在此框架中可以使用各种不同的过程和技术。

Scrum框架由Scrum团队以及与之相关的角色、事件、工件和规则组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。Scrum的规则把事件、角色和工件组织在一起，管理它们之间的关系和交互。

Product Owner （PO）PO是了解客户需求以及相关商业价值的团队角色，作为客户代表，定义产品功能，决定产品发布的内容和日期，对产品的投入产出负责。根据市场变化对需要开发的功能排列优先顺序，合理调整产品功能和迭代顺序。

Scrum Master (SM)SM 将帮助团队消除任何阻碍团队生产力的障碍，SM的角色是培训和激励团队成员。他起到教练的作用。

Development Team （Dev.Team）开发团队由关键开发者或架构师等5-9人组成，他们各有职责但又是多面手，能独当一面又能互相支持。他们在敏捷开发在不断的组织和管理属于自己的工作，由此产生的协作力将优化团队的整体效率和能力。

我们公司本来就没有ScrumMaster这么个角色，难不成我们要招聘一个？

• 在组织转型过程中，大部分组织都不会选择从外部招聘新的ScrumMaster，而是会考虑把组织中传统项目中的工作人员转型成ScrumMaster。理论上，以前项目里无论是项目经理、产品经理还是工程师，都可以作为备选人成为新的Scrum团队的ScrumMaster。但是，在实践层面上，一般都是项目经理转做ScrumMaster的实践居多。

ScrumMaster的职业发展路线通常会有如下4个方向：

• （1）服务于多个团队或者更具挑战性的团队。作为ScrumMaster，最开始一般都是从服务于一个团队开始的。在经过一段时间的磨合以后，团队的成熟度越来越高，越来越稳定。ScrumMaster就可以去寻找更多的挑战了。通常来说，ScrumMaster可以去为多个团队服务或者是去为充满挑战的团队服务。以此，来提升自己的技能。

• （2）成为Agile Coach。有些ScrumMaster在经过一段时间的工作以后，他们发现自己热衷于激发团队进行创造的过程，而并无所谓产品本身。在经历了一段时间的经验积累以后，他们非常希望可以把这些经验分享给其他新手ScrumMaster，对于这种人来说，转型成为Agile Coach就是一个非常不错的选择。

• （3）成为产品负责人。还有一些人，也许做了一段时间ScrumMaster以后，发现自己对构建产品的过程很感兴趣，那么成为一个产品负责人就是他们的最佳选择。当然，我并不是说产品负责人在组织中高于ScrumMaster这个角色。在理论上，这两个角色是平级的关系。

• （4）成为管理者。对于像你这种从传统的项目经理转型成为ScrumMaster的人来说，也许做了一段时间的ScrumMaster以后，你仍旧更加希望转回到传统的管理者角色上来。如果这时候，组织里有机会，那么也是可以成为管理者的。

ScrumMaster是一位服务型领导，通过服务于团队之外的人以及团队中的各个角色来促进和支持Scrum，其中包括但不限于推动阻碍团队工作的事情，引导Scrum流程，协调团队内外的沟通，隔离团队的外部干扰等。

ScrumMaster的主要职责：

• （1）教练——指导Scrum团队。

• （2）Scrum专家——Scrum团队的过程专家，引导Scrum的流程。

• （3）推土机——推动一切阻碍开发团队工作的问题。

• （4）保护伞——保护开发团队免受外部的干扰。

• （5）服务型领导。项目经理会问：“那么，今天你要准备为我做什么？”相反，服务型领导的ScrumMaster会问：“那么，为了帮助你和团队更加有效，今天我能做什么？”

作为确保团队做出正确产品以便帮公司得到最高投资回报的产品负责人，在Scrum团队中负责“做什么”的问题。产品负责人的工作包括：愿景和边界。产品负责人的工作包括两个方向：提出正确的解决方案和确保解决方案被正确“制造”。

在传统软件开发方法里，定义了不同的工作类型：软件主任工程师、程序员、测试工程师、UI工程师、数据库管理员。但是，在Scrum里面定义了“开发团队”的角色，这个角色是所有这些工作类型的集合。在Scrum里面，所有这些人统称为开发团队，所有的人都被称为“工程师”。

Scrum开发团队的主要职责如下。

• 在冲刺执行期间，开发团队完成创造性的工作，包括设计，构建，集成，测试，最终提供潜在可发布的功能发布。

• 每日检视和调整（每日站会）——作为一个自组织的团队，团队通过每日站会来实现自我的检视和调整以实现冲刺目标。

• 梳理产品列表——帮助产品负责人梳理产品列表，细化产品列表条目，估算和排列优先级。

• 冲刺规划——在每个冲刺之初，开发团队参与冲刺计划会议。在会议上，根据产品经理提供的信息，对产品列表条目的工作量进行估算，并在ScrumMaster的指导下，与产品负责人共同制订冲刺目标。注意，开发团队对工作量的估算有绝对话语权，作为一个自组织的团队，他们不受其他角色的影响，对工作量进行估算并且按照自己的承诺去履行冲刺目标。

• 检视和调整产品与过程——在每个冲刺结束的时候，开发团队都需要参加冲刺评审会议和冲刺回顾会议。在会议上，Scrum团队检视和调整自己的过程和技术以进一步改善团队使用Scrum来交付业务价值的能力。

Scrum开发团队的特征如下。

• 自组织——没有项目经理或者其他经理告诉团队怎样开展工作；团队在没有外部力量干预的情况下，为了共同的冲刺目标而工作，逐渐达成默契，相互理解，不断改进。

• 跨职能——为了提交潜在可交付的增量，团队需要具备所有相应知识和技能的成员。

• 规模适中——5～9人的规模。

Sprint列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作。

Sprint列表在Sprint规划会议中产生，一旦Sprint规划会议结束，产品负责人就不能再修改Sprint列表的故事清单了。这是Scrum中业务方和开发团队之间的基本协议，每次Sprint开始前，业务方都可以改变方向，然而Sprint开始以后，团队则会专注于他们所承诺完成的故事。

改变这个已承诺的故事清单只有一个方式，就是由干这个活儿的团队成员提出变更请求。也许团队发现他们能比最初设想的做更多的活，也或许他们无法交付所有已经承诺的故事。遇到这种情况，产品负责人将和团队一起修改Sprint列表中的故事清单。

产品列表是固定不变的，与之相比，Sprint列表则是Sprint过程中一直都在变化的。

团队一旦发现想要交付已经承诺的故事还有些新的任务需要完成，就会把它们也添加进Sprint列表。有时候团队也会发现某个现有任务已经毫无意义，那他们就会从Sprint列表中把它剔除掉。

知识小结：

• （1）Sprint列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。

• （2）Sprint列表是开发团队对于下一个产品增量所需的功能以及交付这些功能到“完成”的增量中所需的工作的预测。

• （3）为了确保持续改进，Sprint列表是少包含一项在前次回顾会议中确定下来的高优先级的过程改进。

• （4）Sprint列表是拥有足够细节的计划，任何进度上的变化可以在每日展会中清晰地看到。开发团队在Sprint期间修改Sprint列表，使得列表在Sprint期间涌现（根据不断涌入的、具有经济价值的信息持续更新）。

• （5）在Sprint期间只有开发团队可以改变Sprint列表。

• （6）Sprint列表是高度可见的，是对开发团队计划在当前Sprint内工作完成情况的实时反映，由开发团队全权负责。

从概念上来说，完成的定义是在宣布工作潜在可发布之前要求团队成功完成的各项工作检查。

在大多数情况下，完成的定义至少要产生一个产品功能的完整切片，即经过设计，构建，集成，测试并编写了文档，能够交付已验证的客户价值。但是为了得到一个有用的列表，这些大级别的工作项需要进一步的细化。例如，做过测试意味着什么？写过文档意味着什么？

完成的定义具有如下的特点。

• 完成的定义可以随时间演变。

• 完成的定义和接收标准不同（当某个“接收标准”里的需求适合于所有的用户故事，那么它就是完成标准里的一项；但如果该需求只是适用于所有用户故事的一个子集，那么它就是这个用户故事子集里的故事的验收标准）。

• 完成的定义可以是多个不同层面的（任务层面，用户故事层面，交付层面）。

• 完成的定义里会包含一些限制因素（可移植性，可伸缩性，可维护性，安全性，可扩展性，互操作性）。

在Scrum冲刺中，我们应该计算Sprint待办列表中所有剩余工作的总和。开发团队至少要在每日站会时跟踪剩余工作的总和，预测达成Sprint目标的可能性。通过在Sprint中不断跟踪剩余工作量，开发团队可以管理自己的进度。因此，跟踪Sprint当中有意义的指标是必须的。

Sprint燃尽图：

• Sprint燃尽图用于显示当前冲刺剩余工作量的变化。增加或者完成任务以后，团队成员会更新图表，以体现剩余的工作量（工作量可以用任务小时，任务点或者任务数量来表示）。

• Sprint燃尽图的目的在于，通过它团队能够看清楚情况并且知道自己能否交付迭代中已经承诺的全部。如果团队发现有些故事已经无法完成，也能立刻让产品负责人知道。这样产品负责人就可以和团队协商如何应对状况。产品负责人可能会选择放弃Sprint中某个故事，也可能会选择缩小一个或者几个故事的范围，直到团队能完成剩下的部分为止。如果团队发觉他们将提早完成所有的故事，那就可以找产品负责人再要一个故事继续开发。

关于Sprint燃尽图有一个让人吃惊的现象，Sprint第一部分的趋势线往往会走高而不是走低。为什么会这样呢？

• 团队工作刚刚开始的时候，他们会发现还需要完成一些新的任务，这是正常现象。发现这些任务之后，就要估计它们的大小，还要加入到Sprint列表当中。由此带来的增长会体现在Sprint燃尽图上。大多数团队发现Sprint到1/3的时候，燃尽图又会掉头回来继续向下。Sprint进行当中发现更多工作成了一种模式，一些团队刚开始会被吓到，但很快就开始意识到这就是正常Sprint燃尽图的模样，刚开始向上翘，随后开始真正转为下降趋势。”

交付燃尽图便于产品负责人跟踪发布剩余工作随时间变化的过程。通常情况下，我们会使用Sprint作时间轴增量，剩余故事点数作纵轴。不同的下降趋势反映了单位时间段内所完成点数的自然变化

一个冲刺目标相当于一个短期的迭代计划，时间跨度大概在两三周左右。将一个产品分成好多冲刺目标的意义在于，每个短期的迭代目标都是明确的，而且每次要看的任务少了很多啊（这才是重点）。

然而，很多时候，只有跨度是两三周的短期目标还是不够的，一些大型的软件开发项目还需要个中期目标，时间跨度大概在两三个月甚至更长，而且需要中期目标达成后，产品是稳定可交付的。这个时候，就需要“版本”这个概念。

交付燃尽图，就是跟版本相关的。如果说，会用Sprint 燃尽图以后就能掌握当前冲刺目标的完成趋势的话，那么，交付燃尽图就是用来看某一未发布版本的完成趋势——估计需要多少个冲刺目标能将版本交付。

交付燃尽图：

• 浅灰色的柱状代表这个目标完成了的任务点数，所以前面加了个减号。

• 中等灰色的柱状代表在这个目标开启之前就存在的任务点数，在这个目标结束时还剩下多少。

• 深灰色的柱状代表在这个目标开启后到下个目标开启前这段时间，版本中增加了多少任务点数，所以用加号，在当前没有开启的目标甚至没有目标的情况下，增加的点数就都算在上一个目标头上。

• 两条预测线交点对应的横坐标代表这个版本预计会在哪个冲刺目标内完成。

燃尽图描述了剩余工作随时间变化的轨迹。纵坐标绘制剩余工作量，横坐标是时间。通常来说，团队不断地完成任务，剩余工作量也应该随之下降。这会呈现为一条从左到右向下延伸的斜线。

3.5.1 谁负责产品列表，谁负责Sprint待办列表

产品列表由产品负责人负责管理并对它拥有绝对的权利。但是，这并不代表只有产品负责人才可以向产品列表中添加和修改内容。例如，问题、技术相关的工作就经常需要团队来创建相应的条目。对于用户故事来说，也经常需要团队成员去维护相应条目。因此，我们说产品负责人管理产品列表，但维护产品列表的责任团队成员人人有之。至于每个团队的成员如何帮助产品负责人维护产品列表，要看产品负责人给团队成员的授权而定。

关于Sprint待办列表，它是在每个冲刺的计划会议当中产生的。在进入Sprint阶段以后，团队成员负责维护和更新Sprint待办列表。因此，Sprint待办列表是属于团队的。

3.5.2 产品列表的优先级如何制定

产品列表的优先级是产品负责人根据公司更高层面的策略制定的。通常情况下，对于Scrum小组来说，他们的产品列表优先级要服从于整个产品，甚至是产品集的优先级（产品组合规划→产品规划→版本规划→冲刺规划）。

3.5.3 什么是DOR

DoD就是完成的定义。

关于DoR，是指Definition of Ready，即准备就绪的定义。根据《Scrum指南》中的定义：“排序越高的产品待办列表项通常比排序低的更清晰，同时包含更多细节。根据更清晰的内容和更详尽的细节信息就能做出更为准确的估算；同样，排序越低，则细节信息越少。产品待办列表项中那些即将会占用开发团队下一个Sprint大部分时间的项会被加以精化，因此，任一产品待办列表项都能够在Sprint的时间盒期限内适当地‘完成’。这些能够被开发团队在一个Sprint中‘完成’的产品待办列表项称为‘准备就绪’，它们将作为Sprint计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。”

因此，DoR就是一个类似于DoD的列表，如果满足，列表中规定的产品待办列表项可以放入到Sprint待选产品列表里。如果不满足DoR的定义，则不可以放入Sprint待选产品列表当中。

3.5.4 敏捷了就不需要文档了吗

不是！敏捷要做的是减少浪费，以便能按照项目的特点灵活选择文档的数量与形式，在过度设计和返工之间寻找到平衡。也就是说，每个项目都要根据自己的特点，选择合适的形式和内容来写文档。例如在大多数项目中，设计文档、接口文档是一定要写的，但是有些需求文档也许就不用刻意写了，Jira或者其他用来整理用户故事的工具里的信息就已经足够了。因此，请不要因为是敏捷项目就拒绝写有用的文档。敏捷宣言中的那句话叫作“可工作的软件重于面面俱到的文档”，这绝不能成为不写文档的挡箭牌。

3.5.5 Scrum管理产品列表、冲刺待办列表，需要使用什么工具

需要一个任务板，不同颜色的便签纸，白板笔。如果不是远程团队，那么就请在办公室团队的位置准备一个实体白板来作为任务板（在每日站会的部分，我们会具体讨论如何组织任务板的细节）。

需要管理产品列表和冲刺待办列表的工具。简单到一个Excel表格，复杂到Jira系统，只要可以帮助管理好你的待办事项就没问题。

3.5.6 什么时候梳理产品列表，谁梳理产品列表，怎么梳理产品列表

• 产品列表的梳理是包括产品负责人、ScrumMaster、研发团队在内的整个团队的责任。梳理产品列表的形式可以是多样的，根据团队的成熟度和产品的特点不同，每个团队都可以选择自己喜欢的梳理方式。

• 例如，对于不成熟的团队，如果团队成员还没有形成定时梳理产品列表的习惯，那么由ScrumMaster定期组织梳理会议的方式就比较合适。

• 如果团队很成熟，成员可以自发地定时梳理产品列表，那么就不用组织专门的会议。

• 如果团队跨国家、跨地区，例如产品负责人在美国，研发团队在北京，那么邮件沟通和电话会议的形式就更加合适了。

• 团队可以选择梳理产品列表的时间，只要这个时间是在计划会议之前并且团队有充足的时间进行梳理和调整就可以。

3.5.7 需要开产品列表梳理会议吗

产品列表梳理会议不是Scrum的标准活动，也就是说这个会议不是必需的。但是大部分的Scrum团队都会选择使用产品列表梳理会议。当然，对于非常成熟的团队，他们可能会因为对产品的了解以及团队成员之间频繁的沟通而不必非要组织专门的梳理会议。另外一种情况是转型初期的团队，他们可能会期许产品负责人提供完备的文档，团队成员之间还没有形成良好的互动，如果ScrumMaster不够强势的话，产品梳理会议也会被忽略。对于上述两种情况，第一种非常健康，梳理会议不是必需的；第二种就不健康了，建议团队考虑梳理会议。

3.5.8 Scrum团队跟踪个人完成的任务吗

很多经理都会问：在Scrum团队中，我如何跟踪每个工程师的个人绩效？要知道这和每个人的KPI考核息息相关啊！我的答案是：对不起，Scrum团队强调团队作战。跟踪个人的KPI指标有点儿违背这个原则。

不信你看，Scrum的各种监测图表都是以团队为单位的。没见过有哪个监测工具是统计团队中单个人的工作绩效的。

当然了，如果你说我们公司就要统计个人的KPI，那Scrum是阻止不了你的。但是你得手工统计或者自定义开发一些小工具了，因为像Jira、VSTS这些主流的产品都是不提供这些功能的。

3.5.9 监测的结果可以用来比较不同的Scrum团队之间的绩效差距吗

有的能，有的不能。每个团队负责的功能和对故事点的理解以及团队成员数量都有可能不同，因此不能直接将团队的工作量进行比较（即使是按照团队成员数量比例进行计算后的比较也是不公平的）。

但是，对于一个团队能否每个迭代都完成承诺，一个团队处理单个任务的时间这样的指标是可以进行比较的。监测的结果重在协助团队进行自我管理。

产品待办事项列表存在（并演化）于产品的整个生命周期，它是产品的路线图。

当一个团体计划向Scrum过渡时，在首个Sprint可以开始之前，他们需要有一个（按1、2、3顺序）排好优先级的、以客户为中心的特性列表，即产品待办事项列表。

在传统的瀑布项目里，项目经理会根据收集到的工作信息，绘制计划（例如甘特图、各种任务分配表格）来计划所有工作。团队工作人员根据项目经理的计划工作。当工作无法按时完成或者提前完成时，他们会通知项目经理这个变化。但是在Scrum里，我们不再使用甘特图来计划工作，也没有项目经理来制订计划，所有的计划工作都是通过一个由包括产品负责人、ScrumMaster和研发团队参与的计划会议完成的。

计划会议是一个为Sprint做准备的会议，通常分成两部分，第一部分关于“做什么”，第二部分关 于“怎么做”：

• 第一步，我们要决定接下来的Sprint要做什么；在Sprint计划会议第一部分中，产品负责人和团队审视产品待办事项列表中产品负责人有兴趣在这个Sprint中实现的那些高优先级的事项。通常，这些事项应当已经在前一个Sprint中（的产品待办事项列表梳理会议里）被很好地分析过了，因此在这个会上只有较少的需要在最后时刻澄清的问题。

• 第二步，我们要决定怎么做。根据对用户故事的理解，估算出完成任务需要的工作量，并且创建出具体工作的任务。Sprint计划会议第二部分关注于如何实现团队决定要开始做的那些事项。团队预期他们在Sprint结尾能够完成多少事项，从产品待办事项列表的顶部开始（换句话说，就是从对于产品负责人来讲最高优先级的事项开始），并依次查看事项。以下是Scrum中的关键实践：由团队决定将完成多少工作，而不是由产品负责人分配给他们。因为团队是基于他们自己的分析和计划，这使得预期更可靠。

工作量估计表格：

• 冲刺时长是两周，正常情况下是10个工作日

• 工作大致分为三类：研发工作、测试工作（包括自动化测试工作）和UI设计工作

Dave的总工作量是8天，但是他只有6.4天的研发工作量，大家会不会问其他的1.6天哪里去了？

• 有一列信息叫作‘其他时间’，在这里填写的数字是20%。而且在团队成员工作量估算表格里面，每一个成员的总工作量都与另外三列的‘研发’‘测试’‘UI’不相等。

• Scrum有一些固定的会议需要团队成员参加，例如现在我们正在召开的计划会议，这些会议会占用我们一部分时间。而且，处于组织中，我们还会有其他的一些会议、工作必须完成，这些工作也会占用我们一部分时间。

• 为这些工作预留时间是很多Scrum团队的做法。因此，我们为大家预留了20%的时间来完成这些可以统一被称为‘其他’的工作。这个20%是可变的，随着项目的进行，我们可以根据实际情况增减这个预留的时间。

在计划会议结束以后，团队成员立即开始按照计划会议上的讨论将用户故事分解成各个小的任务，在系统和物理任务板上按照既定的工作流程创建相应任务，并且标记完成任务所需的时间。

知识小结

Sprint中要做的工作在Sprint计划会议中来做计划。Sprint计划会议是由时间盒限定的。ScrumMaster要确保会议顺利进行，并且每个参会者都了解会议的目的。Sprint会议回答以下两个问题。

（1）这个冲刺能做什么？

开发团队预测在这次Sprint中要开发的功能。产品负责人讲解Sprint的目标以及达成该目标所需完成的产品待办列表。整个Scrum团队协同工作来理解Sprint的工作。

Sprint会议的输入是产品待办列表，最新的产品增量，开发团队在这个Sprint中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来Sprint可以完成什么工作。

（2）如何完成所选的工作？

在设定了Sprint目标并选出这个Sprint要完成的产品待办列表项之后，开发团队将决定如何在Sprint中把这些功能构建“完成”产品增量。这个Sprint中所选出的产品待办列表项加上如何交付它们的计划就是Sprint待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转化成可工作的产品增量所需要的工作。工作有不同的大小，或者不同的预估工作量。然而，在Sprint计划会议中，开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的Sprint中能够完成。在Sprint计划会议的最后，开发团队规划出在Sprint最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取Sprint待办列表中的工作，领取工作在Sprint计划会议和Sprint期间按照需要进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并做出权衡。如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在Sprint计划会议结束时，开发团队应该能够向产品负责人和ScrumMaster解释他们将如何以自组织团队的形式完成Sprint目标并开发出预期的产品增量。

经常听到一些伙伴抱怨计划会议时间太长，太烧脑。按照《Scrum指南》的说法，一个两周的迭代可以有最多不超过4小时的计划会议时间。4小时的确不是很短的一段时间。如果你的团队无法集中4小时的精力，那么把计划会议在物理时间上分割成两部分会是一个不错的选择，计划会议1和计划会议2（分别来完成计划会议的两部分）。

随着团队成熟度的上升，计划会议所需要的时间会下降。这有赖于团队对于产品功能的理解和熟悉，同时也依赖于产品负责人和团队成员之间充分的沟通和彼此的信任。

每日Scrum站会是开发团队的一个时间盒限定为15分钟的事件。在每日站会中，开发团队为接下来的24小时的工作制订计划。通过检视上次每日站会以来的工作和预测即将到来的工作来优化团队的协作和效能。每日站会在同一时间同一地点举行，以便降低复杂性。

开发团队借由每日站会来检视完成目标的进度，并监视完成Sprint待办列表的工作进度趋势。每日站会优化了开发团队达成目标的可能性。

以下是一个可以使用的会议议程范例。

• （1）昨天，我为帮助开发团队达成Sprint目标做了什么？

• （2）今天，我为帮助开发团队达成Sprint目标准备了什么？

• （3）是否有任何障碍在阻碍我或开发团队达成Sprint目标？

每日站会是开发团队的内部会议。如果有开发团队之外的人出席会议，ScrumMaster必须确保他们不会干扰会议进行。

每日站会规则：

（1）每次站会一开始，我们会先标记迟到的人。

（2）任何人迟到，如果没有事先请假，没有正当的理由，就要把钱放到我们任务板边上的存钱罐里。团队也可以发挥想象力来考虑用什么方式惩罚规矩的破坏者。例如，让规矩破坏者做俯卧撑。

（3）请大家在开会时围绕着任务板站好。

（4）在站会正式开始之前，开一些轻松的玩笑，让大家感到会议的氛围是轻松正面的。

评审会议是为了收集项目干系人的各种反馈，达到检视和调整的目的。

在冲刺规划期间，我们要制订工作计划。在冲刺执行期间，我们在实际地执行工作。在冲刺评审期间，我们检视并且调整工作成果。冲刺评审发生在每个冲刺迭代快要结束的时候，在冲刺执行之后，冲刺回顾之前。

产品负责人将作为团队代表向所有项目干系人介绍团队在过去一个冲刺中的成果。团队的所有成员都被邀请参与到评审会议中和项目干系人沟通。

到底我们是要向产品经理和干系人展示呢，还是开发团队展示成果给产品负责人呢？

• 答案是，向产品经理和项目干系人的展示都是必需的。在每个用户故事完成的时候，产品负责人都会在集成环境上做验收测试，只有产品负责人通过验收测试才可以关闭用户故事。因此，我们就不需要在冲刺结束时在评审会议上通过演示的方式来获得产品负责人对于团队工作的认可。

Scrum里的其他会议都是团队内部会议，不邀请他人参与。但评审会议对项目外的人开放，包括Scrum团队、内部干系人、外部干系人的所有项目相关人员都可以与会。

冲刺评审常常会被误认为是‘冲刺演示’或干脆被当作‘演示’。虽然演示在冲刺评审中很有帮助，但演示并不是冲刺评审会议的目的。

• 评审会议的目的是参与者深入交谈，合作讨论出建设性的建议和意见。而演示实际上只是展示工作的一种途径。虽然我们刚才用演示的方式和对象来区分评审会议的各种表现形式，评审会议的目的并不是只是做演示。

• 除了上述目标外，评审会议的另外一个目的是要和与会的项目干系人一起对下一个Sprint要做的产品列表达成共识。这里的共识并不是之前计划会议上所做的计划，而是对下个Sprint做什么事情的一个大致的、方向性的确定。

Sprint评审会议用以检视所交付的产品增量并按需调整产品待办列表。在Sprint评审会议中，Scrum团队和项目干系人协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。

Sprint评审会议包含以下内容。

• 参会者包括Scrum团队和产品负责人邀请的主要利益攸关者。

• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”。

• 开发团队讨论在Sprint期间哪些工作做得很好，遭遇到什么问题以及问题是如何解决的。

• 开发团队演示“完成”的工作并解答关于所交付增量的问题。

• 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）。

• 参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下来的Sprint计划会议提供有价值的输入信息。

• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变。

• 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性的调整。

回顾会议是针对流程和环境进行审视并调整。

Sprint之间没有间歇期，团队通常在某个下午开Sprint回顾会议，第二天早上就直接进入下一个Sprint计划会议（不包括周末休息）。敏捷开发的一个原则是“可持续的步伐”，团队只有保持合理水平的常规工作时间才可以一直继续这一周期。生产力随着团队实践的演变和铲除影响团队生产力的障碍而增长，而不是通过加班加点或降低质量来取得。

回顾会议是Scrum检视与调整的一个重要环节。团队对自己的开发过程进行改进，并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。

一、Say Hello

这个环节和别的会议有点儿区别，在别的会议里一般都是会议主持者和大家问一下好，顶多再说个活跃气氛的段子。在回顾会议上，Say Hello环节需要所有的团队成员参与其中。在这个环节中，大家需要用一个词来说一下自己对这个冲刺的感受。如果实在说不出来，你也要说‘我没有’感受。

二、介绍回顾会议需要讨论的问题

回顾会议的目的是检视和调整Scrum团队的流程。为此，会议组织者会组织大家使用各种技术来进行讨论，以挖掘出团队的问题以及讨论解决方案。

在的回顾会议中，经常遇到以下几个问题：

• 问题1：回顾会议被当成吐槽大会。大家在会议上吐槽自己的各种不爽，宣泄情绪，但是吐槽完毕后没有任何解决问题的方法提出，会后也不会有人跟进解决问题。请注意，回顾会议绝不仅仅是一个让大家畅所欲言抱怨抱怨就了事的会议，畅所欲言结束后一定要讨论解决方案并且跟踪执行。

• 问题2：回顾会议被当成鸡肋。很多Scrum团队会为了完成回顾会议而完成回顾会议，而无法从回顾会议当中收获到有用的交流和改进。

三、团队发现问题

思考一下在这个Sprint当中发现的一些问题或者一些想法，然后把这些内容按照开始做、停止做和继续做这三个维度进行分类

（1）会议目的——检视和调整Scrum团队的流程。

（2）会议时间——每个ScrumCycle的最后一个会议（推荐开会时间是每个Sprint最后一天的下午）。

（3）时间盒：≤2小时（两周的Sprint）。

（4）会议讨论的问题：

• 检视前一个Sprint中关于人、关系、过程和工具的情况如何。

• 找出并加以排序做得好的和潜在需要改进的主要方面。

• 同时，制订改进Scrum团队工作方式的计划。

4.5.1 冲刺目标是什么

在Sprint计划会议中，Scrum团队会草拟一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。Sprint目标为开发团队在Sprint中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是Sprint目标。Sprint目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记Sprint目标。为了达成Sprint目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商Sprint待办列表的范围。

4.5.2 Sprint应该多长

Sprint应该多长取决于团队和项目。当然，如果采访Scrum团队的话，你会发现绝大多数团队都会把Sprint长度定在一周到四周之间，其中两周的长度是最常见的。对于新项目来说，可以考虑以下两个因素来确定Sprint长度。

（1）团队的偏好——研发团队都喜欢长一些的Sprint，这样他们可以更从容地完成任务；但产品负责人则更倾向于更加频繁的迭代，这样他们可以更快地看到工作的产品。这两股力量互相平衡，最终决定了团队的偏好。

（2）需求的易变性——如果由于产品的特点或者市场情况而需要产品负责人经常性地修改需求，那么我们就建议选择短一些的Sprint。

有一点需要反复强调：一旦确定了Sprint的长度（前期尝试是可以的），就请不要轻易地修改它。保持团队的工作节奏是非常重要的。尤其当多个团队工作于同一个产品当中时，工作节奏就成为管理的重点。

4.5.3 一个Sprint需要完成多少个故事点

故事点是一个相对的估计，除非刻意安排，每个公司的每个团队都可以有自己的一套对于故事点大小的认知。因此，一个团队需要在一个冲刺中完成多少个故事点这个问题是没有答案的。但是，根据上个冲刺你团队完成的故事点数来估计下个冲刺你可以做多少个故事点是有意义而且可以找到答案的。

团队速率是Scrum当中的一个重要指标。在每个冲刺的最后，团队会将完成的所有任务的故事点相加，最终得到的数字就是团队速率。团队速率可以被用来预计下个冲刺团队可完成的工作。这样就可以帮助团队做出更长时间内可完成工作的预估，并且帮助团队发现和确认问题。

4.5.4 如果评审会议没有可以演示的内容怎么办

如果团队什么工作也没有完成，肯定就没有任何东西可以演示，此时评审会议要讨论的重点就是为什么这个冲刺没有任何工作进展，这对今后的工作有什么影响。当然，如果完成的工作难以演示则是另外一件事。例如，假设完成的工作是架构工作，那么可以展示代码（前提是产品负责人认可代码是可验收的有价值的增量）。

4.5.5 Sprint评审会议有没有一些小技巧

在评审会议当中，你很有可能会遇到大家提出各种各样的问题和建议。团队应该回答与所演示内容有关的问题。但是如果问题跑题，就应该留到会后再处理，最好由产品负责人和相关的干系人召集单独的会议进行讨论。

另外，所有的建议（不管听起来有多不靠谱）记在白板或者是便签纸上，在会中就呈现给所有与会人。会后，任何有价值的建议都应该由产品负责人加入到产品列表中，以便进一步考虑。

4.5.6 回顾会议上的安全检查

在任何一个会议上，不同的与会者都有可能有完全不同的感受。开会的时候有些人会觉得说话很安全很舒适，因此他们也会假设别人也有同样的感觉。但是，有另外一些人，他们也许就感觉很难受，甚至是恐惧，以至于他们很安静，甚至看起来很紧张。

回顾会议需要Scrum团队成员发表自己的观点，因此对于与会者在会议中的舒适度和喜好（喜欢当众发言或者是在小组里发言）对会议成功与否有很重要的影响。安全检查是通过匿名调查来了解团队整体对会议的安全感的情况。

如果在安全检查中，发现大家对回忆的感觉更倾向于“危险”或者“恐惧”，那么ScrumMaster就需要尽量增加小组讨论的环节，让与会者在相对更加安全和舒适的小组里讨论问题。

以下就是安全检查的步骤，以及发给与会者的调查表。