《用户故事与敏捷方法》阅读纪要3

用户故事不是唯一表达需求的形式，可以根据情况选择更优的表现形式，如截图或文档

故事的经典格式：我作为xx，想要xx，以便xx。使用主动语态

故事的意图是“提醒讨论”，所以不要加入过多细节

创建“约束”卡，贴在公共墙上，确保系统没有违反约束

故事由远及近，粒度越来越小

让客户来编写故事

（1.实际很难做到，只能由BA/PM/TEST来编写

2.客户普遍只能写出终端功能的故事，而无法写出影响架构、性能、兼容性等故事）

一个故事点可以近似认为是一天工作量。讲估算好的故事卡按点数归类排序贴在墙上，可以根据相对大小重新修正最初的估算。

一个故事分解成小故事后，小故事的估算点数总和可以不等于大故事

项目开发期间，尽可能坚持固定的迭代周期，可以获得固定的节奏.忌讳随意改变迭代长度

优先级由客户来确定（实操上还需根据故事之间的逻辑关系来安排迭代）

迭代计划会议

1.全员参加

2.输入：排好优先级的故事集

3.从故事分解任务

4.承担任务

（测量速率能带来价值吗）