讲课视频在线视频

在敏捷项目中

用户故事

是描述产品需求的一种常见方法

所谓用户故事是从用户的角度

来描述它所需要的功能

一般情况下

我们是把故事

用很简短的语言写在一张卡片上

这里列出了

一种常见的故事表达格式

它包括三个部分

第一是角色

谁要使用这个功能

第二是活动

需要完成什么样的功能

第三是价值

为什么需要这个功能

这个功能可以给用户

带来什么价值或者好处

一个好的用户故事

应该具备独立性 可协商 有价值

可估算 短小和可测试

六个方面的特点

故事之间要保持独立性

尽可能地避免存在依赖

否则的话

就会使制定计划确定优先级

和工作量估算都变得很困难

故事的内容是可以协商的

一个故事卡片上

只是对故事的一个简短的描述

不应该包括太多的细节

具体的细节

应该是在沟通的过程中产生的

每一个故事必须对客户

是有价值的

没有价值的故事

就不应该纳入开发范围中

开发团队

需要对故事的规模进行估计

以便确定开发的工作量

安排开发计划

故事的开发工作量

要尽量的短小

最好不要超过10个理想人天

至少要保证是在一个迭代中

能够完成

故事必须也是要可测试的

这样才可以确认

它是可以完成的

我们在故事卡片的正面

写上故事的内容

比如说 顾客可以使用信用卡

购买购物车中的商品

并且注明所接受的三种信用卡

在卡片的反面 可以列出

对这个故事的一些测试项

包括三种信用卡 借记卡

某种会员卡 各种卡号

失效的卡 以及不同的限额等

用户故事是要面向价值

进行编写的

例如 这是一个网络游戏

排行榜功能的用户故事

作为一个玩家可以通过显示排名

以便让自己在服务器中的地位

获得认可

表面上看

这个故事好像没有什么问题

但是仔细分析可以发现

虽然这个功能

可以激发玩家的斗志

鼓励购买道具

但是实现起来却有技术的问题

如果玩家太多

实时查看排名是很不现实的

另一个问题是

小的玩家

其实对自己的排名并不关心

即使关心

也不会为了提升排名去购买道具

只有少数的顶级玩家

才会真正地受此诱惑

所以这个功能

就被改为系统每周重新排名一次

而且只显示前多少名玩家

那么我们把故事就写成

作为一个排名靠前的付费玩家

可以通过显示排名

以便让自己

在服务器中的地位获得认可

以刺激消费

通常情况下

我们主要使用故事

来描述产品功能

这里有三个故事的例子

第一个是维基用户

希望上传文件到维基网站

第二个

是客服代表希望记录客户问题

第三个

是网站的管理员需要统计

访问网站的人数

这三个故事

都采用了前面的格式进行描述

而且明确地给出了

具体的用户角色

需要特别说明的是

我们不要把故事的角色

总是写成

作为一个用户之类的含糊的说法

而是要把用户区别对待

这样才能更好地理解

他们使用什么功能

如何使用 以及为何使用

另外故事除了用于描述功能之外

有时候也用于描述非功能需求

技术增强和缺陷修复等

比如说 这个故事描述的就是系统

对浏览器支持的非功能需求

开发人员有时也会创建一个

技术增强的故事

比如说 这里给出的这个例子

就是开发团队希望评估分析

两种可行的过滤引擎的技术架构

并且建议要进行性能测试

规模测试和类型测试

然后用一个简单的备忘录

来说明所进行的实验 取得的结果

和下一步开发的建议等

这个故事则是描述了

需要修复的缺陷信息

产品订单

是一系列用户故事的列表

这些故事描述的

是一些粗粒度的功能

它是由产品负责人负责维护

并根据市场价值

来决定故事的优先级

不过这个列表并不是一成不变的

需要在每次迭代之前

对功能和功能的优先级进行调整

在每次迭代开始

我们通过迭代计划会议

挑选出需要开发的订单故事

再进一步细化成开发任务

最后由开发团队进行实现

这个表是一个关于网上购物的

产品订单示例

每个条目是一个用户故事

描述了用户需要的功能

所有的条目

按照优先级进行排列

这里是某一个产品的需求列表

那么需要多长时间

才能完成版本1的开发

要回答这个问题

首先需要估算出

版本1的工作量

具体的做法是

估算每一个故事的工作量

然后把所有的估算值相加

