敏捷实践之用户故事实践

敏捷实践之用户故事实践
一、什么是用户故事
我认为用户故事是范围的单位，是交付的单位。
重要的是，用户故事向他人传递了有用的（或有价值的）信息。在IT环境中，“他人”通常指的是使用系统的人（尽管有时是另一个利益相关者，想以某种方式限制用户，例如保护系统免受未经授权的访问）。
因此，通常从用户角度以“作为……我可以……以便于……”格式描述用户故事，从而迫使交付团队始终专注于用户正在试图达成的目标及其原因。
用户故事的基本属性(3C和INVEST)

     独立 - 不依赖其他故事
     可协商 - 并非一成不变，可以进行讨论
     有价值 - 对某些利益相关者（通常是最终用户）
     可估计的 - 足够清晰，交付团队可以很好地知道它有多大
     足够小 - 小到足以在一个sprint /迭代中传递多个故事
     可测试 - 如果无法测试，则显然对任何用户都无济于事

以我的经验，这通常没有那么简单 - 拆分故事以使它们“足够小”通常会在故事之间引入依赖关系，而单个故事往往本身并没有价值，只有一定数量的相关故事一起，它们才有价值去交付。
因此，我倾向于将INVEST属性视为准则，而不是无可争议的法律。一些属性更适用于史诗（大故事），而另一些属性更适用于小故事。对于所有故事而言，我的一条规则是：无论故事多大，它们都必须提供用户可见的内容。

二、为什么要拆分故事？

拆分故事最典型的原因是将它们分成几小块 - 足够小以在一次冲刺中交付其中的几个。你怎么吃大象？一次一小块。
我认为，还有另一个原因同等重要（如果不是更重要的话