课件

6.2 用户故事与估算.pdf

用户故事 User Story

在敏捷项目中，用户故事是描述产品需求的一种常见方法。所谓用户故事，是从用户的角度来描述它所需要的功能。

一般情况下，把故事用很简短的语言写在一张卡片上，常见的表达格式如下图所示：

角色：谁要使用这个功能；
活动：需要完成什么样的功能；
价值：为什么需要这个功能，这个功能可以给用户带来什么价值或者好处；

一个好的用户故事应该具备独立性、可协商、有价值、可估算、短小和可测试，六个方面的特点。

独立性：故事之间要保持独立性，尽可能地避免存在依赖，否则会使制定计划、确定优先级和工作量估算都变得很困难；
可协商：故事的内容是可以协商的，一个故事卡片上只是对故事的一个简短的描述，不应该包括太多的细节，具体的细节应该是在沟通的过程中产生的；
有价值：每一个故事必须对客户是有价值的，没有价值的故事就不应该纳入开发范围中；
可估算：开发团队需要对故事的规模进行估计，以便确定开发的工作量，安排开发计划；
短小：故事的开发工作量要尽量的短小，最好不要超过 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 主管就要立即中断这个估算，或者取平均值，或者取一个大家共同接受的值，作为估算的结果。