用户故事 特性 简介 用户渴望得到的功能

特性

用户故事的六个特性-INVEST

INVEST=Independent,Negotiable,Valuable,Estimable,Small,Testable

一个好的用户故事应该遵循INVEST原则。

独立性（Independent）—要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）—一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。

具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）—每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）—一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

简介

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。[1]

MVC

Controller-Action树是另一个潜在的史诗-故事树的原型。

FPA和MVC居然能扯上关系？是的，上面提到的FPA中的内部逻辑文件，与MVC中的Controller有很好的对应（有的不能），而基本过程（输入输出查询）与MVC中Controller的Action有很好的对应关系。

比如如果有一个“UserStoriesController”（UserStories可以看作ILF），就会有一堆Create/Edit/Delete/Index……这就是4个基本过程（从前面“增加一个用户故事”的例子可以看出，Create+[HttpPost]Create两者一起才组成一个完整的基本过程）。

基本过程对应Action还是好理解的，但为何对应内部逻辑文件的是Controller而非Model？因为Controller是面向用户写的，而Model是面向实现技术的。

何以见得？因为如果要访问“增加一个用户故事”，我们会输入UserStoriesCreate，而其中可能会用到几个Model：UserStories,Statuses,Priorities,Owners……用户无法直接访问Model，但可以直接访问Controller。

所以MVC的Model更像是DataModel，而Controller才是BusinessModel（有时不是），是“一组逻辑上的数据，用户能够理解和识别它”。

使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型有以下几个好处：

Action是一类特殊的面向用户业务和价值的函数，还是客户可以直接感知并调用的函数；

Action的数量多，客户可感知的功能一般也就多（相对于一般函数）；

Action是一类可单独演示、单独测试的函数，很适合作为故事使用；

Action很容易被程序员所理解，使用MVC的程序员更容易回答“你们的软件有多少真正的用户故事？”。

使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型，将作出以下约束：

多个过程不能合并到一个故事中（与前面FPA的观点相同），因为不能用一个Action实现“增删改查”。

Controller的Action将只包含有意义的用户故事。有些程序员为了调用方便，会在Controller里定义一些不期待用户直接调用的函数（尤其是直接定义在controller.cs中），应挪到Model中实现。