敏捷开发之Scrum在线视频

Scrum是目前最流行

也是最有效的一种敏捷项目

管理方法

已经被许多知名的软件企业

所采用

这个英文单词的意思

是橄榄球运动的一个专业术语

表示争球的动作

用在软件开发上

它象征着开发团队

在开发软件的时候

所有的人都像打橄榄球一样迅速

而富有战斗激情

你争我抢 完成任务

并且通过逐步逼近的方式

取得最后的胜利

在Scrum框架中

整个开发过程是由若干个

很短的迭代周期所组成

一个短的迭代周期

称为一个Sprint

Scrum是通过以下过程

来实现产品的迭代开发

首先产品经理

根据用户需求和市场需要

提出一个按照商业价值

进行排序的客户需求列表

在每一个迭代的开始

开发团队要召开迭代计划会议

从这个列表中

挑选出一些优先级最高的条目

形成迭代的任务

在迭代开发过程中

要进行每日站立会议

检查每天的进展情况

在迭代结束的时候

就会产生一个可运行的交付版本

由项目的相关人员

参加产品的演示和回顾会议

来决定这个版本

是否达到了发布的要求

一个Sprint是指一个

1到4周的迭代

现在很多的团队采用2周

作为一次迭代

像一些市场变化快

竞争激烈的领域

比如说互联网或移动互联网领域

有可能使用一周的迭代

Sprint在整个开发过程中

是保持固定的时间长度

结束的时候

会产生一个完成的

可运行的潜在可发布的产品增量

在一个迭代的执行过程中

它的实现目标 质量和验收标准

都是不允许变化的

除非迭代的目标

失去了价值和意义

比如说 公司的发展方向

或者市场技术等情况发生了变化

这个时候就应该取消迭代

不过由于迭代的周期非常短

这种情况一般也很少发生

Scrum框架包括三个部分

开发团队角色

开发制品和开发活动

首先来看开发团队角色

主要包括产品负责人

Scrum主管和团队成员三种类型

产品负责人代表客户

决定产品的需求和优先级

它是开发团队

对于需求的唯一诉求人

产品负责人的主要职责包括

确定产品的功能

负责维护产品的需求列表

决定产品的发布日期和发布内容

为产品的投资回报负责

要根据市场价值

确定需求的优先级

在每个迭代开始前

调整功能和功能优先级

在迭代结束的时候

要验收开发团队的工作成果

Scrum主管作为团队领导

与产品负责人密切合作

及时为团队成员提供帮助

使得团队免予外界的干扰

它的主要职责是直接管理项目

要知道什么任务已经完成

哪些任务已经开始

哪些新的任务被发现

以及哪些估算可能已经发生变化

要保证开发过程按照计划进行

组织每日站立会议

迭代计划会议 迭代评审会议

和迭代回顾会议

要引导团队正确地应用敏捷实践

保证团队资源完全使用

和高效运作

要促进团队成员之间的良好合作

解决团队开发中的障碍

作为团队和外部的接口

屏蔽外界对团队成员的干扰

Scrum团队

负责在每个迭代中

把产品需求转化为潜在的

可交付的功能增量

它的特点是

团队的规模控制在5到9人

如果小于5人

团队的生产力会下降

有可能会受到技能的限制

从而导致无法交付

可发布的产品模块

如果成员多于9人

那么成员之间

就需要太多的协调和沟通

对于大型项目来说

可以采用多个小的Scrum团队

每个团队派出代表

进行团队之间的协调和沟通

团队是跨职能的

团队成员必须具备交付产品增量

所需要的各种技能

比如说编程 质量控制 业务分析

架构 用户界面设计

或数据库设计等

在Scrum团队中

没有头衔的概念

每一个人

都必须尽心尽力完成迭代目标

团队成员要全职工作

而且是自我组织和管理的

成员之间协调配合

提高整个开发效率

最终保证每一个迭代的成功

自组织团队

是敏捷软件开发的基本观念

它是指团队被授权自己管理

他们的工作过程和进度

并且由团队决定如何完成工作

具体说来

就是团队自己进行任务分配

自己做技术决策

在确保目标的前提下

制定自己的行为准则

团队要有义务保持过程的透明性

要监督和管理自己的过程和进度

Scrum制品主要包括产品订单

也称产品待办事项

迭代订单和燃尽图

产品订单

是一个从客户价值角度理解的

有优先级顺序的产品功能列表

产品订单中

包含开发和交付成功产品

所需要的所有条件和因素

产品订单的条目

可以是功能需求

也可以是非功能需求

还可以是主要的技术改进目标

比如说 用java代替C++重写系统

以及已知的缺陷

比如说 分析并修复

订单处理脚本的错误等等

迭代订单是团队承诺的

在当前迭代要完成的任务列表

这些任务是通过选取产品订单项

并进一步细化和分解形成的

其目的是将产品订单项

转化为潜在的可交付的产品增量

对于简单情况

可以直接把订单项作为任务分配

在复杂情况下

就需要进一步把订单项

分解成一系列

更细致的开发任务

如何选择产品订单项

取决于它的优先级

以及开发团队

完成开发所需要花费的时间

选择哪些订单项

以及多少项是由开发团队

自己来决定

可工作产品

是迭代开发的产出结果

它是一个可以交付的产品增量

可交付的标准是在迭代初期

提前设定的

