Story Writing

Story Writing

%TOC%

为什么使用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 包括三部分：用户故事卡片、详细描述、验收标准。

（1）用户故事卡片

三要素：用户、任务和活动、目标

框架：

作为	xxx
我想要	xxxxx
以便	xxxx

实例：

作为	一个书店管理员
我想要	添加新书到书库
以便	购书者能查阅到这本书

（2）详细描述

对如何实现“我想要”的详细描述。

（3）验收标准

Q1:如何确定Story已经完成？

通过验证验收标准里的一系列内容，就能验证实现符合story的需求。

Q2:验收条件通常包括哪些？

a.具体属性

b.功能性验收条件

c.非功能性验收条件

story实例：

好的Story有哪些特点？

1. Independent 　　　可以独立开发
2. Negotiable 　　　　可以协商
3. Valuable 　　　　　有价值
4. Estimable 　　　　　大小可评估
5. Sized appropriately 合适粒度（1~5天验收完成）
6. Testable 　　　　　可测试验证

Story的生命周期是什么样的？