Scrum入门基础(Scrum in a nutshell)

Scrum 入门基础

出家如初 , 成佛有余http://www.yeeach.com

2010年 8 月

Scrum 是什么？Scrum是橄榄球运动的一个专业术语，表示“并列争球”。

这里特指一种敏捷开发的模型 . Scrum是一个迭代性、增量性的流程，适用于任何的产品开发以及工作管理。 Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

2

Scrum 目标

Manage Complexity, Unpredictability and Change

through Visibility, Inspection and Adaptation

通过高透明性、检验和适应性来管理复杂性、不可预测性和变化

Scrum 核心价值观承诺（ Commitment）：承诺不只是把一项工作分配给团队，也不是简单的答应去完成。它是建立在目标之 上的来自内心的接受和应许，这里只有“做”和“不做”，没有“让我试试”

专注（ Focus）：像邮件和不相关的会议就是很常见的一些分散注意力的事情，我们需要做得是不转移注意力，把精力全部集中在承诺的事务上

公开（ Openness）：保持一直让任何有兴趣的人员都可以在墙上、 wiki页面或者仪表盘工具上获知项目当前状况，能够了解多少功能已经完成，哪些正在做，每次迭代和发布的目标是什么

尊重（ Respect）：每个团队成员都必须被尊重的看待，大家一起指定工作规范（ working agreements）

勇气（ Courage）：为了接受并负责任的交付产品，团队成员必须有足够的勇气来对大家说“不”，比如不能承诺时，对纳入 sprint的故事说“不”等

4

Scrum理论的三大支柱 Scrum是以经验过程控制理论为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险。 Scrum的三大支柱支撑起每个经验过程控制的实现。

第一大支柱是高透明性（ Transparency）—高透明度确保管理结果的人看得到那些影响结果的过程方面。这些过程方面不仅要透明，而且那些被观察到的方面也必须被充分了解。

第二大支柱是检验（ Inspection）—开发过程中的各方面必须做到经常性的检验，以确保及时发现过程中的重大偏差。

第三大支柱是适应（ Adaptation）—如果检查员经检验发现过程中的一个或多个方面不满足可接受标准，并且最终产品是不合格的，那么检查员就必须对过程进行调整。调整工作必须尽快实施以减少进一步的偏差。

5

Scrum特点 Scrum规定了一个非常简单的开发流程。

Scrum是现有设计流程的总结。

Scrum以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。

Scrum是一个控制由利益和需求冲突导致的混乱的流程。

Scrum是改善交流并最优化合作的方式。

Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。

Scrum是最大化生产率的一种方法。

Scrum适用于单一的项目到整个组织。 Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。

Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。

6

敏捷联盟宣言

敏捷实践原则1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件

来使客户满意。

2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3. 经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

敏捷实践原则5. 工作的软件是首要的进度度量标准。

6. 敏捷过程提倡可持续的开发进度。责任人、开发者和用户应保持一个长期恒定的开发速度。

9. 不断关注优秀的技能和好的设计会增强敏捷能力

10.简单——使未完成的工作最大化的艺术——是根本的。

11.最好的构架、需求和设计出自于自组织的团队。

12.每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整

各种软件开发方法对比

10

各种敏捷过程 SCRUM

http://www.scrumalliance.org/

XP(eXtreme Programming)

http://www.extremeprogramming.org/

The Agile Unified Process (AUP)

http://www.ambysoft.com/unifiedprocess/agileUP.html

FDD(Feature Driven Development)

http://www.featuredrivendevelopment.com/

Dynamic Systems Development Method (DSDM)

http://www.dsdm.org/

各种敏捷开发方法对比

12

Scrum VS. XP

XP与 Scrum是敏捷方法中被业界采用最为广泛采用的两种实践

Scrum注重的是管理和组织实践，而 XP关注的是实际的编程实践，两者都聚焦于信息价值流和信息沟通，除了迭代长度稍有差别外，大多数 Scrum实践与 XP是兼容且相互补充

