SCRUM敏捷开发方法在线视频

嗨，大家好

今天继续讨论敏捷开发方法

在这次课程当中，我们会讨论两个典型的敏捷方法

一个是scrum，一个是xp

首先来看一看scrum

这个词来源于一个橄榄球比赛的术语

中文的意思相当于抢球

像橄榄球运动员一样玩命的抢球

它体现的是一种富有战斗激情

你争我抢这样的一个劲头

这个词很形象的表达出了

软件开发人员作为一个团队

来完成一个共同的目标所富有的精神

下面从这三个方面来展开了解

第一，了解scrum的开发模型

然后了解在这种模型当中

它的典型的三个角色

最后讨论scrum当中比较流行的三个实践活动

首先来看一看scrum的开发模型

我们看左侧，左侧是产品的一个backlog

它对应的是用户的需求

只不过这个需求是经过整理的

具体的表现在它有优先级

这个优先级非常重要

它表明了这个需求的功能

它是紧急还是可以往后延续

对于一个排好优先级的这样一堆的需求列表

开发团队拿出一片来

然后通过一个会议

对它进行分解，然后估算完成时间

把它进一步分拆成更小的任务

叫sprint backlog

然后开发团队当中的成员来领取

倾向于主动认领这个backlog

每个backlog可能在几天内完成

经过2到4周的一个迭代

这个sprint backlog就完成了

这就是一个可运行的增量的一次迭代

在这个2-4周的开发过程当中

其中有一个典型的动作叫daily scrum

实际上就是每天早上有一个站立会议

后面详细讨论这个站立会议是如何进行的

每天在一起讨论，讨论完了之后

要更新，这里实际上还有一个更新看板

就是每个人的任务列表

可以这么来理解

大家觉得这个开发模型其实非常简单

在这个模型当中有特别重要的三个角色

第一个角色叫product owner

使所谓的产品负责人

这个产品负责人可以认为是

scrum团队和客户之间的一个接口

有的时候，我们说产品经理

在scrum这种敏捷开发方法当中有一个定位

叫做product owner

他的职责与企业文化，与竞争对手

与个人能力这些因素密切相关

这里列出了一部分产品负责人这个角色所对应的职责

但这个职责它是变化的

比如第一个，建立愿景

让团队成员具有向上的共同的目标

就是说他能忽悠，他能够把团队的战斗力鼓动起来

通俗地讲就是这个意思

确定功能，确定客户的需求

确定用户的业务目标等等

然后他定义需求，来维护这个backlog

在实际的工作过程当中

这个backlog是谁创建的，是谁维护的

不一定由product owner来做

他有可能委托给团队成员当中的某一个人

也就是说，在具体的工作当中

所有的这些职责都可以独立的

或者是协同的来完成

其中有一点还要注意的就是

由product owner来确定产品的交付日期

他要为此负责

第二个角色叫scrum master

这是一个大师级的人物

普遍的认为这个master一定是一个

管理方面的好手

或者是一个技术方面的强人

这里强调的是scrum这种敏捷方法

强调的是自组织，自管理

所以这个master是一个促进者

不再是传统软件开发过程当中的管理者

或者说命令式的管理者

他的职责也是可变的

这里列出了一部分

scrum这个流程还是比较简单的

但不同的公司，不同的开发人员

不同的团队，他在执行的时候

就会出现一些偏差

能不能不要流于形式

从本质上把握scrum的精神实质

这是master重点要做的

另外他可以确保团队的沟通舒畅高效

来维护开发环境不受外界干扰等等

第三个角色就是开发团队了

开发团队他们的职责是

负责这种产品在scrum的流程下

能够正常的进行

在指定的时间内完成一个高质量的产品

它的人数一般是5-10人，7-9人都可以

每个成员可能负责不同的技术

但更多的呢，我们推荐每个成员

认为自己能做什么，自己喜欢做什么

然后来主动进行自我管理

我们要强调在这种敏捷方法中

开发成员要具备一定的表达能力

这不是传统模式的那种命令式的管理

让你干什么你就干什么

要发挥成员的积极性和主动性

这种表达能力的培养就变得至关重要了

对成员的约束很少

可以采用任何工作方式

只要能达到目标就可以

