不懂用户故事做不好敏捷开发！（二）

上一篇写过《不懂用户故事做不好敏捷开发！》，用户故事在敏捷开发中的重要性比你想象的还要重要。因此在补一篇关于用户故事的内容。

用户故事可以将软件研发过程中的需求，开发和测试这些环节有效的连接起来。很多项目经理喜欢直接描述功能性的需求，有的时候开发会听的一头雾水，并且根本不知道项目经理这么做的目的，项目经理怎么说，开发就怎么做，有点盲人摸象的感觉。

一个好的用户故事应该具有六大特性：Idependent（独立的）；Negotiable（可协商的）；Valuable to users or customers（对用户或者客户是有价值的）；Estimatable（可估算的）；Small（小的）；Testable（可测试的）。这就是用户的INVEST特性。

独立性（Independent）是指要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。独立性好的用户故事可以进行独立交付。传统的需求描述的方式，比如功能模块，测试用例等由于比较大，模块和模块之间依赖比较多，这就导致开发工程师在协作的时候不太容易计划他们的工作，从而导致开发周期延期。

可协商性（Negotiable）是指一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）是指每个故事必须对客户具有价值（无论是最终用户还是购买你服务的客户）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。怎么写？参考上一篇说的。作为一个<角色>, 我想要<活动或者怎么操作>, 以便于<商业价值>

可估算性（Estimable）是指开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。但是估算本身就是浪费。使用小时进行估算则更加浪费，人们花费几个小时去讨论细枝末节，还不如赶快开始工作。虽然使用点数进行估算也是浪费，但为了可以使项目的进度更加易于预测和透明，用户故事应该大致上有相同的大小，再加上一定的差异。对于大多数（成熟或者不成熟的）团队来说，这并不容易，因此他们需要故事点。估算故事点比小时更快速、更好也更经济，高效团队会完全弃用任何以小时为单位的估算，因为他们认为这是一种浪费，只会拖慢他们。我们应该确保那些新接触敏捷的人不会假设故事点＝工作量＝小时。在决定故事点时，虽然工作量很重要，但还需要充分考虑不确定性，点数和小时之间不存在等价关系。

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

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

欢迎关注！下篇再聊如何划分用户故事！