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

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

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

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

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

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

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

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

  • (地址和办公电话),或者移动电话
  • 地址和(办公电话或移动电话)

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

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

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

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

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

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

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

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