得到一个总的估算值

接着需要给出团队的开发速度

我们可以使用历史值

或者做一个猜测

也可以试着做一轮进行测算

这个图显示了

前5次迭代的开发速度

通过计算

就可以得到一个平均速率

测算的时候

只是统计每一个迭代

所有已经完成的故事

没有完成的不计算在内

最后我们就可以估计出

版本1的迭代次数

敏捷估算有两种度量单位

用以表达用户故事 功能

或者其他工作的总体规模

一个是故事点

它是一个相对度量单位

使用的时候

我们给每个故事分配一个点值

点值本身并不重要

重要的

是不同故事点值的相对大小

另一个是理想时间

它是一个绝对度量单位

可以是天 小时等

理想时间是指某件事

在剔除所有外围活动以后

所需要的时间

一般按照

一天有效工作时间的60%-80%计算

比较合理

理想时间的估算方法

是团队成员分析和讨论

故事的细节和复杂性

然后估算出完成故事开发

所需要的理想时间

这种方法

是我们平时习惯使用的

容易理解和掌握

但是做绝对的估计

是人们天生不擅长的

而且每个人的估算不同

很难达成共识

另外 每个人的理想时间

也是不一样的

显然

无法把估算的结果进行相加

所以这样产生的计划

肯定是不准确的

故事点的基本做法

是先找出一些标准的故事

设定一个标准点数

形成比较基线

其它故事和标准故事进行比较

给出一个相对的比例

从而得到

这个故事的一个估计值

这种方法的难点在于

故事点的产品特征很明显

没有办法在不同团队之间

进行比较

如果没有历史数据

很难设定标准故事

对于网上购物这个订单来说

我们首先选择一个

简单的标准故事 注册帐户

把它的规模设定为1

然后其它故事和标准故事

进行比较

可以得到相应的故事点数

敏捷估算是由开发团队共同完成

产品负责人和Scrum主管

并不参与实际的估算

产品负责人只是阐述

和澄清用户故事

Scrum主管是指导和引导

整个估算的过程

估算不是承诺

如果我们用估算的结果

来评价一个成员的工作

是否按时完成

那么它就会在原有估算的基础上

加入一个安全量

从而人为地放大估算值

估算应该准确

但是没有必要过于精确

我们应该投入刚好够用的工作量

得到一个大致正确

足够好的估算

过于精确的估算也是浪费

由于人们更擅长相对的估算

所以应该使用相对大小

而不是绝对大小进行估算

我们可能对于一个玻璃杯

到底能放入多少饮料

没有什么概念

但是说出一个玻璃杯

相对于另一个多大

比较容易

开发团队可以使用敏捷估算扑克

来进行估算

它是一种基于共识的

估算工作量的技术

在扑克牌上

印有一些估算值

一般是有三种形式给出

一个是自然序列

一个是斐波纳契数列

还有一个是不连续的自然数

比如说2的幂等

选用哪一种形式

是由开发团队来决定的

用敏捷估算扑克进行估算

主要包括以下步骤

首先是分牌

敏捷扑克和普遍游戏扑克一样

都有54张牌

拥有4种花色

每一种各13张

每一名参与估算的成员

会得到相同花色的一组牌

扑克牌的正面

印有估算的数字

以斐波纳契数为例

0代表故事已经完成

或者太小没有估算的意义

1/2代表微小的故事

1 2和3代表小的故事

5 8和13代表中等大小的故事

20和40代表大的故事

100代表非常大的故事

问号代表估算的成员

对故事不理解

或者不知道怎么来进行估算

接下来产品负责人

从订单中选择一个故事

为大家进行详细讲解

团队成员讨论并且提问

产品负责人解答大家的问题

当团队成员确认

已经对故事完全了解

而且没有重大问题之后

大家开始进行估算

所有成员都选出

代表自己估算值的纸牌

然后扣在桌面上

选完之后大家同时亮牌

如果每张牌的估算值

存在很大差异

代表大家对这个故事

没有达到共识

就需要对评估结果进行讨论

在对故事进一步了解之后

再重新进行估算

直到团队成员之间的估算值

达到一致

一般情况下

最多三轮就可以达到统一

如果三轮之后

依然没有达到统一的意见

那么Scrum主管

就要立即中断这个估算

或者取平均值

或者取一个大家共同接受的值

作为估算的结果