Scrum
敏捷项目管理
2011
年
2
月
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
敏捷的背景与动机
软件危机及软件工程的出现
速度是企业竞争致胜的关键因素，软件项目的最大挑战在于
一方面要应付变动中的需求
一方面要在紧缩的时程内完成项目
传统的软件工程难以满足这些要求
所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是
Agile Process (
敏捷的软件开发流程
)
于近年来兴起的主要原因。
最为突出的例子是美国
IBM
公司于
1963
年～
1966
年开发的
IBM360
系列机的操作系统。该软件系统花了大约
5 000
人一年的工作量，最多时，有
1000
人投入开发工作，写出近
100
万行的源程序。尽管投入了这么多的人力和物力，得到的结果却极其糟糕。据统计，这个操作系统每次发行的新版本都是从前一版本中找出
1000
个程序错误而修正的结果。
从
1968
年，软件界借鉴其它工程领域的经验提出了软件工程，其中最重要的问题之一是解决软件的生命周期问题，出现了经典的瀑布模型，把每个阶段的规格说明，严格的评审后进入下一阶段等
软件项目的复杂性
横轴代表需求的复杂度
纵轴表示技术的复杂度
还有人力资源的复杂度
解决复杂性问题需要采用经验式方式
解决问题的两种方式：
预定义过程控制（富士康流水线生产）
经验性过程控制（摸着石头过河）
如果复杂度超过预定义方式的能力范围，应该采用经验性方式
经验性方式的三大支柱：可见性、检查及适应
可见性：影响最终结果的因素必须可见，比如说功能是否完成
检查：只有通过检查才能
有中国特色的社会主义，躺着石头过河，白猫黑猫抓到老鼠就是好猫
他山之石
互联网时代的出版模式
作者最开始的时候并没有想出一本书，而只是把多年的积累梳理出来写成了博客，凭借博客的成功最后得到了出版商和纸版读者的认可。在写成本书的过程中，作者是渐进式的进行的，每写完一个章节，放到博客上去征求读者的反馈，很多反馈意见在后面的章节或修订中及时地体现出来，这样就形成了与读者之间的良好反馈，在出版之前就锁定了大量的读者。
这
就是敏捷开发提倡的“增量迭代、及时交付”的思想
。
这种模式能
最大程度地不偏离客户需求的本质。
精益制造
消除浪费、
关注
流程
、
建立无间断流程以快速应变
、
降低库存
、
一次做对
、
基于顾客需求的拉动生产
、
标准化与工作创新
、
尊重员工，给员工授权
等
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
敏捷的
历史
敏捷软件开发又称敏捷开发，
从
1990
年代
开始逐渐引起广泛关注的一些新型软件开发方法，
是一种应对快速变化的需求的一种软件开发能力。
2001
年初，因观察到许多的软件团队身陷不断扩大的流程之中的困境，一群业界专家聚集在一起，勾勒出一些能让软件团队迅速工作，以及响应变化的价值观和原则。他们自称为
Agile Alliance
。
之后的七个月里，他们创造具有价值的声明，也就是敏捷软件的开发宣言。
十五人中包括：大名鼎鼎的
Kent Beck
（
XP,TDD
的创始人
,Junit
的创始人之一）、
Ward Cunningham
（
Wiki
概念的发明者）、
Martin Fowler
（
《
企业应用架构模式
》
作者）、
Robert C. Martin
、
Ken Schwaber
敏捷价值观之敏捷宣言
敏捷开发的核心思想是
：
以人为本，适应变化
。
敏捷价值观之敏捷宣言
-1
个体和交互胜过过程和工具
人是软件项目获得成功最为重要的因素
合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；
这里的交互就是强调了团队的价值，好的团队能够形成一种默契省去很多复杂的交互问题。
也以交响乐团来举例子，指挥要指挥几十名乐手，一个手势就能表达节奏、强弱等等
好的团队，交互起来也是很简单的，复杂的问题可能几句话就交代清楚了
敏捷价值观之敏捷宣言
-2
可以工作的软件胜过面面俱到的文档
过多的面面俱到的文档往往比过少的文档更糟
软件开发的主要和中心活动是创建可以工作的软件
直到迫切需要并且意义重大时，才进行文档编制
编制的内部文档应尽量短小并且主题突出
什么才是必要的文档？这很重要。就像居家过日子花钱一样，再吝啬的人对于他觉得值的东西也会很慷慨。
有些文档你现在觉得不必要，可是未来可能很必要；另外分工的情况决定文档的必要性；项目是否有推广价值
再说说什么是无用的文档？为了应付验收后补的文档，
COPY/PASTE
出来的文档，不提供信息的文档，不一致的文档
关于文档的重要性我有一个亲身经历，广西电费算法文档
敏捷价值观之敏捷宣言
-3
客户合作胜过合同谈判
客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
为开发团队和客户的协同工作方式提供指导的合同才是最好的合同
敏捷价值观之敏捷宣言
-4
响应变化胜过循环计划
变化是软件开发中存在的现实
计划必须有足够的灵活性与可塑性
短期的迭代的计划比中长期计划更有效
Jiangsu Microsoft Technology Center
痛苦也是一天，开心也是一天，我们为什么开心地面对生活
既然变化不可避免，我们何不坦然面对
敏捷开发的
12
个原则
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。
经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个人来构建项目。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
1
、我们最优先要做的是通过尽早的、持续的
交付有价值
的软件来使
客户
满意
规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。
2
、即使到了开发的后期，也
欢迎改变需求
。敏捷过程利用变化来为客户创造竞争优势。
敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。
5.
业务和技术是引起不确定的二个主要方面，人是第三个方面。而业务和技术又必须由人来执行，所以能够激励人来解决这些问题是解决不确定性的关键。只要个人的目标和团队的目标一致，我们就需要
鼓舞起每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。
6
、在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
敏捷开发的
12
个原则
工作的软件是首要的进度度量标准。
敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单化是根本（不做过度设计和预测）。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。
7.
一般的工作都比较容易衡量任务进展，比如让你去搬运
1
吨的石头，我只要去称一下你已经搬运的石头重量就知道你完成多少了。而对于软件来说，在软件没有编码、测试完成之前，我们都不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。
8.
很多人都认为软件开发中加班是很正常的，不加班反而不正常，我对此有点不理解，这个可能是国情所致吧。敏捷过程希望能够可持续的进行开发，开发速度不会随着迭代的任务不同而不同，不欣赏所谓的拼一拼也能完成的态度，开发工作不应该是突击行为。我们不能指望说突击这个项目后就可以轻松了，因为完成一个项目后会接踵而来下一个项目，而只要还是拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说，那我们就一直加班，也是
“
持续的开发速度
”
啊，这时可要注意了，持续加班智慧导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。
9.
敏捷过程有很多好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。
10.
我们不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而把注意力放在如何通过最简单的方法完成现在需要解决的问题。这时有人会说，我已经预计到了肯定存在哪些需求扩展点，我们在一开始是否需要考虑呢？这时团队需要根据自己的理解去决定是否考虑，如果深信在明天发生了这个问题也可以轻易处理的话，那么就最好先不考虑。
11.
在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。要形成一个自组织团队其实比较难。
自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。
在经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。比如，每个人都知道上午九点来上班，都会主动询问别人是否需要帮助，也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。在自组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好的软件的目标。总之，自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。但是，实现这些承诺对于自组织团队来说非常重要。否则，一旦出现问题，团队成员之间就会出现信任危机。
12.
由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。 敏捷不是基于预定义的工作方式，而是基于经验性的方式，对以上这些变化，小组通过不断的反省调整来保持团队的敏捷性。
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
什么是敏捷方法？
敏捷方法是一类软件开发流程的泛称；
敏捷方法是相对于传统的瀑布式软件过程提出的；
敏捷方法可以用敏捷宣言（
4
条）、敏捷原则（
12
条）来概括；
敏捷原则通过一系列的敏捷实践来体现出来；
敏捷方法有很多种。
问题
1
，请举出你知道的
2
个以上敏捷方法名字来
敏捷的方法
Extreme Programming
(XP)
极限编程
Scrum
Adaptive Software Development
(ASD)
自适应软件开发
Crystal Clear
and Other Crystal Methodologies
水晶方法
Dynamic Systems Development Method
(DSDM)
动态系统开发方法
等
XP
侧重于技术实现层面，主要关注用户故事、结对编程、测试驱动、持续集成、
敏捷方法
VS.
瀑布模型
瀑布模型
固定的、没有弹性的。
很困难去达到互动。
假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的
model
是比较不适合的。
敏捷方法
完整地开发，每少数几周或是少数几个月里可以测试功能。
强调在获得最简短的可执行功能的部分，能够及早给予企业价值。
在整个项目的生命周期里，可以持续的改善、增加未来的功能。
敏捷项目管理
VS
传统项目管理
传统项目管理：
事先对整个项目进行估计、计划、分析
反对变更
;
变更需要重新估计、重新规划
严密的合同来减少风险
,
如果改变需求要走
CR
流程
.
项目作为一个“黑盒子” ，对客户与供应商的可视性差
.
文档和计划驱动的方法
.
软件交付时间晚
,
意识到风险的时间晚
.
WBS,
甘特图
,
关键路径分析
敏捷项目管理
:
对整个项目做一个粗略的估计
,
每一次迭代都有详细的计划
.
鼓励变化
,
客户价值驱动开发
.
信任和赋予权力
;
合约使变更变得简单，增加价值
.
客户和开发人员之间是紧密的连续的合作关系
每次迭代都产生可交付的软件
专注于交付软件
.
第一次迭代就可交付能工作的版本，风险发现的早
.
甘特图和关键路径分析对于复杂的多个分支的项目特别适合，比如说软硬结合的产品研发，比如说房地产开发
敏捷 与
CMMI
双剑合璧
CMMI
更加关注于流程，敏捷更加关注于人
CMMI
自顶向下，敏捷自底向上
敏捷并不排斥必要的文档
敏捷的很多实践是对
CMMI
的一种实现，比如
sprint
计划会议就是
PP
的实现，每日例会就是在做
PMC
很多
CMMI4~5
级的公司也在应用敏捷，比如说宝信、华为
项目级的敏捷实践通过
CMMI
可以在组织级得以重用
从
2007
年开始我对
CMMI
和敏捷的认识经历了这样的阶段，
CMMI,
敏捷，
CMMI
和敏捷融合
eXtreme Programming
XP
我们一般称为极限编程，是最轻量级的开发流程。
最主要的精神是
『
在客户有系统需求时，给予及时满意的可执行程序
』
，所以最适合需求快速变动的项目。
它强调客户所要的是
workable
的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以
side-by-side
的方式一起工作。
XP
的实践包括：
完整团队、计划游戏、客户测试
简单设计、结对编程、测试驱动开发
改进设计、持续集成、集体代码所有权
编码标准、隐喻、可持续的速度
主要关注的是技术实现
Scrum
开发流程
Jiangsu Microsoft Technology Center
为什么采用敏捷
? –
预期的收益
采用敏捷方法得当的话，可以：
更加透明
;
随时跟踪项目的状态和进展情况，及早发现问题和风险
.
快速交付
,
每次迭代都能交付可运行的软件
.
最高风险和最高优先级的需求，最优先进行开发
.
改善应对变更能力
,
减少大量的重计划
.
改善项目沟通
.
更好的客户参与
,
避免错误的假设
.
总之
:
提高了生产率
;
减少“浪费” （不需要的文档，重复工作等） ，项目的每次迭代都有明确的目标
.
提高客户满意度
;
短期内产生成效
,
按预期交付软件
,
每次迭代结束产生可以运行的软件
.
改善员工的满意度
;
团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）
.
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
敏捷关键实践
1——
增量迭代
每个迭代有一个大约为
1
～
4
周的时间框，在
SCRUM
里称为一次冲刺（超过
1
个月的详细计划往往偏差很大）
每次迭代都应该有明确的目标
每次迭代都应该有明确的可演示的工作成果
迭代过程中项目团队应该尽量免受打扰
迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解
敏捷关键实践
2——
测试驱动开发
TDD
什么是测试驱动？
首先创建测试用例，然后开发软件通过测试
(
在开发代码前，首先编写测试代码
)
一种设计软件的方法，而不仅仅是一种测试方法
所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护
不需要测试的工作不需要完成
所创建的测试用例通常替代详细的业务和技术需求定
测试也有效地驱动设计，使设计更加趋向于可行的设计
通常情况下需要自动测试的支持
(EUnit, JUnit etc.).
对于
UI
软件应用
TDD
方法有一定的困难
敏捷关键实践
3——
持续集成
极限编程称为“每日构建”
持续集成一般利用
ANT
、
MAVEN
等工具
日构建的好处：
将集成风险降到最低
降低质量风险
提升士气
日构建可以看做是项目的心跳，冒烟测试就像是听诊器
日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试
敏捷关键实践
4——
面对面交流
虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的；
敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会；
尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。
匿名共享需求文档只会打开曲解和误解之门，更不用说书面信息比口头交流还要慢很多。
敏捷方法的其它实践
结对编程
每日立会
用户故事
团队工作室
频繁发布
自组织团队
重构
用户故事是一种表示需求的轻量级技术，它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板：
“
作为【用户的类型】，我希望可以【能力】以便【业务价值】
“
。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口头交流。
重构
——
改善既有代码的设计
Martin Fowler
提出
代码的坏味道
Martin Fowler
和
Kent Beck
列举了
22
种坏味道：冗余代码、冗长的方法、巨大的类、过多的参数等等
重构可以弥补设计的不足
简单设计的思想
重构与测试驱动的关系
TDD
是重构的脚手架
IDE
已经对主要的重构模式提供了自动化支持：
Rename, extract method, move field
等等
简单设计
>>
测试用例
>>
实现再说
>>
（重构
>>
回归测试）
*
收拾家的隐喻
Scrum
何时更有效？
公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法
.
敏捷方法对需求不完整以及经常变换的项目比较有效
.
项目可以划分成固定时间间隔的迭代
,
并且可以冻结正在进行的迭代的范围
公司和客户都有能力担当角色尤其是
Product Owner
和
Scrum Master.
项目的人员结构能够分成
6
到
10
人的团队，最好每个工作地点一个小组
.
（
Scrum of Scrums
，
Scrum
的扩展）
团队成员能够以自组织的方式工作
.
项目的合同允许变更
.
固定价格的项目可以使用敏捷，但应当尽量避免。
最好在按时间和材料付费或者按月付费的项目中进行使用、
变更项目的范围不需要高级管理层的批准
.
问题
2
，为什么
SCRUM
团队人员最好在
10
人以内？
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
敏捷特别强调人的因素
相对于过程与工具，敏捷更强调“人”的因素。
诚信是基础
没有过程能够对诚信进行有效的约束
诚信与否是有效实施敏捷过程的最大限制
Scrum
框架
www.
海颐软件
Scrum
角色
Scrum
角色之
Product Owner
产品负责人（
Product Owner
）的职责如下：
确定产品的功能。
决定发布的日期和发布内容。
为产品的
profitability of the product (ROI)
负责。
根据市场价值确定功能优先级。
每个
Sprint
，根据需要调整功能和优先级（每个
Sprint
开始前调整）。
接受或拒绝接受开发团队的工作成果。
Scrum
角色之
ScrumMaster
作为
Team Leader
和
Product owner
紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须
:
保证团队资源完全可被利用并且全部是高产出的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织
Daily Scrum, Sprint Review and Sprint Planning meetings
。
Scrum
角色之
Scrum Team
一般情况人数在
5-9
个左右
团队要跨职能
（包括开发人员、测试人员、用户界面设计师等）
团队成员需要全职。
（有些情况例外，比如数据库管理员）
在项目向导范围内有权利做任何事情已确保达到
Sprint
的目标。
高度的自我组织能力。
向
Product Owner
演示产品功能。
团队成员构成在
sprint
内不允许变化。
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
Scrum
流程
Sprint Planning Meeting:
Next Sprint Goal
Sprint Backlog
Updated Product Backlog
Daily Scrum meetings :
What did you do yesterday
What will you do today?
What obstacles are in your way?
Source:
Daily Scrum
Sprint
Retrospective
Shippable
Product Increment
Backlog,
待办任务
Sprints(
冲刺
)
Scrum
的项目过程有一系列的
Sprint
组成。
Sprint
的长度一般控制在
2-4
周。
通过固定的周期保持良好的节奏。
产品的设计、开发、测试都在
Sprint
期间完成。
Sprint
结束时交付可以工作的软件。
在
Sprint
过程中不允许发生变更。
Scrum
框架
Scrum
仪式之
Sprint
计划会议
Jiangsu Microsoft Technology Center
Scrum
仪式之
Sprint
计划会议
Jiangsu Microsoft Technology Center
Scrum
仪式之每日
Scrum
会议
(Daily Scrum)
每日
Scrum
会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行。
最好是每天早晨开，一般
15
分钟左右，时间比较短，也有利于团队成员安排好当天的工作。
只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。（小猪和小鸡的故事）
每日
Scrum
会议由
Scrum Master
主持，
Scrum
团队所有成员轮流回答以下
3
个问题：
昨天我完成了什么工作？
今天我打算做什么？
我在工作中遇到了什么困难？
Jiangsu Microsoft Technology Center
Scrum
任务板
(Task Board)
Jiangsu Microsoft Technology Center
任务板（墙）展现了在
Sprint
过程中所有要完成的任务。在
Sprint
过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子
:
Scrum
仪式之
Sprint
评审会议
Sprint
评审会用来演示在这个
Sprint
中开发的产品功能给
Product Owner. Product Owner
会组织这阶段的会议并且邀请相关的干系人参加。
团队展示
Sprint
中完成的功能
一般是通过现场演示的方式展现功能和架构
不要太正式
不需要
PPT
一般控制在
2
个小时
团队成员都要参加
可以邀请所有人参加
Jiangsu Microsoft Technology Center
Scrum
仪式之
Sprint
回顾会议
Jiangsu Microsoft Technology Center
团队的定期自我检视，发现什么是好的，什么是不好的。
一般控制在
15-30
分钟
每个
Sprint
都要做
全体参加
Scrum Master
产品负责人
团队
可能的客户或其它干系人
Sprint
回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。
Scrum
物件之产品订单
(Product Backlog)
一个需求的列表。
一般情况使用用户故事来表示
backlog
条目
理想情况每个需求项都对产品的客户或用户有价值
Backlog
条目按照商业价值排列优先级
优先级由产品负责人来排列
在每个
Sprint
结束的时候要更新优先级的排列
Jiangsu Microsoft Technology Center
Scrum
物件之产品订单
(Product Backlog)
Jiangsu Microsoft Technology Center
Scrum
物件之冲刺订单
(Sprint Backlog)
Jiangsu Microsoft Technology Center
Sprint Backlog
示例
Persons
working on
the task
Description of
the task
Effort
estimate
Task blocked
by an impediment
Sprint goal
Meets the
definition of done
Scrum
物件之冲刺订单
(Sprint Backlog)
管理
Sprint
的
backlog:
团队成员自己挑选任务，而不是指派任务
对每一个任务，每天要更新剩余的工作量估算
每个团队成员都可以修改
Sprint backlog
，增加、删除或者修改任务
Jiangsu Microsoft Technology Center
Scrum
物件之燃尽图
(Burn Down Chart)
Ideal burndown.
Actual burndown.
Remaining work
increasing
Tasks
underestimated
and/or work remaining
not updated.
Tasks removed from the
Sprint Backlog to meet
Sprint Goal
faster decline
.
Sum of remaining work [h] for all tasks in the
Sprint Backlog on a particular day.
Initial estimate (752 h)
In the beginning of the
Sprint
扩展
Scrum
一般情况一个团队的人数控制在
5-9
人
大型项目可以采用多团队，通过
team of teams
来扩展
Scrum
。
影响扩展的因素
团队规模
项目类型
项目周期
团队分布
Scrum
曾被用于超过
1000
人团队规模的项目。
Jiangsu Microsoft Technology Center
Scrum Of Scrums
Jiangsu Microsoft Technology Center
Scrum
项目之估计
Scrum
团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位
Story Points (
模糊的
).
也可采用人天或者人小时作为单位，但容易混淆：
a)
实际的规模
b)
时间的单位
.
精确的估计值可以在
Sprint
规划时给出
,
当前阶段没有足够的信息
.
规模的相对值才有意义
.
这个估计值有助于确定优先级
;
可以采用估算扑克
所需时间
团队速度
产品规模
完成的定义
当迭代任务清单上的任务都完成时，变为“已完成”状态
定义“已完成”的含义是非常重要的
,
例如
:
如何记录软件的变化
.
使用什么样的代码分析工具
，发现的问题应当如何处理
.
进行了什么样的测试
,
结果是如何记录的
,
通过标准（如覆盖率、修正的错误）是什么
.
定义“已完成”意味着定义质量上的需求
.
“
已完成”是
0/1
变量：完成或者未完成
.
所有的任务（
task)
都完成了迭代任务才算完成
.
在第一个迭代开始之前应该定义好，因为它会影响工作量
,
而且必须文档化，这样团队和产品所有者的理解是一致的
.
完成的定义
- Example
完成的定义
遵循编码规范
能在模拟器上演示
使用
PCLint
进行静态代码分析
具有
EUnit
测试套件的通过率 和执行率
.
或者使用结对编程，或者进行代码走查
障碍
基本上，任何阻止团队正常工作的，都可称之为障碍，例如
:
无法访问信息系统
.
所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确
开发环境或者原型系统出现问题
其他的任务分配：培训，售前支持
缺乏必要的信息或者相应的知识
对于团队提出的各项障碍，
Scrum Master
要以列表形式进行记录，
谁来清除障碍？
每个人
自我管理、自我组织的团队
Scrum Master
产品所有者
管理层
其他相关的干系人
Scrum Master
负责确定障碍已经清除，不一定亲自自己清除
清除障碍
某些障碍是浪费
部分地完成工作
额外的过程
额外的功能
任务转换
等待
缺陷
清除障碍的过程是团队和组织学习的过程
浪费产生的原因
多问几个“为什么”
对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在
多问几个“为什么”，找到造成浪费的根本原因
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
SCRUM
实践
研发部
2009
年开始在几个项目当中进行了
SCRUM
项目管理的尝试：
营销综合停电系统开发
FLEX-ADP
开发
海颐
OA
项目
等
www.
海颐软件
SCRUM
看板
www.
海颐软件
SCRUM
燃尽图
www.
海颐软件
SCRUM
带来的改善
项目的计划性更强了，将项目按
SPRINT
进行分解，每个
SPRINT
要进行计划和总结，每天也有立会来进行简短的总结和计划；
引入
SCRUM
以后，项目团队的沟通比以往更有效，项目看板为项目团队沟通提供了一个统一的项目视图，每日立会是项目团队沟通的有效通道；
项目的阶段性比以前更明确，通过
SPRINT
将项目划分成阶段，通过
SPRINT
演示等活动将项目整体的压力分解到每个
SPRINT
，这样可以有效降低项目的整体风险。
www.
海颐软件
目录
敏捷的背景与动机
敏捷宣言及原则
敏捷方法是什么？
敏捷方法的实践
Scrum
的角色
Scrum
流程和工作产品
Scrum
应用
总结
一些常见的误解
敏捷是拯救任何项目的银弹
.
敏捷方法只有运用得当才有效果
.
敏捷意味着
ad-hoc hacking
，不需要任何文档
.
敏捷是有严格要求的，也是面向质量的
根据沟通的需要产生相应的文档
.
敏捷只是开发者的问题
基本的开发方法与传统相比有显著不同
,
影响项目的各个方面
:
合同
,
角色
,
定价模型
,
项目管理等
.
采用敏捷方法的开发组
/
项目不需要制定计划
敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的
.
敏捷项目的范围可以随时改变
.
变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更
只对小项目适用
在中型和大型的项目中一样取得了成功
解决了部分问题，同时产生了新的问题
总结
Agile Software Development
是软件开发所强调的一个精神，而不是一个方法。
遵循
Agile Alliance
所提的四个价值观与
12
个原则。
最常见的开发方式
XP
SCRUM
敏捷开发过程是一个艰苦的过程，重在实践
即使非敏捷的项目中也可以应用敏捷的实践经验
CMMI
应该与敏捷实现融合，双剑合璧
问题
3
，在
SCRUM
中能够直观展现冲刺的进度的图形是什么图？
延伸学习
原书名：
Agile Project Management with Scrum
原出版社：
Microsoft Press
作者：
(
美
)Ken Schwaber
[
作译者介绍
]
译者：
李国彪
丛书名：
微软技术丛书
出版社：清华大学出版社
ISBN
：
9787302164036
硝烟中的
Scrum
和
XP——
我们如何实施
Scrum
原书名：
Scrum and XP from the Trenches
原出版社：
作者：
(
瑞典
)Henrik Kniberg
译者：
李剑
出版社：清华大学出版社
ISBN
：
9787302243335
上架时间：
2011-1-17
出版日期：
2011
年
1
月
www.
海颐软件
Thank You !
