SCRUM 敏捷开发

引自《天天学敏捷：Scrum团队转型记》作者：杨蕾、郑江

为什么敏捷？

根据Scrum联盟2017年年底发布的调查结果显示，有98%的人确认自己所在的公司计划在将来使用敏捷的管理方法来管理项目。著名公司，如外国的谷歌、苹果、脸谱、IBM、HP、PayPal、波音、美国在线、摩根、BBVA，中国的阿里巴巴、百度、腾讯、京东也都有敏捷的项目。更有甚者，据调查报告显示，敏捷正在从它兴起的软件产品部门快速渗透到公司的其他部门，甚至是渗透到其他行业。

传统的开发模式

存在的问题

图片[1]-SCRUM敏捷开发-一一网

瀑布开发模式

模型：

特点：

阶段间具有顺序性和依赖性

必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。

推迟实现的特点

缺乏软件工程实践经验的软件开发人员，接到软件开发任务以后常常急于求成，总想尽早开始编写程序。但是，实践表明，对于规模较大的软件项目来说，往往编码开始得越早，最终完成开发工作所需要的时间反而越长。这是因为，前面阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性后果。

质量保证的观点

软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应该坚持两个重要做法。

每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。
每个阶段结束前都要对所完成的文档进行评审，以尽早发现问题，改正错误。事实上，越是早期阶段犯下的错误，暴漏出来的时间就越晚，排除故障改正错误所需付出的代价也越高。因此，及时审查，是保证软件质量、降低软件成本的重要措施。

问题：

传统的瀑布模型项目面临着质量、可见性不高而风险太多，无法应对变化的问题。

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

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

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

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

什么是敏捷？

无论你是否做过敏捷项目，你肯定听说过“敏捷”这个词汇。但是，敏捷到底是什么？敏捷，英语单词是Agile，意思是灵活的，灵巧的，轻快的，机敏的。

竹内弘高和野中郁次郎使用橄榄球和争球（Scrum）的隐喻描述产品开发：产品开发的“接力赛”方式……可能和要求最快、最灵活的目标有冲突。一种整体方法或“橄榄球”方法（即团队作为一个整体打完比赛，来回传球），也许能够更好地迎合当下的竞争需求。

Scrum图解

迭代和增量

Scrum作为一个框架，它的最大特点就是迭代和增量。

举例：

有一个挑夫，他需要从A村运输500千克粮食到B村。在对粮食的验收标准（产品需求）、运输路线和运输所应使用的最合理的工具（技术）不确定的情况下，他可以通过敏捷的方式完成这个任务：

挑夫把自己完成整个运输任务的过程分为若干个小的迭代（也就是敏捷中的专业术语：迭代），每个迭代以1小时为时间长度。
在第一个迭代里（也就是第一个小时里），他找来自己认为最合理的工具——一个大筐并且选择了自己所知的最合理路线从A村运100千克粮食到B村后返回A村。
在完成了第一个迭代的搬运后，挑夫发现自己其实可以改进运输工具——担子，这样他就可以一次性运输更多的粮食，于是他决定使用担子（工具变化），并且在第二个迭代运输了200千克粮食到B村。
在第三个迭代中，他想到从A村到B村有一条捷径，只要经过一个水塘就可以节省一半的时间，于是他选择了这条捷径，在这个迭代里运输了200千克粮食。可是，负责验收粮食的人却说粮食被水泡了而拒绝收货（产品需求不确定带来的问题）。
于是，在第四个迭代里，挑夫放弃捷径，继续使用原来的路线从A村运输粮食到B村，他运送了200千克粮食到B村。

这里面1小时时长就是迭代，挑夫以1小时为时长来分期完成任务。

挑夫每个迭代运输的粮食就是增量，第一个迭代增量是100千克粮食，第二个迭代是200千克，第三个迭代因为粮食被泡所以增量为零，第四个迭代增量是200千克。

敏捷的核心思想

