用户故事与敏捷方法笔记---故事不是什么

系列文章

上一篇 “测量并测控速率”

---

如有问题请留言

---

前言

为了更深入的了解用户故事，接下来了解下用户故事不是什么。如何区分用例，IEEE830软件需求规格和交互设计场景。

---

提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。

文章概览

1. 用户故事不是IEEE 830

• IEEE 830 涵盖了如何整理需求规则文档，角色原型和良好需求的特征等主题。
• IEEE 830 使许多项目误入歧途，因为其侧重于关注需求清单，而不是用户目标。
• 对于IEEE 830 而言在写下所有需求前，每个需求成本是不可见的。

2. 用户故事不是用例

• 用例是对系统之间以及一个或多个用户之间交互的一般性描述，使用者要么是用户，要么是另一个系统。
• 与用户故事最大的区别就是他们的范围，用例覆盖的范围几乎总是比故事大。
• 他们存在的寿命也是不同之处，对于用例来说，只要产品在开发和维护，用例就会作为永久性的工作持续存在。
• 用例比较容易包含页面细节。
• 用例编写成客户和开发人员都能接受的格式，而故事是为了更方便的发布计划和迭代计划。

3. 用户故事不是场景

• 场景是用户与计算机交互的详细描述。交互设计场景与用例设计场景是不同的。
• 每个场景至少包含一个使用者。
  与用户故事相比，场景包含更多细节，他们的范围通常涵盖更多个故事。

---

Finish

下一篇 “用户故事的优势”

参考书籍《用户故事与敏捷方法》