什么叫用户故事
描述了对用户、系统或软件购买者有价值功能。
用户故事的组成
1）一份书面的故事描述，用来做计划和作为提示；
2）有关故事的对话，用来具体化故事细节；
3）测试，用于表达和编制故事细节且可用于确定故事何时完成。
如何创建用户故事
1）用户访谈
2）问卷调查，不适合作为拖网捕获新故事主要方法
3）观察
4）故事编写工作坊：会议，快速捕获故事最有效办法，结合头脑风暴最佳要素和简单原型法
用户故事的特征
1）独立的
2）可讨论的
3）对用户或客户有价值的
4）可估计的
5）小的
6）可测试的
用户故事的优势
1）用户故事强调口头沟通
2）人人都可以理解用户故事
3）用户故事适合于迭×××发
4）用户故事鼓励延迟细节
5）用户故事的大小适合做计划
6）用户故事支持随机应变的开发
7）用户故事鼓励参与性设计
8）用户故事传播隐性知识
用户故事准则
1）从目标故事开始
2）切蛋糕（slicing the cake）
3）编写封闭的故事，值那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得他完成了某个任务
4）卡片约束
5）根据实现时间来确定故事规模
6）不要过早涉及用户界面
7）有些需求并不是故事
8）在故事里包括用户角色
9）只为一个用户编写
10）以主动语态编写
11）由客户编写故事
12）向故事卡编号说“不”
13）不要忘记意图
用户故事的不足
1）在用于大量用户故事大型项目中，故事间关系错综复杂，难于捉摸
2）如果开发过程规定要有需求可追溯性，必然离不开额外文档
3）不适用特大规模，多团队结构
如何估算故事
1）无论什么时候获得有关故事新信息，都允许我们之间改变想法
2）适用于史诗故事和小故事
3）不需要花很多时间
4）提供进度和剩余工作的有用信息
5）不太精确的估算也不会有太大问题
6）可以用来制定发布计划
如何发布计划
发布计划排列优先级方法：莫斯科（MoSCow）规则
1）必须有，指系统的基本功能
2）应该有，指很重要但短期内有替代解决方法的功能
3）可以有，指如果没有时间就可以在发布中不予考虑的功能
4）这次不会有，指客户期望拥有但同时承认需要在后续发布中实现的功能
敏捷项目与传统规范过程区别
1）传统规范过程：在项目早期正确地获取写出所有的需求
2）敏捷项目：没有一种理想办法可以在一个单一阶段获取所有用户故事
用户故事与IEE830软件需求规格、用例和交互场景设计的区别
1）用户故事与IEE830需求规格
a.IEE830侧重于关注需求的检查清单，而不是用户目标
b.IEE830在写下所有需求前，每个需求成本是不可见的
2）用户故事与用例
a.范围：故事范围小，对故事大小有限制
b.完整性
c.寿命：用例作为永久性工作持续存在，故事不会超过包含他们的迭代
d.用例容易包括用户界面和细节
e.目的：编写故事是为了更方便发布计划和迭代计划
3）用户故事与交互场景设计：范围和细节
Scrum
1）迭代的过程是一种持续改进的过程，类似于雕刻
2）递增的过程是指团队按照功能点开发和发布软件
3）Scrum和XP都是基于递增和迭代方式的过程
4）采用30天为周期迭代，称为Sprint
5）Scrum没有区分架构师和测试人员角色，而是有产品负责人和ScrumMaster
a.产品负责人：主要负责管理product backlog内容和排列优先级
b.ScrumMaster：负责为团队排除障碍
6）产品backlog：所有待开发产品功能列表
7）一旦sprint开始，只有团队成员才能向sprint中添加工作
8）每日scrum短会：
a.你昨天做了什么
b.你今天打算做什么
c.有什么困难
9）每日scrum短会目的
让每个人在自己以及同事面前做出承诺，是团队成员之间的承诺
10）用户故事、sprint评审会议
好处就是很容易评估sprint中哪些部分已经完成
11）用户故事、每日scrum短会
确保整个团队关注于完成余下面向客户和最终用户的任务
XP极限编程
1）XP的12种实践
a.短交付周期（small releases）：每轮迭代通常是1-3周时间
b.计划游戏（the planning game）：发布计划和迭代计划名称
c.重构（refactoring）：重组或重写代码以改善代码
d.测试（testing）
e.结对编程（pair programming）
f.持续一致的速度（sustainable pace）
g.团队代码所有权（team code ownership）
h.编码标注（coding standard）
i.简单设计（simple design）
j.隐喻（metaphor）：提供了一个他们如何思考系统的参照体系
k.持续集成（continuos intergration）
l.现场客户（on-site customer）
2）XP的价值
a.沟通
b.简单
c.反馈
d.勇气
3）XP的关键原则
a.快速反馈
b.假设简单
c.增量变化
d.拥抱变化
其它名词定义
1）史诗故事（epic）
指故事很大
2）面向瀑布模型和故事驱动
a.面向瀑布模型：用户和客户在搜集需求后到验收之间的这段时间几乎都不参与
b.故事驱动：客户与用户在项目过程中全程参与
3）故事卡由客户团队编写
a.最了解如何表达需要实现需求
b.共同确定故事细节和安排故事优先级
4）速率：是开发人员可以在一轮迭代中完成的工作量
5）拖网
描述收集需求的过程，需求像鱼一样，会成长也会死亡，需求会随着时间推移变化，需要一些技巧来发现需求
6）故事点代表时间的模糊单位，或叫NUT（XP编程）
7）迭代计划会议内容：
a.讨论故事
b.从故事中分解出任务
c.开发人员承担每个任务的职责
d.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出额过于乐观承诺。
8）迭代计划是发布计划进一步计划，但只在迭代即将开始时才开始做迭代计划
9）迭代燃尽图：展示以故事点表示的每轮迭代末剩余工作量
10）计算速率时只考虑那些已完成的故事，即通过验收测试的故事，不要计算迭代中团队未全部完成的故事。
《用户故事与敏捷方法》读书笔记
原文：http://blog.51cto.com/luweikai/2132002