敏捷方式的核心思想在于迅速把产品投放给用户来为公司带来盈利，敏捷的特点是迭代和增量（迭代和增量的概念请见附录A）。对于公司来说，敏捷开发的目的就是尽早开发出可以工作的产品给用户来赢得市场带来利润。在产品投放市场以后，通过客户的反馈，公司可以继续改进产品功能。而实现这一目的的过程就是，项目被分成若干个迭代（迭代），每段时间里开发出一部分产品功能（增量），并且按照计划将这些功能（增量）投放到市场成为为公司盈利的产品。与传统管理方法提前做好计划，尽量规避变化的管理方式不同，敏捷拥抱需求和技术的变化，认为需求和技术的不明确和变化是必然的。

敏捷特点

需求分析，设计，编码和测试的工作是持续进行的。
产品开发过程是迭代的。
计划更加灵活，可以调整。
项目成员为了同一个目标努力，做出力所能及的奉献；而不强调‘角色’的分工和明确的职责划分。
拥抱变化，及时调整。
交付可工作的软件是最重要的衡量项目是否成功的标志。”

敏捷对组织和项目的好处

更高的生产力和更低的成本。
员工的参与度与工作满意度增强。
更快的产品上市时间。
更高的质量。
项目干系人的满意度提升。

Scrum谁来做？

ScrumMaster

作为Scrum流程的捍卫者和布道者，ScrumMaster在Scrum团队中起到至关重要的作用，他们确保团队使用正确的流程，确保团队正确地召开各种会议，他们训练团队的敏捷思维，他们和团队外的相关项目干系人沟通。根据最新的Scrum研究报告，ScrumMaster在组织中倾向于服务多个Scrum团队。另一个倾向就是在组织中ScrumMaster同项目经理分担职责。

ScrumMaster负责根据《Scrum指南》中的定义来促进和支持Scrum。
ScrumMaster通过帮助每个人理解Scrum理论、实践、规则和价值来做到这一点。ScrumMaster对Scrum团队而言，是一位服务型领导。
ScrumMaster帮助Scrum团队之外的人了解他如何与Scrum团队交互是有益的，通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的价值。
ScrumMaster服务于产品负责人……
ScrumMaster服务于开发团队……
ScrumMaster服务于组织……

ScrumMaster每日工作列表

一天的开始

更新和检查目前冲刺的燃尽图（有关燃尽图的内容请参见3.4节）报表。
如果团队落后于时间表，ScrumMaster需要帮助团队想办法追上进度。同时，ScrumMaster需要确保所有完成了的任务都已经被标记成了完成，这样燃尽图表的数据才准确。
检查Sprint待办列表里的条目和相应的任务情况。
检查是否有任何遗漏的信息。
- 遗漏条目的工作量估算信息。
- 遗漏具体任务的估算信息。
- 正在进行和已经完成的任务遗漏任务人信息。
检查是否有任何不一致的信息。
- 是否有已经决定不做了的条目仍旧可以被选中。
- 已经完成了的任务却没有标记成完成。
- 没有完成的任务却被标记成完成。

工作期间

找出所有影响进度的工作。
协调Scrum每日站会。
评审新加入产品列表的用户故事、技术故事和问题，确保新加入的条目可以被正确地指派到相应Scrum团队。

每日工作结束时

和每天开始时一样：评审状态，查看是否有任何遗漏、错误的信息，跟踪记录团队待解决问题的状态。

准备计划会议

协调产品列表梳理会议。
统计下一个迭代的生产能力。
在各种电子和物理工具上更新相应的信息。

计划会议时

从头到尾查看产品列表里的条目，并且将条目一个一个地从优先级最高的开始顺序念给团队。
协调估算过程。
记录团队讨论的内容（例如，估算的工作量，条目的详情）。
将相应条目拖曳到下一个Sprint的待办列表。
建议团队在工作量范围以外多评估一部分用户故事以备不时之需。

在评审会议上

ScrumMaster需要组织会议确保相应成员到场。

在回顾会议上

ScrumMaster组织团队成员一起回顾自上个回顾会议以后团队的工作状态。
ScrumMaster组织，收集和记录团队成员讨论的信息。
ScrumMaster协调确认下个迭代团队需要做的改进措施以及负责人。

ScrumMaster角色图解

产品负责人

