User Story Q&A

1. 什么是用户故事？
用户故事描述了对用户或客户有价值的功能。用户故事由以下三方面组成（3C）：

• 一份书面的故事描述，用来做计划和作为提示（Card）。
• 有关故事的对话，用于具体化故事细节（Conversation）。
• 测试，用于表达和编档故事细节且可用于确定故事何时完成（Confirmation）。

可以用故事卡来记录用户故事，在故事卡的正面记录故事的简短描述，背面则记录测试要点。

2. 什么是优秀的用户故事？
优秀的用户故事应该具备以下6个特点（INVEST）：

• 独立的（Independent）。
• 可讨论的（Negotiable）。
• 对用户或客户有价值的（Valuable to users or customers）。
• 可估计的（Estimatable）。
• 小的（Small）。
• 可测试的（Testable）。

3. 为什么使用用户故事？
使用用户故事能够带来下面好处：

• 用户故事强调口头沟通。可以提供迅速的反馈周期，能够促成对需求的充分理解。
• 用户故事更容易被人理解。
• 用户故事的大小适合做计划。
• 用户故事适合于迭代开发。可以很容易的从一个史诗故事入手，并在需要的时候将其分解成多个小故事。
• 用户故事鼓励延迟细节。可以很快的写出大量用户故事，迅速的开展工作。
• 用户故事鼓励随机应变的设计。团队能迅速的在高层及低层细节思考间切换。
• 用户故事鼓励参与性设计。
• 用户故事有利于传播隐性知识。

4. 用户故事有哪些不足？

• 大型项目中，用户故事之间的关系可能错综复杂，难以组织好成千上万的用户故事。
• 如果开发过程规定要有需求的可追溯性，需要额外的文档。
• 在特大规模多团队的项目中，仅靠用户故事是不够的，不然难以保证信息在大型团队中充分共享。

要点：

• 可以考虑使用其它补充需求说明或使用用例。

5. 怎样开始编写用户故事？
首先从识别关键用户角色开始。按以下步骤对用户角色建模（角色卡）：

• 通过头脑风暴，列出初始的用户角色集合。
• 整理最初的用户角色集合，表明角色之间的关系。
• 整合角色，合并完全重叠的角色，丢弃多余的和不太重要的角色。
• 提炼角色，定义角色的特征，以便更清楚的了解不同角色的差异。

要点：

• 用户角色代表的是单一用户。
• 用户角色定义的是人，而不是其它外部系统。

6. 怎样发现和收集用户故事？
以下2种方法有助于发现和收集用户故事：

• 用户访谈。
• 故事编写研讨会（头脑风暴，简单原型）。

要点：

• 使用开放式的，背景无关的提问。
• 应该把重点放在故事的数量上而不是质量上。

7. 当不能或很难接触实际用户时该怎么办？
以下方法有助于解决问题：

• 组建由用户代理领导的用户顾问团队（业务分析师和领域专家是较好的用户代理人选）。
• 尽早的频繁的发布产品，以便尽快得到用户的真实反馈。

8. 怎样描述用户故事？
可以使用下面的格式描述用户故事：
作为一个（角色），我想要（功能），以便于（商业价值）

9. 怎样处理非功能需求？
使用约束卡片，如果需要也可以使用其它形式的补充需求说明。

10. 怎样估算用户故事？
用故事点估算方法估算故事。

要点：

• 估算用户故事工作量的相对大小。
• 团队估算

11. 怎样安排故事的优先级？
故事的客户价值和风险是安排故事优先级要考虑的重要因素。

12. 怎样将用户故事分配到发布计划？
按以下步骤分配用户故事到发布计划：

• 确定客户预期的大致发布日期。
• 确定迭代长度（一般2-4周）。
• 估算用户故事（故事点估算）。
• 估算团队初始速率（每个迭代完成的故事点）。
• 安排故事优先级（按客户价值和风险等因素）。
• 按故事优先级，故事点，团队速率分配故事到每轮迭代。

13. 怎样将用户故事分解为多个任务？
以下3方面是分解任务时要考虑的重要因素：

• 有利于估算。
• 有利于协作分工。
• 有利于跟踪完成情况。

14. 怎样将任务分配到迭代计划？
按以下步骤分配任务到迭代计划：

• 将用户故事分解为多个任务。
• 团队成员认领任务。
• 团队成员估算并确认他们自己的任务。

要点：

• 团队分解任务
• 个人估算任务（按小时）

15. 当用户界面设计不适合频繁变更时怎么办？
可以按下面步骤实现以使用为中心的设计：

• 用户角色建模。
• 捕获高层次的用户故事。
• 排列故事优先级。
• 精炼高优先级和中等优先级的故事。
• 对故事整理分组。
• 建立书面的原型。
• 精炼该原型。
• 开始编程。

16. 怎样基于用户故事监控团队速率和完成情况？
以下4种方法有助于监控速率和完成情况：

• 速率图，用于展现每轮迭代的速率（每轮迭代完成故事点），以便于监测实际速率和计划速率的偏差。
• 累计完成故事点图，用于展现每轮迭代完成的故事点，以便于监测累计的实际完成故事点和计划完成故事点的偏差。
• 迭代燃尽图（发布燃尽图），用于展现每轮迭代末剩余的故事点，以便于把握项目整体的进展情况。
• 每日燃尽图（Sprint燃尽图），用于展现一轮迭代中每日剩余工作的小时数，以便于把握每轮迭代的进展情况。

评论

1 楼 ggokind 2011-04-18  

iPhone不能进行迭代开发：），因为用户看到了就会导致商业泄密，致使大量跟进者模仿。

上面说的“对于大型项目story的缺点”，还是比较中肯的，story最大缺点是没有逻辑性。用户一般很难有足够的耐性帮我们一个个澄清story和异常分支。
真正保证完整设计的，还是有经验的设计人员。

最重要的还是人：）