组合使用 Scrum和 XP会有显著收获！ XP的结对编程、测试驱动开发（ TDD）、持续集成等最佳实践仍然可以在 Scrum中使用

Scrum与 XP的组合使用可以参考： 硝烟中的Scrum和 XP

Scrum and XP fit together

13

Scrum VS. XP

14

Scrum 成功案例：公司

• Microsoft

• Yahoo

• Google

• Electronic Arts

• Philips

• Siemens

• Nokia

• Salesforce.com

• BBC

• 腾讯

• 阿里巴巴

• 华为

• 盛大

• 淘宝

• Facebook

• Twitter

• Time Warner

• others

Scrum 成功案例：行业• Commercial software

• In-house development

• Contract development

• Fixed-price projects

• Financial applications

• ISO 9001-certified applications

• Embedded systems

• 24x7 systems with 99.999% uptime requirements

• the Joint Strike Fighter

• Video game development

• FDA-approved, life-critical systems

• Satellite-control software

• Websites

• Handheld software

• Mobile phones

• Network switching applications

• ISV applications

• Some of the largest applications in use

迭代 vs.增量

迭代：在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程；

增量：在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。

例子： 假设现在要开发 A,B,C,D四个大的业务功能 , 每个功能都需要开发两周的时间 . 则

对于增量方法而言可以将四个功能分为两次增量来完成 , 第一个增量完成 A,B功能 ,第二次增量完成 C,D功能 ; 而对于迭代开发来将则是分两次迭代来开发 , 第一次迭代完成 A,B,C,D四个基本业务功能但不含复杂的业务逻辑 , 而第二个功能再逐渐细化补充完整 相关的业务逻辑 . 在第一个月过去后采用增量开始时候 A,B全部开发完成而 C,D还一点都没有动 ; 而采用迭代开发的时候 A,B,C,D四个的基础功能都已经完成 .

17

Scrum 核心过程

Scrum on a page

19

Sprints( 冲刺 )Sprint的本意是指冲刺，在 Scrum中，一个 Sprint就是一个迭代， Scrum 项目通过一系列的 sprints来推进， Sprints类似于极限编程的迭代。

Sprint长度通常 2-4周，它是一个时间箱，在项目进行过程中不允许延长或缩短 Sprint长度。

稳定的周期会带来更好的节奏

Sprint由 Sprint计划会议、开发工作 ( 需求分析、设计、开发、测试、质量控制等 ) 、每日站会、 Sprint评审会议和 Sprint回顾会议等活动组成。

Sprint一个紧跟一个进行，之间没有任何时间间隔。

一个 Sprint 周期内需求不发生变更计划 Sprint周期的长度要依赖于你能在多长时间内保证在 Sprint期间需求不发生变更

Change

有效的沟通

22

让 Scrum团队坐在一起！

让 Scrum团队坐在一起！

“一起”意味着：—互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。—互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。

—隔离：如果整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到。

23

时间盒迭代（ timeboxing）时间盒迭代（ timeboxing/timeboxed iterations）的核心思想：在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。

如果在迭代进行中，开发团队发现进度落后，无法完成全部的迭代开发任务和计划的需求功能时，敏捷方法通常允许或要求开发团队与客户协商，减少开发任务或需求（可以放入下一次迭代中），以保证在既定的时间点提交高质量的成果（尽管这个成果可能不完整）。

参考： 为什么时间盒迭代提倡删减需求任务？

EssUP迭代核心——时间盒 Time boxing

24

Scrum Framework

•产品负责人•Scrum 教练•团队

角色（ Roles ）

•Sprint 计划•Sprint 评审•Sprint 回顾•每日 scrum 例会

仪式（ Ceremonies）

•Product backlog•Sprint backlog•Burndown charts 燃尽图

产出工件（ Artifacts）

产品负责人（ Product Owner ）

定义产品特性

决定发布日期和内容

对产品收益负责 (ROI)

根据商业价值排定特性的优先级

根据需要在每个迭代中调整产品特性和优先级

接受或否决开发结果