产品负责人的职责是将开发团队开发的产品价值最大化。产品负责人是负责管理产品待办列表的唯一负责人。

产品待办列表的管理包括：

清晰地表述产品待办列表项；
对产品待办列表项进行排序，使其最好地实现目标和使命；
优化开发团队所执行工作的价值；
确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作；
确保开发团队对产品待办列表项有足够深的了解。

产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品负责人是负最终责任的人……为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定……”

产品负责人每日工作列表

每天一开始

●　要检查Sprint待办列表里的条目和相应的任务情况，如果有任何关于进度的疑问都需要追踪。

●　协助团队成员解决问题，澄清需求。

●　尽早评审已经开发完成的功能，确认功能是否是期望的。如果不是则需要决定是否要在本个迭代做出更改，或者可以放到下个迭代继续完成，或者需要创建新的用户故事。

●　编写新的用户故事来完成更多的功能，并且向团队澄清新的用户故事。

●　编写史诗级用户故事（如果功能太大，单个用户故事无法承载的话）。

●　报告任何你发现的软件问题。

●　参加每日站会（如果你和你的团队认为这样有助于完成迭代目标）。

●　听取并且回答每日站会的三个标准问题。

●　发现需要你进一步跟进的任务。

●　和团队分享有用的信息。

准备计划会议

收集足够数量的待办列表项以便团队在计划会议上评审，并且按优先级排好顺序。
要以商业价值作为排序的依据，同时考虑到风险、潜在失败的可能性和其他相关的因素。
列表项的信息里要包含它与其他列表项之间的依赖关系。

计划会议中

和研发团队、ScrumMaster一起使计划会议变得更有效。
产品负责人必须参加计划会议。
回答问题以澄清和解决有可能影响实施和估算的问题。
如果需要的话，需要更新用户故事的主题和描述以避免歧义和误解。
如果需要的话，重新更改用户故事的排序以便Sprint可以更有效。

评审会议中

评审团队在过去的一个迭代中提交的功能是否符合期望，确认是否接收团队提交的潜在可发布增量。

回顾会议中

ScrumMaster主持会议，团队共同决定产品负责人参与该会议是否对团队实现目标更加有帮助。

产品负责人角色图解

开发团队

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

在Scrum的每个冲刺当中，开发团队为了实现计划里的功能，他们必须完成所有的相关工作，包括产品设计，开发，集成和测试。为此，他们必须具备完成这些工作的所有技能。区别于传统开发方法里的“只负责自己那一部分工作”，作为一个整体，团队对功能的实现负责。

开发团队每日工作列表

一天的开始

查看目前冲刺的燃尽图报表。
如果团队落后于时间表，你需要确认自己是否可以帮助团队追上进度（尤其是当你手中的任务落后于进度的时候）。你需要确认所有你已经完成的任务在相关的系统和任务板上都已标记为完成。
检查你今天要做的工作。
如果你今天没有可以做的工作，你需要和团队成员一起找到你可以帮忙的工作。

一天当中

当你完成了一个任务的时候，要立即更新任务状态。
更新所有相关项的信息。
如果你开始了一个新的任务，请把任务状态更改成“进行中”并且填写任务人。
如果你的任务完成了，请将任务状态标记成完成。
更新完成任务需要的剩余时间信息。
完成你领取的任务。如果需要帮助，请不要犹豫，立即让大家知道。
和大家一起协作以完成任务。和大家讨论你的工作以便可以完成任务。
参加Scrum每日站会。
汇报你的工作信息。
从上次站会之后你都做了些什么。
你计划在下次会议之前都做些什么。
你遇到了什么阻挠你工作进度的需要他人帮助的问题。
确认是否可以帮助其他人。
帮助产品负责人完成需求的更新。
回答产品负责人问题并且提供你的理解。
编写技术故事。
报告产品缺陷（例如，你在完成任务时进行的验收测试中发现的缺陷）。
和产品负责人澄清Sprint待办列表中的用户故事的细节（越早越好）。如果用户故事没有按照产品负责人的期望完成的话，产品负责人会做出决定是否在当前迭代中立即修改或者以后再改。

一天结束时

更新你的工作状态。
查看燃尽图确认团队工作进展。