这是比较灵活和高效的地方

下面一块来了解scrum的几种典型实践

这些实践在其他的开发团队当中

甚至在没有采用敏捷开发方法的团队当中

也会被大量的采用

我个人比较欣赏的就是这种每日站会

每天早上上班之后

这个开发小组，很小，5-10个人

站着，一定是站着，一定不能坐下来

坐下来话就多了

聊的时间就长了

每天早上15分钟，每个人都必须发言

如果团队太大，组长发言就可以了

组员就没有时间发言了

这里要求每个人都发言

每个人发言说什么呀

第一，要汇报一下昨天做了什么

今天要做什么

昨天遇到了什么问题

怎么解决的，或者是如果没有解决

今天打算怎么解决

可能需要什么帮助等等

注意这里的粒度，就是昨天和今天

不像传统方法当中

星期一的这种例会汇报的是

上一周干了什么

要汇报下一周的计划

这里的粒度变小了，就是昨天和今天

每个人发言完之后，有一个看板

到看板那儿把自己的状态更新一下

下面来看一下看板

这个看板非常灵活，可以用软件来做

这个软件里面左边这一列是ready

中间是working，正在工作的

右边就是done，做完的

还可以分成四版

正在收集的资料

正在计划做的事情

正在做的事情和已经做完的事情

还可以是这样一个破破烂烂的板子

上面可以用这种标签纸

可以用不同颜色的标签纸来写明

未开始，进行中，已完成

结合开发的一个实践

可能说分成5部分

待开发，开发中，待测试，测试中和测试完

为什么要展示这么多看板？各种各样的

就是想提醒大家

用看板这种方法，这种形式

没有任何硬性的规定

大家重点在于把握这里面一个实质的问题

就是灵活和高效

下一个比较有意思的实践就是它的计划纸牌

就是工作的时候可以打打扑克

这个扑克当然不是一般的扑克

这个扑克它有一个“不知道”

就是说不知道用多长时间

不知道这个数字是多少

首先要明确一下这个纸牌干什么用的

是用于估计指定的某个任务的工作量

在团队当中，大家对某一个任务工作量的估计

不像传统的那样，由负责人，由CTO，由技术牛人

一个人来估计，估计完之后

分给下面的工作人员

那样的话会出现不准

你想一下，一个老手和一个新手

他对同样一件事的时间估计可能是完全不一样的

新手可能说我需要20天

老手说1天我就搞定了

这个差距是非常的大

在scrum当中用这个计划纸牌

大家坐在一起，每人一副牌

拿出来一个任务，大家打牌

我出2+0.5，也就是我认为需要2.5天才能完成

另外一个人可能拿出一个13，他说13天完成

每个人都打牌，都先不亮

最后123大家一起翻牌

看一看每个人对同样一件任务估计数字的大小

它的差异是不是很大，如果差异很大

要解释为什么我估计的跟别人估计的差距那么大

通过这种讨论，可以有这样的几点收获

第一点，团队集体的估计

这种估计的准确性大大提高了

第二点，不同的开发人员通过

别人对这件事的估计与自己估计的一个对比

倾听别人的讲解，可以提高自己

这是说计划纸牌，在实际的工作当中

有的时候打这个纸牌无解

这时候可能就需要master出面

要么平均，要么采取一种其他的方式

不能让这种纸牌一直循环下去

下面来总结一下scrum敏捷开发方法

首先它很简单，它规定了一个也很简单的流程

第二，这种方法是以团队的自主自发为基础

所以很多人就会有这样一个误解

对团队成员的要求这么高啊

那我们可能搞不定

敏捷方法离我们比较远，我们的人员素质没那么高

后面对敏捷方法当中

会进一步的讨论

第三，团队成员要跨职能的

这里分工不要那么明确

当然了，不能让一个兼职的开发人员

来进入我们这样一个团队

快速迭代要求全体开发人员

必须全副身心的投入

第四，通过简单的流程，自组织的团队

来快速的迭代的增量的来完成系统的交付

同时scrum并不排斥

团队从其他敏捷开发方法当中

甚至是从重型方法当中借鉴一些必要的工程技术手段

这就是我们开始说的，软件工程是一个非常灵活

非常系统，非常工程的这样一套方法