Scrum 教练（ Scrum Master ）

对项目组来说代表管理层负责制定 Scrum价值观念和实践，确保每一个成员都认同 Scrum价值观和遵守其游戏规则

组织每天的 Daily Scrum会议帮助 Scrum Team规划 Sprint计划清除障碍确保团队功能完备富有效率促进所有角色和职能的紧密协作替团队抵御外部干扰

Scrum 团队

一般 5-9人跨部门 : 程序员，测试员，界面设计人员等等成员必须是全职投入：可以有例外 ( 例如数据库管理员等 )

团队自我组织：理想情况下，团队成员是平等的，不分头衔一个 sprint中保持成员稳定负责将 Product Backlog转化成 Sprint中的工作项目所有团队成员协调 , 合作完成 Sprint中每一个规定的工作所有团队成员和 Scrum Master负责每一个 Sprint的成功

•Product owner•Scrum Master•Team

Roles

Scrum Framework

•Product backlog•Sprint backlog•Burndown charts

Artifacts

•Sprint 计划•Sprint 评审•Sprint 回顾•每日 scrum 例会

仪式

Sprint 计划会议（ Sprint Planning Meeting）Sprint计划会议包含两部分内容：“做什么”和“怎么做”

Sprint计划会议 1 ：确定该 Sprint将要完成什么任务，用时 4 小时。

—产品负责人给团队介绍最高优先级的 Product Backlog条目，并一起决定接下来的 Sprint中开发什么功能。 Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少 Product Backlog的条目。

Sprint计划会议 2 ：团队研究在 Sprint内如何构建产品增量，用时 4 小时。

—团队先以设计展开工作，设计过程中，团队确定任务，这些任务就是将Product Backlog转化成可用软件的具体工作。任务需要被分解，以便在一天之内完成。这个任务列表就是 Sprint Backlog。团队通过自组织，并且是自己认领的方式分担任务，任务认领可以在 Sprint计划会议上进行，或也可以 Sprint中及时（ Just-in-time）确定。

30

Sprint 计划会议

Sprint 计划会议 1 ：做什么

• 分析和评估 product backlog• 确定 sprint 目标• 排定优先级

Sprint 计划会议 2 ：怎么做

• 决定怎样实现 sprint 目标 ( 设计 )

• 从产品 backlog （用户故事或特性）中创建 sprint backlog ( 任务 )

• 估计 sprint backlog 故事点 (人天 )

Sprint目标Sprint目标

SprintbacklogSprintbacklog

业务约束条件业务约束条件

团队能力团队能力

Product backlogProduct backlog

技术技术

现有产品现有产品

Sprint 计划会议

Sprint 计划会议 1

产品负责人和团队一起，在先前评估的成果基础上，定出 Sprint 目标和既定产品 Backlog。

目标—定出 Sprint 目标和既定产品 Backlog

会议准备—邀请与会者：产品负责人、 Scrum Master、团队所有成员—已按优先级排列产品 Backlog 中各项问题—已评估 Backlog 中的各项问题—把产品 Backlog 公开给会议中的每个人，保证其可被获取—预期团队中有哪些人已明确会缺席（如度假）—保证房间环境适合小组讨论—每个人都可以获取上次 Sprint 评审会议和 Sprint 回顾会议的结果—Sprint 时间表已经安排 —（可选）为既定 Backlog 准备图钉板 : 一个至少 2x2 米的图钉板、卡片和贴纸

、荧光笔—（可选）用作计划纸牌的卡片

Sprint 计划会议 1会议进程（ 4 小时）

—把 Sprint 时间表公开给所有人—把 Sprint 评审会议的结果公开给所有人—把 Sprint 回顾会议的结果公开给所有人—产品负责人向团队产品阐述产品远景—产品负责人和团队一起确定 Sprint 目标—如果 Backlog 里有问题遗漏：产品负责人有权限往 Backlog 里添加问题—如果产品 Backlog 完全未被评估：选择 Backlog 中您认为是最小用例的问题，