准备计划会议

梳理产品列表（和产品负责人讨论以澄清对条目的理解）。
创建技术用户故事。

计划会议中

讨论并且估算每个列表条目

计划会议结束后

在计划会议结束后需要立即将用户故事分解为任务。这对正确完成工作非常重要。

和团队成员一起分解任务（所有的用户故事和缺陷）并且提供任务工作量的估算。
对于新的团队来说，这通常需要整组人一起开会讨论决定。
对于有经验的团队，做法相对灵活；可以一个人负责进行所有估算，然后其他组员进行检查以确保一致。

在评审会议上

团队成员负责向产品负责人演示功能。

在回顾会议上

在ScrumMaster的组织下，团队成员一起回顾自上个回顾会议以后团队的工作状态。
在ScrumMaster的协调确认下，团队成员一起确认下个迭代团队需要做的改进措施以及负责人。

开发团队角色图解

Scrum组织中项目管理职责的映射

Scrum怎么做？

产品列表

产品列表由各个待办事项组成，每一个待办事项称之为产品列表条目。按照性质区分，可以把产品列表条目大致分为：经常写成用户故事形式的特性、缺陷、技术工作和知识获取。

产品列表应该具有以下特点：

详略得当：马上要做的条目要详细描述，短时间内不做的内容粗略。
涌现的：只要有正在开发或维护的产品，产品列表就永远不会完成或冻结。它会根据不断涌入的、具体的、有经济价值的信息持续更新。
做过估算的：每个产品列表条目都要有大小估算，相当于开发这个条目需要完成多少工作。
排列优先顺序的：对短期内要做的几个冲刺要仔细排好优先顺序。但是对于短期内不做的条目，除了给出一个大致的优先级，其他任何工作都是不值得做的。一般情况下，产品列表需要至少包括以下信息：用户故事名称（列表条目）、功能模块、史诗级故事、描述、接收标准、状态和备注。
用户故事（列表条目）：我们使用用户故事技术来描述产品列表条目。
功能模块：用户故事所属功能模块。
史诗级故事：“史诗级故事”（epic）是用来描述大型用户故事的通用术语。史诗级故事是一个我们觉得它“个头儿”有点儿大，因而需要进一步拆分的故事。

Sprint待办列表

Sprint列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作，例如，在回顾会议中所发现的团队改进任务，团队计划要在当前Sprint完成。

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

待办列表应该具有以下特点：

Sprint列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。
Sprint列表是开发团队对于下一个产品增量所需的功能以及交付这些功能到“完成”的增量中所需的工作的预测。
为了确保持续改进，Sprint列表是少包含一项在前次回顾会议中确定下来的高优先级的过程改进。
Sprint列表是拥有足够细节的计划，任何进度上的变化可以在每日展会中清晰地看到。开发团队在Sprint期间修改Sprint列表，使得列表在Sprint期间涌现（根据不断涌入的、具有经济价值的信息持续更新）。
在Sprint期间只有开发团队可以改变Sprint列表。
Sprint列表是高度可见的，是对开发团队计划在当前Sprint内工作完成情况的实时反映，由开发团队全权负责。

完成的定义

当我4岁的侄子在为自己把所有的玩具都放到了箱子里而感到开心的时候，我对他的表现表示了赞许，但是我告诉他：你的工作并没有做完，因为你把应该放在“汽车”箱子里的汽车放进了“火车”箱子里。这个简单的例子揭示了一个重要的事实，当有两个或更多的人参与同一个事务的时候，最重要的是设定和统一期望值。Scrum理解这句格言的重要性并提供一个重要的概念来帮助我们做到这点：完成标准（DoD）。

例如：

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

完成的定义可以随时间演变。
完成的定义和接收标准不同（当某个“接收标准”里的需求适合于所有的用户故事，那么它就是完成标准里的一项；但如果该需求只是适用于所有用户故事的一个子集，那么它就是这个用户故事子集里的故事的验收标准）。
完成的定义可以是多个不同层面的（任务层面，用户故事层面，交付层面）。
完成的定义里会包含一些限制因素（可移植性，可伸缩性，可维护性，安全性，可扩展性，互操作性）。