每一次迭代都应该是一个

可运行的版本

产品负责人

负责产品订单的内容 可用性

和优先级

产品订单永远都不会是完整的

最初它只是列出一些最基本的

和非常明确的需求

这些需求

至少要足够一个迭代的开发

随着开发团队

对产品和用户的了解

产品订单在不断演进

所以产品订单是动态的

它经常发生变化

以保证产品更加合理

更具有竞争性和更有用

产品订单条目

是按照优先级进行排序

优先级主要是由商业价值

风险和必要性来决定

优先级高的条目

需要优先进行开发

优先级越高 条目就越详细

越低就越概括

使用用户故事

来描述产品订单条目

是一个非常有效的实践

用户故事是从用户的角度

来描述他所期望得到的功能

这个表列出了一些

关于网上订购商品的用户故事

这些故事描述了作为顾客

注册 搜索 浏览和购买商品的

一系列功能

以及作为工作人员维护商品信息

和查看订单的功能

对于迭代过程中

所有要完成的任务

可以使用任务板直观地进行展现

在迭代开发中

任务板是在不断地更新的

如果某个开发人员

想到了一个任务

他就可以把这个任务写下来

放在任务板上

在每日站立会议期间或者之后

如果估计发生了变化

任务会根据变化

在任务板上进行相应的调整

任务板有电子和实物两种形式

对于远程开发团队来说

电子版是一个有效的方式

对于集中在一起

面对面工作的团队来说

实物板更利于沟通

燃尽图是以图形方式

显示迭代过程中

累计剩余的工作量

它是一个反映工作量

完成状况的趋势图

其中Y轴代表的是剩余工作量

X轴代表的是迭代的工作日

在迭代开始的时候

开发团队会标识和估计

这一个迭代需要完成的详细任务

所有这一个迭代中需要完成

但是没有完成的任务工作量

是累计的工作量

Scrum主管

会根据进展的情况

每天更新累计工作量

如果在迭代结束时

累计工作量降低到0

迭代就成功地结束

现在图上显示了三条曲线

绿色线 代表这个团队计划良好

所有的故事都已经完成

接近理想情况

紫色的线表明该团队

也完成了目标

但是有可能没有主动地

去更新数字

也有可能是前期有点拖延

后期比较赶工

蓝色线表明该团队执行不太理想

在迭代时间截止时

并没有完成所有任务

Scrum是通过以下活动

来管理整个项目开发过程的

迭代计划会议

是计划即将开始的迭代开发

每日站立会议

用来检查迭代过程的工作进展

迭代评审会议

用来检验所发布的工作成果

迭代回顾会议是回顾和总结

已经完成的迭代过程

Scrum项目包括两级规划

一个是发布规划

它对整个产品发布过程进行展望

定义用户故事

并进行优先级划分

估算开发的规模

以及评估开发团队的速度

制定出整个产品的发布计划

另一个是迭代规划

只对一次迭代进行展望

确定迭代的目标

并且选择用户故事

把故事分解和细化成任务

并进行时间估算

迭代计划会议

是在每次迭代开始时召开

它的目的

是选择和估算本次迭代的工作项

整个会议分成两个部分

第一部分

是以需求分析为主

确定到底要做什么

也就是从产品订单中

选择和排序本次迭代

需要实现的订单条目

第二部分

是以设计为主

确定要怎么做

由开发团队决定系统的设计方案

和工作内容

迭代计划会议需要整个团队参加

产品负责人逐条讲解

最重要的产品功能

开发团队共同来估算

故事所需要的工作量

直到本次迭代的工作量

达到饱和为止

产品负责人参与讨论

并回答与需求相关的问题

但是并不干涉估算的结果

在迭代开发过程中

开发团队通过每日站立会议

来确认他们的工作进展情况

评估是否可以实现迭代的目标

这个会议每天在同样的时间

和同样的地点召开

每个团队成员

都需要回答三个问题

上次例会之后完成了什么

遇到了什么困难

下次例会之前计划要做什么

每日站立会议中

可能有简要的问题澄清和回答

但是不应该有任何话题的讨论

讨论可以下去单独进行

这个会议并不是向任何人做汇报

而是开发团队

内部的一个沟通会议

来帮助大家快速地发现问题

促进团队的自组织和自管理

每日站立会议要求简短

通常不超过15分钟

迭代评审会议

是在迭代结束的时候召开

开发团队和相关人员

一起来评审迭代产出的结果

一般情况下

开发团队会演示产品的增量

让用户代表

尝试使用这些新功能

来听取用户

对产品功能的一个反馈

整个小组也会讨论

他们在迭代中观察到了什么

有哪些新的产品想法

产品负责人会对未来

做出一个最终的决定

并适当地调整产品订单条目

在每次迭代完成之后

还要举行一个迭代总结会

会上所有团队成员

都要反思这个迭代过程

要识别出哪些做得好

哪些做得不好

找出潜在的可以改进的事项

为将来的改进制定计划

需要注意的是

要抓重点问题

每次也就是1-3个关键问题

做出可行的解决方案

这里可行的含义

是方法简单 影响范围小 见效快

再一个目标不要太激进

要现实可行 积少成多

好 Scum方法的主要内容

就介绍到这里

对于参加课程实验项目的团队

希望能够尝试着使用这种方法

来管理自己的项目

体会和掌握敏捷开发管理方法