软件工程概述----- Scrum敏捷开发

Scrum敏捷开发

• Scrum是一种迭代式增量软件开发过程，通常用于
敏捷软件开发。Scrum在英语的意思是橄榄球里的
争球。

角色

• Scrum Team
• 产品负责人（ Product Owner）
• 利益相关者
• Scrum主管（Scrum Master）
• 软件架构师
• 开发团队（Team）

谁是“猪”

当前参加项目的成员们

• 他们有可能可能是开发人员，可能是美工或者产品经理。正是他
们组成了整个团队的核心。

SCRUM MASTER

• SCRUM MASTER可能是这个团队的成员，也有可能不是。将这
个角色挑出来讨论一下是非常重要的，因为这个承担这个角色的
人在SCRUM MEETING的过程中要起到非常重要的作用，他需要
负责让整个SCRUM MEETING 不受影响的并且能够高效的进行。

项目所有人

• 项目所有人可能是产品经理，可能是参与整个项目中的某一个成
员,也可能不是。同样的，我们将这个角色从项目中挑选出来也是
非常重要的，因为这个人代表了最终用户的声音。
小故事

谁是“鸡”？

职能经理

• 第一眼看上去，你可能会很自然的认为那些经理们是属于“猪”
的这个分类的，但是实际上，在一个Scrum会议当中，这些职能
经理们通常更加关心有哪些人参加了这个项目，以及参加这些项
目的个人情况。他们往往没有将注意力聚焦到项目本身上，即便
是有一些意见或者想法，也可能是受到某些特定用户的目标导向
，他们并不能真正的全身心投身于这个项目当中。基于上述原因
，在SCRUM MEETING中，我们将其归为“鸡”这一类。

利益相关者

• 利益相关者是会从这个项目中获益，或者是这个项目最终成果的
既得利益者。但是，请不要想当然的认为他们就有影响项目方向
或者是最终产品的权利。这些利益相关者可以提供意见或者是对
未来的建议，但是决定最终产品开发过程的最终权利在产品所有
者的手中。

工件

产品订单（ Product Backlog）

– 按照优先级排序的高层需求。

冲刺订单 （Sprint Backlog）

– 要在冲刺中完成的任务的清单。

燃尽图 （Burndown Chart）

– 在冲刺长度上显示所有剩余工作时间逐日递减的图，因整
体上总是递减而得名。

活动

计划会 （Sprint Planning Meeting）

– 在每个冲刺之初，由产品负责人讲解需求，并由开发团队
进行估算的计划会议。

每日立会（ Daily Standup Meeting）

– 团队每天进行沟通的内部短会，因一般只有15分钟且站立
进行而得名。

评审会（ Review Meeting）

– 在冲刺结束前给产品负责人演示并接受评价的会议。

反思会/回顾会 （Retrospective Meeting）

– 在冲刺结束后召开的关于自我持续改进的会议。

冲刺

– 一个时间周期（通常在2周到1个月之间），开发团队会
在此期间内完成所承诺的一组订单项的开发。

产品需求

产品需求——Sprint Backlog

Sprint 会议

Sprint计划会议 (Planning meeting)

» 工作量估算
» 故事切分
» 定义出口准则 (DODs)

每日会议 （Daily meeting）

» 站立会议
» Scrum of Scrum
» 图标（Dashboard）
» 3 句话

梳理会议 （Grooming meeting）

» 讨论优化下个Sprint需要完成的故事

Sprint评审会议（Review meeting）

» 统一的评审报告
» 预演 Rehearsal
» 示范 Demonstration

冲刺回顾会议 (Retrospective meeting)

» 做得好的
» 需要提高的

Sprint 计划会议

• 计划会议要有足够的时间，最好至少8个小时
• 取出部分产品需求做成sprint需求，并写成索引卡
• 确定并细分每一个索引卡的故事（Story）
• 进行工作认领（不是分配）
• 确定每日站立会议的时间和地点
• 确定好演示会议和回顾会议的日期

站立会议

• 10-15分钟
• 迟到将接受惩罚
• 自问自答三个问题
– 昨天做了什么
– 今天要做什么
– 遇到了什么问题
• 更新燃尽图

场景展示 - 每日站立会议

燃尽图（理想）

燃尽图（实际）

演示会议

• 演示是跨团队的，会产生不同团队之间的交流
• 不要关注太多的细节，以主要的功能为主
• 让老板和客户看到
• 非常的重要，绝对不可以被忽略

回顾会议

• 举行冲刺回顾会议是为了进行持续过程改进。会议
的时间限制在4小时。
– 时间在1-3个小时
– 找最舒适的地方（要有回顾看板）
– 开始的时候轮流发言，而不是主动发言
– 记录问题，总结，并讨论改进的方法，放在回顾看板上
– 每人三个磁铁，将最重要的2-3个改进点，成为下一轮的产品需求

极限编程(XP)和 Scrum区别

区别之一： 迭代长度的不同

– XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭
代长度一般为 2~ 4周。

区别之二: 在迭代中, 是否允许修改需求

– XP在一个迭代中，如果一个User Story(用户素材, 也就是
一个需求)还没有实现， 则可以考虑用另外的需求将其替
换， 替换的原则是需求实现的时间量是相等的。而Scrum
是不允许这样做的，一旦迭代开工会完毕, 任何需求都不
允许添加进来，并有Scrum Master严格把关，不允许开
发团队受到干扰。

区别之三: 在迭代中，User Story是否严格按照优先

级别来实现
– XP是务必要遵守优先级别的。但Scrum在这点做得很灵活
，可以不按照优先级别来做，Scrum这样处理的理由是：
如果优先问题的解决者，由于其它事情耽搁，不能认领任
务，那么整个进度就耽误了。另外一个原因是，如果按优
先级排序的User Story #6和#10，虽然#6优先级高，但
是如果#6的实现要依赖于#10，则不得不优先做#10。

区别之四:软件的实施过程中，是否采用严格的工程

方法，保证进度或者质量
– Scrum没有对软件的整个实施过程开出工程实践的处方，
要求开发者自觉保证。但XP对整个流程方法定义非常严格
，规定需要采用TDD、自动测试、结对编程、简单设计、
重构等约束团队的行为。

建议

使用好任务看板

需求，设计，开发，测试，维护

注意燃尽图

不要使用软件取代看板

可以选择性的和XP的某些方式结合

测试驱动开发

结对编程

建议——结对编程

建议——持续集成

Scrum的主要缺陷：

– 压力大
– 不方便跨时区，跨语言
– 程序维护成本偏高
– 无法被中断

如何改善：

– 结合XP：
• 和客户坐在一起
• 结对编程
• 测试驱动开发（TDD）
• 使用编码规范
– 32小时工作制