监测

走进Scrum团队的工作区，你有可能会注意到墙上贴着手绘的图表，以及一个贴满了便签纸的任务板。这些信息都可以被称为信息辐射器，用来检测和反映团队工作的状态。当然，如果你的团队是分布式团队，那么你也可以选择用软件去展示这些信息。总之，展示信息，方便监测和调整是我们想要的。除了我们之前提到的任务板，燃尽图是我们最常用的信息展示和监测工具。

燃尽图：

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

Scrum做什么？

计划会议

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

工作量预估

计划会议第一部分：做什么

计划会议第二部分：怎么做

Sprint待办列表

计划会议以后

Scrum每日站会

提起Scrum，很多人可能第一反应会是“每天都站着开会”。站会是Scrum最有名的一项活动。每日站会就是团队的脉搏，健康的脉搏稳定，持续而又轻快。甚至很多不具备实践敏捷的组织和项目，都会使用每日站会这个活动来促进沟通。

会议内容：

昨天，我为帮助开发团队达成Sprint目标做了什么？
今天，我为帮助开发团队达成Sprint目标准备了什么？
是否有任何障碍在阻碍我或开发团队达成Sprint目标？

评审会议

冲刺评审会议被有些人称为“Sprint演示”会议，因为在这个会议上团队可以炫耀他们的工作成果给项目干系人。炫耀也好，演示也罢，都说明这个会议是要展示工作成果，但你可千万别被这个表面现象所迷惑，因为评审会议更重要的是为了收集项目干系人的各种反馈，达到检视和调整的目的。

评审会议流程

会前：提前发送评审会议邀请给干系人。确定会议室、与会人等相关信息。
会中：会议议程。
- 会议开始：介绍会议目的和时间安排。
- 演示：团队代表演示冲刺成果。
- 讨论现状。
- 讨论障碍和改进。
- 确定下一个Sprint要做的产品列表共识。
- 会议总结。
会后：会议纪要梳理及跟踪。

Sprint评审会议包含以下内容

参会者包括Scrum团队和产品负责人邀请的主要利益攸关者。
产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”。
开发团队讨论在Sprint期间哪些工作做得很好，遭遇到什么问题以及问题是如何解决的。
开发团队演示“完成”的工作并解答关于所交付增量的问题。
产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可能的目标交付日期（如果有需要的话）。
参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下来的Sprint计划会议提供有价值的输入信息。
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变。
为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

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

回顾会议

Scrum鼓励变化，鼓励尝试；最终目的是找到适应环境的实践；当然如果环境变了，实践就要做出相应的调整。回顾会议是Scrum检视与调整的一个重要环节。在这个会议上，团队对自己的开发过程进行改进，并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。就像我们频繁地迭代和交付是为了快速地获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力成长不断改进。

会议关键

会议目的——检视和调整Scrum团队的流程。
会议时间——每个ScrumCycle的最后一个会议（推荐开会时间是每个Sprint最后一天的下午）。
时间盒：≤2小时（两周的Sprint）。
会议讨论的问题：
- 检视前一个Sprint中关于人、关系、过程和工具的情况如何。
- 找出并加以排序做得好的和潜在需要改进的主要方面。
- 同时，制订改进Scrum团队工作方式的计划。

实践问题

什么项目应该用SCRUM？

例如：

你的项目总是不能按时发布。
你的项目花了很多钱但产出价值却很低。
你的产品无法跟随上市场变化的趋势。

实践Scrum时会遇到问题吗？

说实话，我敢100%保证，你会遇到很多问题。对于大部分组织来说，你们必须改变组织文化。所谓的组织文化就是组织成员的行为。在改变的过程中，也许你会遇到很大阻碍，大家也许会很抵抗。组织里的保守派也许会要求在改变之前能有明确的回报可以证明改变的益处。你需要坚持，不要轻易放弃。请记住Scrum是基于经验主义的，所有的问题都是基于经验逐步解决的。Scrum是自组织的，请依靠和相信你的团队，他们是真正创造价值的人。

如果项目工作太多，一个Scrum团队做不完怎么办（团队之间的工作协调）

