Scrum--用户故事

经过前两篇对敏捷基本结构，冲刺介绍后，本次主要介绍用户故事。从用户故事是什么？好的用户故事的INVEST原则，以及如何收集用户故事分别介绍。

图片发自App

一，用户故事是什么

用户故事是可用于陈述业务价值的一种简便格式，适用于各种PBI，特别是特性。

如何描述用户故事要遵循3C原则，即：卡片card， 会话conversation， 确认confirmation。

1、卡片要写明用户种类（即用户角色）、这类用户想要达成什么（目标）以及用户为什么想达成此目标（收益）。使用卡片是为了简洁，并提醒干系人进行更深入的讨论。

2、会话开启了一个更加丰富的信息交易与协作形式。从而确保正确描述需求并使每个人都能理解需求。

3、确认则提现为满意条件的形式，更加有利于构建和测试。

用户故事的抽象层级结构可以有如下三个层级

第一层为月度级别，即史诗级别。

第二层为星期级别，大于一个冲刺，也称为特性。

第三层为天级别，冲刺就绪。

底层为小时级别，是具体的任务（任务并不是故事，比如强调的是如何构建不少构建什么）。

区分好用户不少的以上四个级别对于编写有效的用户故事很有帮助。

二、好的用户故事BillWake给出了6大标准即INVEST。

独立（Independent）、可协商（Negotiable）、有价值（Valuable）、可估算（Estimatable）、小（Small）、可测试（Test）。

下面逐一讲解各个标准的含义：

独立：用户故事是独立的，至少应是松耦合。因为依赖程度过高会使得估算、排序规划都比较复杂。

可协商：故事和普通瀑布模型需求不同，是可以协商的。

有价值：故事有价值，客户才会支付产品。当然对于技术性故事属于完成因为价值所涉及的任务。

可估算：指的是故事的故事的工作量和成本。如果团队无法衡量故事大小，原因不外乎两个：故事太大或太模糊；团队积累的知识不够。

大小合适：刚才提到的用户故事四个层级抽象，一定要够小，同时一定要考虑故事的时间点。

可测试：故事要么测试通过要么测试失败，测试标准就是3C中的确认。

三、其他故事

1、非功能需求算不算故事？

非功能需求是系统级约束，可以写到用户故事中，如支持的浏览器等。但也不写，但非功能需求是完成定义的主要目标。任何一个测试不能正常工作，都是没有完成。

2、知识获取型故事

相当于预言工作，由于受到成本、时间限制，不可能无限探索，如何决策就显得很重要。抛硬币、快速失败策略都是不错的选择。

四、如何收集用户故事

问用户想要什么不靠谱，而让用户作为团队的一员则效果会好很多。采用

用户故事研讨会、绘制故事地图是两种比较有效的方法。

用户故事研讨会：可以集中进行头脑风暴，讨论预期的业务价值，并为目标产品和服务创建用户故事占位符。

绘制故事地图：将概要性用户活动分解为工作流，工作流还可以继续分解为一套明确的任务。如下图所示，横轴为工作流（使用顺序）纵轴为优先顺序。它结合了用户为中心和故事分解这两大概念。

作为新手，学习了用户故事，是否能编写出有效的用户故事呢?