1.8. 为什么要变成用户故事？

为什么要编写用户故事，并进行所有这些对话呢？

相比较其他方法，用户故事有比较多的优势，比如：

• 用户故事强调对话交流而不是书面沟通
• 用户故事可以同时被你和开发人员理解
• 用户故事的大小适合做计划
• 用户故事适用于迭代开发
• 用户故事激励推迟考虑细节，直到你非常清楚地了解自己的真正需求

由于用户故事的重点从文档转移到对话，所有重要决策不会写在文档里，因为很可能没有人阅读哪些文档。取而代之的是，在自动化测试中捕获用户故事的重要信息，频繁执行进行验证。

除此之外，我们还要避免在文档中出现下面含义不清的语句：

• 系统必须存储地址和办公电话或移动电话

上面的描述是什么意思呢？它可以理解为系统必须存储：

• （地址和办公电话），或者移动电话
• 地址和（办公电话或移动电话）

再次强调，由于用户故事不会有技术术语（它们是有客户团队编写的），所以开发人员和客户团队双方都能理解。

每个用户故事都代表一个独立的功能，即用户在一个单一环境中可能做的事情。这便使用户故事成为一个非常合适的计划工具。你能够估计在不同的发布中挪动故事顺序（优先级）的价值，这远远比估计去掉一个或多个“系统应该…”的陈述所产生的影响容易。

迭代过程是一个逐步求精的过程。开发团队首先开发系统中一小部分，知道它在某些（或许很多）方面是不完整的或者不完善的。然后在逐步加以相应的改进，直到产品让人满意。

通过每轮迭代中增加的更多细节，软件被逐步改进。用户故事和迭代开发可以紧密结合，因为故事也是可以迭代的。

对于最终需要但当前并不重要的特性，可以写下一个大的故事(史诗故事Epic)。准备好将大故事加入系统之后，便可以提炼它，抛弃史诗故事继而使用更小的，更具体的故事代替它。

“故事集可以迭代”这一能力，恰恰可以佐证我们可以推迟考虑故事细节。

因为假如你可以今天写下用于占位的史诗故事，就没有必要再进一步写下系统这部分的用户故事，除非马上就要开发那些部分。

推迟细节很重要，因为这样一来，我们在不确定是否真正需要某个特性时，可以不花过多的时间来考虑它。使用故事，我们不必假装可以事先知道并写下所有东西，以客户团队和开发人员的讨论为基础，不断精炼我们的需求。