如果你有足够的工作和足够的资源，那么就请你通过组建新Scrum团队的方法来加速你的速度。如果你的工作太多但是资源不足，那么就请你通过给特性排列优先级的方式，保证团队只开发最重要的功能。

迭代和冲刺的区别是什么？

迭代的英文为Iteration。迭代是一个通用的敏捷术语，指的是单个开发迭代。冲刺的英文为Sprint。作为敏捷的一种方法的Scrum，冲刺是指Scrum的一个迭代。如果把语境局限在Scrum的话，迭代和冲刺指的都是一回事儿。

为什么在开发团队里只有工程师而不是开发、测试呢？

在Scrum里，责任和成果属于整个团队。为了强调团队的整体性，Scrum开发团队里只有一种角色，就是工程师。但这并不意味着每个人都必须拥有相同的技能，或者是说做相同的工作。这也许对每个人未必完全公平。例如，一个初级工程师和高级工程师的能力就不相同。但是，还是那句话，Scrum强调团队作为一个整体承担责任。

产品负责人和ScrumMaster都是全职工作吗？

为了保证Scrum团队的工作，ScrumMaster和产品负责人需要有足够的时间来完成他们的工作。一个比较常见的陷阱是，除了日常工作以外，组织会给某个人分配产品负责人的新角色，让他同时兼顾日常工作和产品负责人的角色。这样做的结果通常都不好。我们比较推荐的做法是让产品负责人和ScrumMaster成为全职的工作。

质量控制在Scrum里怎么体现？

在Scrum里，质量控制不是一个在产品发布以后才执行的工作。相反，在Scrum当中，质量控制应该包括在所有的从开始到结束的冲刺过程中。在项目和每个冲刺开始的时候，团队就应该注意如何检查各个工作的进行。因此，我们说质量控制从用户故事的定义就已经开始了。所有的功能和非功能测试都应该被覆盖到。

Scrum的核心价值观？

怎样才能通过挑选团队成员来确保团队不会因为各自强烈的自我意识和持续不断的争吵而分崩离析呢？最好的办法就是所有团队成员都要有用户Scrum的核心价值观，并且以此形成他们的职业特质。Scrum的核心价值观：活力，共情，好奇，友善，尊重（请参见附录D）。

Scrum有没有一套流程，有没有标准？

对不起，Scrum不提供流程或者最佳实践。Scrum的游戏规则就是它的标准，这些全都包含在《Scrum指南》当中。

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

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

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

我们在本章中曾讨论过这个问题，在这里简单罗列一下。

你需要一个任务板，不同颜色的便签纸，白板笔。如果不是远程团队，那么就请在办公室团队的位置准备一个实体白板来作为任务板（在每日站会的部分，我们会具体讨论如何组织任务板的细节）。
你还需要管理产品列表和冲刺待办列表的工具。简单到一个Excel表格，复杂到Jira系统，只要可以帮助管理好你的待办事项就没问题。

冲刺目标是什么？

在Sprint计划会议中，Scrum团队会草拟一个Sprint目标。Sprint目标是在这个Sprint通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确开发增量的目的。Sprint目标为开发团队在Sprint中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个连贯一致的功能，也即是Sprint目标。Sprint目标可以是任何其他的连贯性来促使开发团队一起工作而不是分开独自做。开发团队必须在工作中时刻谨记Sprint目标。为了达成Sprint目标，需要实现相应的功能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商Sprint待办列表的范围。

Sprint应该多长？

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

团队的偏好——研发团队都喜欢长一些的Sprint，这样他们可以更从容地完成任务；但产品负责人则更倾向于更加频繁的迭代，这样他们可以更快地看到工作的产品。这两股力量互相平衡，最终决定了团队的偏好。
需求的易变性——如果由于产品的特点或者市场情况而需要产品负责人经常性地修改需求，那么我们就建议选择短一些的Sprint。有一点需要反复强调：一旦确定了Sprint的长度（前期尝试是可以的），就请不要轻易地修改它。保持团队的工作节奏是非常重要的。尤其当多个团队工作于同一个产品当中时，工作节奏就成为管理的重点。