User Story 入门

对于敏捷开发来说，User Story 是开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的 Story，以方便拆分 Task，估计开发时间，领取开发任务。

什么是用户故事 (User Story)

用户故事是从用户的角度来描述用户渴望得到的功能。用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：
As a <Role>, I want to <Activity>, so that <Business Value>.

中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。” 作为一个普通用户，我希望能够用用户名和密码登录，以便我能享受到个性化的服务 用户可以在网站上发布简历 用户可以查找职位 公司可以发布新的职位 用户可以限制那些人可以查看他的简历

Ron Jeffries 的 3 个 C

1. 卡片 Card – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
2. 交谈 Conversation - 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
3. 确认 Confirmation - 通过验收测试确认用户故事被正确完成。

用户故事的六个特性 - INVEST

独立性 Independent – 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性 Negotiable – 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值 Valuable – 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性 Estimable – 开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小 Small – 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性 Testable – 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

一些经验

1. 永远不要在 User Story 中使用 And 和 Or，因为这是些分支词就表示分支任务，把它们拆成两个 Story.
2. 数据整理：通常情况下1个 sprint(2周一次迭代) 可以做 4～5 个 Story，极端大的 Story 不可大于1个 sprint。
3. 数据整理：通常情况下1个 sprint(2周一次迭代) 可以做 50 个左右的 Task。
4. User Story 用于描述用户故事，不要包括任何的技术，框架等内容。Task 可以包括框架，技术等内容。

用户故事的划分

怎样划分用户故事？

主要是要从客户角度对用户故事进行划分，具体可以：

• 按照不同操作 – 添加、删除、修改、浏览等
• 按照数据 – 可以浏览产品名和介绍、可以浏览产品价格
• 按照特性 – 易用性、性能、兼容性、并发性等等按照角色 – 从不同用户角度
• 按照投入的人力 – 比如要完成信用卡支付(Visa, Master, AmericanExperess)，可以分成三个故事来实现

为什么用户故事越小越好

1. 减少等待 – 下游的成员不必要等待过长的时间，小用户故事在系统内的流转会更快
2. 加快反馈 – 每一个小功能的完成都是一个反馈点，可以及时沟通信息。
3. 减少缺陷 – 沟通更加及时，有问题可以及时发现，立刻解决，而不需要过长时间的等待。
4. 更好的衡量进度 – 可以工作的软件能够更好、更真实地反映项目进度状况。
5. 人天生只能关注很小部分 – 精力和智力所限。
6. 较少的投入获得较早的回报 – 这样可以尽早的达到成本与收入的平衡点。
7. 风险小 – 小的功能投入的资源较少。
8. 更容易分优先级 – 大块用户故事中难免还有优先级较低的小用户故事，通过细分，可以真正关注高优先级的用户故事。
9. 更容易让每个人接触不同的用户故事 – 用户故事变小，也会更简单，因此很容易让不同人同时去完成。

User Story的分析与设计

为了降低成员之间的学习成本，对于 Story 分析的格式和叙事风格应当形成统一的认识和理解，并在项目进行当中随时修正，始终保证文档的可用性。

User Story 分析的内容

1. 站在使用者的角度，从功能层面说明 User Story 的特性和能力，比如用户做一些操作，产品会有什么样的反馈。
2. 站在开发者的角度，从实现层面说明为了实现前述能力，产品内部需要做哪些调整，针对不同的操作要实现怎样的处理流程。
3. 作为记事本，记录 User Story 分析过程中的疑问和问题，用于和用户、团队的其他成员交流，同时方便后续团队成员查看和学习。

User Story 分析怎么去做

1. 由外及内，站在客户角度观察特性，分析出特性提供给客户的各项能力，描述出客户的使用场景和使用顺序，判定出客户的正常行为以及异常行为
2. 由内及外，站在系统内部，分析出参与特性实现的相关模块，确定修改范围
3. 确定上述两点后，理清系统边界，确定本 Story 的交付范围和质量要求，以及依赖的资源
4. 识别出隐性要求，比如性能需求，要求多长时间内必须响应，或者每秒处理用户的多少次操作，或者满足多少用户同时在线操作；比如可靠性需求，识别出用户的异常行为，避免系统承受一定的攻击行为，避免系统崩溃
5. 思维清晰，很有条理，文字比较简单，意义明确，没有歧义，阅读起来很方便

商务分析师

商务分析师最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事并将需求转述给程序员。同时，商务分析师也要代替客户负责功能验收测试。

敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。和客户进行交流，最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验，客户说，我要这个功能，我想要怎么怎么样。这时候要特别注意，他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么，挖掘出他真正的目标。

在这个目标下，商务分析师开始进行需求的分析：我们到底是否真的需要这个需求？有没有更好的解决方案？有没有简单并且低廉的方式？换一种形式是不是也能达到这样的需求？这个需求有多少地方涉及到以前的软件变更？

参考

• 用户故事的划分