并指派其工作量为 2 个 Story Point。以这个最小用例的工作量标准，分配 Backlog 中其他问题的 Story Point

—如果 Backlog 中的一些问题尚未被评估：根据其他问题工作量，评估这些问题的 Story Point 量

—如果产品 Backlog 中的各项还没能合理地按优先级排序 : 产品负责人对产品 Backlog 中的各项按优先级排序

—产品负责人和小组成员相互认可这 Sprint 目标和既定产品 Backlog

会议结果—为 Sprint 计划会议 2 的进行准备好既定产品 Backlog 33

Sprint 计划会议 2在 Sprint 计划会议 2 中，团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内

目标—确定所有任务，生成 Sprint Backlog，确认 Sprint 目标

会议准备—邀请与会者： Scrum Master、团队所有成员、产品负责人（可以有权得知所有问题）

—任务规划时可以参考既定产品 Backlog—（可选）为既定 Backlog 准备图钉板 : 一个至少 2x2 米的图钉板、卡片和贴纸、荧光笔

Sprint 计划会议 2会议进程（ 4 小时）

—团队成员从 Backlog 的各项问题中分出相应的任务—确保考虑到工作中所有的细节 : 编码、测试、代码评审、会议、学习新技术、编写文档

—如果任务需时超过一天：尝试把该任务分割成几个小任务—如果团队认为 Sprint Backlog 中项过多：和产品负责人一起删减 Backlog 中的问题

—如果团队认为 Sprint Backlog 中的项过少：和产品负责人一起从产品 Backlog 中选出最重要问题，加入 Sprint Backlog 中

—团队确认 Sprint 目标会议结果

—Sprint 目标和 Sprint Backlog 对于公司内的所有人都是公开的

—所有团队成员都可以获取 Sprint Backlog 中的任务 35

场景展示 - 索引卡

Sprint评估会议目标：评估出产品 Backlog 中各项问题的相对工作量

会议进程—介绍会议的目标—在用作计划纸牌的一组卡片上写上标签 1 ， 2 ， 3 ， 5 ， 8 ， 13， 21

， 34， 89，并发到每个团队成员的手上—产品负责人介绍其需要评估的产品 Backlog 中的那些部分—对于产品 Backlog 中的各项问题：

由产品负责人来解释 Backlog 中该问题背后的详细用例。 团队各成员选出其手上的一张计划卡片，以投票决定他所认为的该问题的工作量大小

。 所有团队成员同时亮出他们的卡片 如果评估结果有分歧，让意见分歧最大的成员进行辩论，然后再次投票，直到所有人

意见一致评估结果被添加到 Backlog 项

—通过简洁的总结来结束评估会议37

场景展示 - 计划纸牌

每日 Scrum例会（ Daily Scrum）目标：团队成员间工作进度的沟通和协调

特点

—每天进行

—10-15分钟

—站立式会议 ( 防止超时 )

不是为了解决问题

—邀请所有人参加

—只有团队成员， Scrum教练，产品负责人才能发言有助于避免其他不必要的会议

场景展示 - 每日站立会议

这不是给 Scrum教练的状态报告—这是在所有成员面前进行的承诺

你昨天干了什么 ?你昨天干了什么 ?11

你今天打算做什么 ?你今天打算做什么 ?22

有什么困难或依赖吗 ?有什么困难或依赖吗 ?33

每日 Scrum例会（ Daily Scrum）

每个人回答 3 个问题

每日 Scrum例会（ Daily Scrum）不是项目状况更新会议 , 或关于某个成员是否落后于时间安排

是 Scrum成员互相的承诺

不能分散精力成为系统设计讨论会

会议中提到的问题应会后解决

Scrum Master指导团队执行规则来控制会议时间，并保证团队成员进行简短有效的汇报 , 焦点集中于每个人的 3 个问题

Product Owner在会议上旁听 , 主要兴趣在于项目进展和困难

Scrum Team由此可以知道整个项目进展的时间表

