1.什么是用户故事？

用户故事描述了对用户，对软件，系统或软件购买者有价值的功能。

用户故事由以下3部分组成：

一份书面的故事描述，用来做计划和作为提示。

有关故事的对话，用于具体化故事细节。

测试，用户表达和编档故事细节且可用于确定故事何时完成。

用户故事就是一个独立的功能，用户故事主要从用户的角度来阐述理念，避免开的的程序员产生更大的歧义。

用户故事贯穿整个流程，不是说用户写了用户故事给我们就完事。他也包含了验收条件，使我们能清楚的知道我们需要他来干什么。

2. 为什么编写用户故事

用户故事把设计、开发、测试都连接起来，贯穿整个产品实现周期。让整个团队以终为始做有价值的功能，明确知道给用户带来什么价值。

开发人员要负责编写用户故事，这些故事要提醒我们和客户交谈，这些故事要对用户有价值，他们是独立，可测，大小合适的。

3. 用户角色建模

1. 角色建模的步骤：    头脑风暴列举初始的用户角色集合，整理最初的角色集合，整合用户角色，提炼用户角色。

我们开发人员需要参与确认用户角色和虚构人物的过程，理解每个用户角色和虚构人物一级他们之间的异同，开发软件是考虑不同的用户角色对软件的不同偏好，shou

4. 搜索故事

1.搜索用户故事的方法：用户访谈，问卷调查，观察，故事编写。

    用户访谈：采用开放性的问题和背景无关的问题，避免对用户的引导

    问卷调查：收集已有故事的相关信息，但属于单向沟通，且时间滞后

    观察：在现场观察用户如何使用

    故事编写：快速编写大量故事，先考虑一种场景的深度，不判定是否编写正确，重点在数量而不是质量，可以先不排优先级。

5. 与用户代理合作

接触用户受限制或者接触不到的时候我们需要与用户代理合作。用户代理指可能是直接用户或者和直接用户有所属关系到人，比如客户经理之类

用户代理给出的反馈很多时间可能不是直接用户的真正的关注点。

6.用户故事验收测试

测试验收提供了确认故事是否被完整实现的基本标准。有了这个标准，我们就知道什么时候某件事算是做完了。

验收测试由客户来定义。只要这些测试还在继续为故事增加价值使它更加清晰，客户就应该继续写测试。一个优秀的开发团队会为很多详细的测试写单元测试。

7.优秀用户故事准则

切蛋糕：较大的故事拆分时应该都具备完整性，可以是需求为单位拆分而不是以技术功能为单位拆分，可以在拆分后的故事里再以技术功能为单位拆分子任务。

封闭性：一个故事里的需求功能应该是可以被完成的，而不是一个持续的过程，例如‘管理’，可以改为‘审核’，‘编辑’和‘删除’等。

卡片约束：类似一个满意条件。

根据时间确定故事的规模。

有些需求不一定要是故事，也可以就是一个任务。

故事里需要包括用户；每个故事都只为一个用户编写。

8.估算用户故事

故事点：故事复杂度的模糊测量，不同的团队可以有不同的标准，只要保证2个故事点的复杂度约为1个故事点的2倍即可。

以团队估算：故事估算应该由整个团队集体完成。

三角测量：在做了几个估算后，我们必须对估算做三角测量。具体的做法就是拿出一些故事，大家要同意4个故事点的故事大约是2个故事点故事2倍的复杂度，3个故事点的故事介于两者之间。这些都不用太过精确，但会帮助团队检验他们的估算。

使用故事点：在一轮迭代结束时，团队计算已完成的故事点数。这个点数可以作为下个迭代完成的故事点数的预报。

9.发布计划

发布周期：2到6个月最好，敏捷里通常给一个理想发布日期和一个可接受的发布日期。

优先级：可以有多种方式，包括普通方式（高中低），DSDM（必须有，应该有，可以有和这次不会有），风险优先级，结构优先级等。

选择迭代长度：通常为1到4周，如果不确定，尽量短。

故事点预计工期：故事点和速率计算工期。初始速率可以由历史记录推算，猜测速率可以讨论。

创建发布计划：按故事点分配好故事到每个迭代。

10.迭代计划

在一个发布里划分完迭代和故事点后，要对每一个迭代进行规划（sprint计划会）。

故事研讨：将本迭代（sprint）的故事合集在计划会上一一解释讨论清、楚。

分解任务：分解成面向开发的工作单位。

认领任务：写情况经办人，估算工作量并确认。

11.测速和监控

不用实际工作量计算，估算多少就按多少。

计划速率和实际速率可做图参照，一般两三个迭代后开始稳定。

燃尽图：可以爆露问题，是团队自管理的工具

12.故事对比其他需求方法

用户故事容易理解。

用户故事大小适合做计划。

用户故事适合做迭代开发：写故事的时候不是一次就把所有细节写清楚，而是按照合适颗粒度去写，先写一部分，然后按照节奏去补全故事地图。

用户故事不要求细节一步到位。

用户故事支持’随机应变‘的开发：理想的按自上而下的计划开发在中大型项目中很难办到，开发人员会在不同层的设计来回切换，用户故事更适合这种模式。

用户故事鼓励参与，增加透明度。

13.用户故事的优势

用户故事强调口头沟通。

人人都可以理解用户故事。

用户故事的大小适合做计划。

用户故事适合用于迭代开发。

用户故事鼓励延迟细节。

用户故事支持随机应变的开发。

用户故事鼓励参与性设计。

用户故事传播隐性知识。

14.故事的不良征兆

故事太小：经常需要调整估算，可能是因为故事太小。例如“编辑结果可以保持XML文件”和“编辑结果可以保持HTML文件”，显然这两个故事在很大程度上共享一部分实现，在计划时，应将这样的故事合并起来。

故事相互依赖：由于故事之间有依赖，所以很难做迭代计划。

镀金：开发人员在迭代中实现了计划外的功能，一个有效的解决方法是通过每日会议提高项目中每个人任务的可见性。

细节太多：花太多的时间去写故事，而不是去讨论故事。

过早考虑用户界面细节：在项目早期阶段编写的故事已经包含用户界面细节。

故事划分太过频繁：为了确保工作量而频繁的划分故事。

客户很难为故事安排优先级：故事太大或者无法体现出商业价值时很难排列优先级。

15.Scrum和用户故事

Scrum是迭代和增量的开发

Scrum master少管理多领导

一个PB应该包含一个版本目标所有的PBI。

Sprint计划会：前半部分梳理需求即’故事研讨‘（PB到SB）后半部分’冲刺规划‘（任务拆分、估时）。

站会越早越好，必须短，主要三个问题，昨天做了什么，今天要做什么，遇到了什么困难，SM要保持站会快的节奏。

PB的用户故事需要对客户或者用户具有价值