基于story的敏捷基础知识----story编写
为什么使用Story？
软件行业40年多来，需求分析技术已经很成熟了，但是MRD驱动的过程不堪重负。因为往往MRD编写会占去很多时间，MRD评审又会占去大量时间，编码完成过后提测，压力又全部倾注在QA身上，往往临计划上线时间，或者体验还差，或者bug还太多，或者项目延期。
使用story，项目完成时间会大大缩短，上市时间大大缩短。主要原因：
A． 采用story模式，将大需求拆为可独立交付的小story，需求清晰明了，节省了大量的需求评审时间。
B． story足够小，设计难度较低，并且改之前的书面详细设计及其评审为“口头沟通为主，文档为辅”，详设环节的时间也大量节省。
C． story足够小，验收标准更明确，测试设计环节简化，评审环节改为口头沟通，节约了大量设计时间。
D． story间并行，不是之前的所有需求评审完成，才开始详设，详设没问题之后才开始编码和测试，因此将需求阶段PM的瓶颈，开发阶段RD的瓶颈、测试阶段QA的瓶颈都被打破。
E． 将RD从文档和评审中解放出来，RD更有时间也更愿意去自测和写单测，bug量减少。
什么是Story?
整个项目:
story:
story 包括三部分：用户故事卡片、详细描述、验收标准。
（1）用户故事卡片
三要素：用户、任务和活动、目标
框架：
| 作为 |
xxx |
| 我想要 | xxxxx |
| 以便 | xxxx |
实例：
| 作为 | 一个书店管理员 |
|---|---|
| 我想要 | 添加新书到书库 |
| 以便 | 购书者能查阅到这本书 |
（2）详细描述
对如何实现“我想要”的详细描述。
（3）验收标准
Q1:如何确定Story已经完成？
通过验证验收标准里的一系列内容，就能验证实现符合story的需求。
Q2:验收条件通常包括哪些？
a.具体属性
b.功能性验收条件
c.非功能性验收条件
好的Story有哪些特点？
- Independent 可以独立开发
- Negotiable 可以协商
- Valuable 有价值
- Estimable 大小可评估
- Sized appropriately 合适粒度（1~5天验收完成）
- Testable 可测试验证
Story的生命周期是什么样的？