Scrum Master要确保扮演“鸡” 的角色不允许在会议上发言或以各种方式干扰会议。

Pigs and Chickens

Product OwnerScrum Master

Team Members

UsersManagersMarketing

Pigs and chickens “ Pigs and chickens” 是 Scrum软件开发模式中的一个比喻，用来比喻参会者在每天的 Scrum会议中所起的作用。

对于程序员来说，每日 Scrum是指每天开始工作时的一个简短的会议，其中小组成员估量他们项目进行的情况，并确定下一步需要做什么。

如果参会者是“猪（ pig）”，这意味着他直接负责完成手头的任务。如果参会者是“鸡（ chicken）”，他可能会参与手头的任务，但如果任务没有按时完成，他不是那个需要承担责任的人。在日常 Scrum中，猪会发表言论讨论。鸡必须保持沉默。

这些角色通常是自我分配，它是为了防止每日 Scrum会议时间太长，谈话脱离话题。除了强制执行只有“猪”可以通话的规则外，会议主持人（称为 Scrum Master）要使 Scrum会议继续下去。

44

任务看板图（ Task Kanban Board）

在敏捷项目里，挂在墙上的“人人可见的大图表”是一种普遍的实践，它被用来共享项目的状态并将之可视化。

任务看板图（ Task Kanban Board），它的名字来自 TPS （ Toyota Production System）所用的“ Just-In-Time” （ JIT）生产方式

任务看板图（ Task Kanban Board）显示了在本次迭代中要完成的所有任务的当前状态。任务用卡片（便笺纸）来代表，状态则由板上分别标有“未做”、“正做”和“做完”的三个区域来代表。

45

场景展示 - 任务看板

场景展示 - 任务看板

47

Sprint评审会议（ Sprint Review）目标：根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标

通常采用演示新功能或底层架构的形式

非正式

—规定用 2 小时来准备

—不需要幻灯片整个团队都参与

邀请所有人 ( 让别人都知道 )

Sprint 评审会议（ Sprint Review ）会议进程

—团队按 Backlog 中的问题，逐个地介绍这次 Sprint 的结果，和演示新功能。

—如果产品负责人想要改变功能：添加一个新问题到Product Backlog 中

—如果对功能有一个新的想法：添加一个新问题到Product Backlog 中

—如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog

会议结果—对这次 Sprint 的结果和整个产品的开发状态的共识

49

Sprint回顾会议（ Sprint Retrospective）目标：定期查看哪些东西工作正常，哪些不正常

指导原则—不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的，他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩

通常 15–30分钟每个 sprint结束后进行全体成员参加

—Scrum教练—产品负责人—团队—客户和其他相关人员

Sprint回顾会议（ Sprint Retrospective）会议准备

—在挂纸板上写上主要指导原则—在挂纸板上画上一个至少三页纸连在一起长的时间轴—在挂纸板上写上“我们的成功经验是什么”—在挂纸板上写上“有什么能够改进”—在挂纸板上写上“谁负责”，然后分成两个区域——“团队”和“公司”

51

Sprint回顾会议（ Sprint Retrospective）会议进程—介绍会议目标—介绍会议主要的指导原则— 在时间轴上，标记出 Sprint 的开始和结束时间— 向与会者解说如何使用该贴纸进行工作—派发贴纸，并且让每人写上他们认为这次 Sprint 中最为重要的事，限时 5 分钟— 每个与会者轮流把他的贴纸贴到挂纸板的时间轴上，并用两句话来解说这事有什么特别的地方

— 分发贴纸，并让每人写上“我们的成功经验是什么”，限时 5 分钟— 每个与会者轮流把他的贴纸贴到挂纸板“我们的成功经验是什么”的区域上，并解说— 分发贴纸，并让每人写上“有什么能够改进的”，限时 5 分钟— 每个与会者轮流把他的贴纸贴到挂纸板“有什么能够改进的”的区域上，并解说。— 对于挂纸板上“有什么能够改进”的区域中的每一项，询问团队“谁去负责解决这个问题？

”，并把贴纸移到挂纸板中“谁负责”的区域中— 和团队一起把这些区域按优先次序排好— 给会议做个总结

52

Sprint回顾会议（ Sprint Retrospective）

会议结果—挂纸板上“谁负责”这栏对于公司内所有人是公开的—把与公司范围相关的障碍增加到障碍 Backlog 中去—把与团队范围相关的障碍增加到障碍 Backlog 中去

53

场景展示 - 回顾会议看板

Scrum 会议时间安排如果是为期 30 天的 Sprint，建议其常规的 Scrum 会议时间安排如下：

—Sprint 计划会议 1 ： 4 小时—Sprint 计划会议 2 ： 4 小时—Scrum 每日例会： 15分钟—Sprint 评审会议： 2 小时—Sprint 回顾会议： 2 小时

55

•Product owner•ScrumMaster•Team

Roles

Scrum Framework

•Sprint planning•Sprint review•Sprint retrospective•Daily scrum Meeting

Ceremonies

•Product backlog•Sprint backlog•Burndown charts 燃尽图

产出工件

Product backlog需求列表项目中所有希望进行的工作的列表理想的表达出每一项都对项目的用户或客户有价值

由产品负责人排定优先级在每个 sprint开始的时候重新排定优先级

Product backlog 例子

Sprint BacklogSprint Backlog 涵盖了最终版本的既定Proudct Backlog 的任务。团队通过它来协调开发进度

59

管理 Sprint Backlog每个人标记自己选择的工作

—工作不是分派的，而是自己选择的每天更新剩余的估计工作量任何团队成员可以增加，删除，改变 Sprint backlog

如果工作不清晰，定义一个用时更多的 Sprint backlog 条目，以后再分解

当状况变得更明了时，更新剩余工作量

Sprint Backlog 例子

障碍 Backlog(Obstacle Backlog)

在挂纸板上准备一个三栏的表：新事项，正在处理事项，已完成事项。在 Sprint过程中，如果您正在经受其中某个障碍的煎熬：

—把它记录在贴纸上—把它加到障碍 Backlog 的“新事项”栏中

对障碍 Backlog的处理—把所有已知的障碍加入到障碍 Backlog 的“新事项”栏中—按优先级排列“新事项”栏中的障碍问题—每当您开始着手解决一个障碍问题时，将它移至“正在处理事项”栏中

—尽快解决这个障碍—障碍得到解决时，将它移到“已完成”事项栏中—在 Scrum 每日例会和 Sprint 回顾会议中收集新的障碍问题62

10 大典型障碍会议规则没能被遵循

产品远景和 Sprint 目标不清晰

没有产品负责人负责回答提问

产品 Backlog 未能按商业价值区分优先级

并不是所有负责交付产品的人员都是团队里的成员

Scrum Master 还要处理其他任务，不能集中精力

团队人数过多（多于 7 个开发人员）

团队没有能坐在一起工作的空间

团队的 Sprint Backlog 混乱63

场景展示 - 燃尽图

Scrum 伸缩性通常单个团队 7 ± 2 人

—伸缩性来源于由团队组成的团队伸缩因素

—应用类型—团队大小—团队分布—项目周期

Scrum 已经在多个超过 500人的项目中应用

大团队 Scrum ： Scrum-of-scrums 应用场合

—较大的团队，有多个独立项目同时进行如何应用

—将大团队分成若干小于 8 人的小团队，分别做 Scrum

—Scrum Master之间进行 Daily Scrum

—在多个 Scrum Team间引入“团队领导”的角色 ：“首席 Scrum master”

66

更多内容参考硝烟中的 Scrum 和 XP 15 章：我们怎样管理多个 SCRUM 团队

总结： Scrum Cheat Sheet

67

图书推荐

推荐站点www.scrumalliance.org

www.scrum.org

www.controlchaos.com

www.mountaingoatsoftware.com

www.agilesoftwaredevelopment.com

www.crisp.se

www.noop.nl

69

70

让我们一起 Scrum吧！