用故事来传递商业价值

作者 | Matt Stine

赛希翻译组 译

软件开发的首要目的是向客户交付价值。用户故事则是实现这一目标的良好工具。

为什么公司会组织开发团队来开发软件？这绝对不是因为软件本身有内在价值。而是因为他们从这些产品中获得了重要的商业价值（或其他价值）。

公司或者组织开发软件销售是因为它满足了一些既定的市场需求。对客户、用户来说，价值通过这些系统、产品交付进行了传递。

金融机构、国企、非盈利组织等IT组织开发软件是因为它为公司或组织其他部分带来价值。

任何不为组织提供任何商业价值（或其他价值）的软件产品--无论是软件公司开发和销售的产品，还是内部IT组织开发的企业系统--是没有存在的理由的。

因此，这就引出了一个问题:我们如何才能确保开发的软件产品为我们的客户或者为我们组织提供商业价值?

一直以来，软件需求规格说明（SRS）以及之后的用户案例，是记录客户需求（即必须交付的价值）的媒介。这通常是一个长期的、艰巨的、预先的需求提取过程的产物。用户、客户、业务分析师、架构师、开发人员等将花费数天、数周、甚至数月，来生产这些需求的“详尽”文档。

在这一过程结束时，双方签名，表明客户（无论是实际的最终用户还是客户）和开发机构就生产什么软件达成一致。

然而，SRS和用户案例存在着问题：

1. 它们通常是固定不变的，唯有通过官方的变更控制程序才能改变，这么做是为了减少变化。这阻碍了它们的发展，从而不能反映当前对客户需求的最佳理解。

我们的备注：该国外笔者这样理解也许是片面的，因为SRS只有在建立基线后才需要走变更控制程序，建立基线也可以迭代形成，另外变更程序也可以做到快速响应，但是背后所产生的核心观点是正确的，那就是无论哪种开发模式、管理模型下，在保证产品质量的情况下更快交付商业价值是我们所共同追求的。

2. "详尽"的性质阻碍了客户和企业之间的持续沟通。它们往往只是按部就班地执行，不管这么做是否符合（或曾符合）逻辑。

我们的备注：“详尽”的性质阻碍了客户与企业直接的持续沟通，应该 没有直接的逻辑联系。该笔者背后的意图应该是鼓励跟客户或者产品使用者 之间高效和持续的沟通。

3. 由于它们是"预先"完成的，许多功能的具体分解和实行之间产生了巨大的延迟。这迫使开发团队不断进行上下文切换，因为在开始实行之前必须回顾早前确定的细节。

这些问题中的每一个都严重降低了软件能提供的潜在价值。

如往常一样，我们可以求助于敏捷。用户故事是敏捷过程中获取用户需求的常见方法。它不断证明自己是通过软件交付价值的有效手段。

如果上网查的话，你会发现用户故事的许多不同定义。其中，我最喜欢的是这样一个主题：故事卡（最早用来记录用户故事的媒介是索引卡，至今仍在大量使用）是“未来沟通的保障”。

谁和谁之间的对话？客户和开发人员。关于什么的对话？将要交付的价值。

Ron Jeffries甚至把这个定义正式化了一些。他将用户故事细分成三个主要部分。

1、卡片

2、对话

3、确认

这三个部分不可分割。去掉任何一个，价值就会立即消失。让我们研究一下这些组成部分，并探索其中的原因。

01、卡片

卡片是用户故事的第一个实体表现。正如我之前所说，卡片通常是普通的索引卡，并且有意设置得很小。我们要避免把需求全部都记录下来，典型的故事定义通常只有一句话。

作为一名实验室管理人员，我应该能够筛选试剂清单，这样我便可以轻松找到我需要用的那个。"

你会在很多用户故事中注意到一种模式。它非常常见，甚至有了自己的名字："角色-目标-动机"。我们在之后的文章再探讨角色，目前我想把重点放在目标和动机上。

目标是 "我需要做什么"，动机是 "我为什么要这样做"。“为什么”说的就是这个故事会交付的价值。我一直努力让故事以这种方式呈现，这样我们就不会遗忘价值的部分。

事实上，卡片的主要功能就是避免遗忘。我们不是要把所有都记录下来，我们只是在创造Jeffries所说的 "标志"。你甚至可以称它为精益世界的看板，它主要是用于提醒我们要进行这些对话。

02、对话

对话是真正实现价值获取的地方。在客户和开发人员定期面对面的交流中，每个参与者对特定需求达成一致。

对话在整个发展过程中会发生很多次，最初在故事定义和卡片创建时，之后在需要评估和执行故事时。在实现故事的整个迭代过程中，他们会频繁发生。最后当故事“完成”并展示软件新功能时，它们还会再次发生。

每一次的对话都是在交流需要增加哪些价值，这是减轻软件需求规范问题的核心。

因为我们的对话从来都不是一成不变的，因为没有变更控制过程，所以我们可以高效地交流如何最好地提供价值。因为我们并不试图把对所需价值的想法都记录下来，所以我们的想法在软件的设计和实施过程中可以不断演变。因为这些对话是持续进行，而不是预先完成的，所以在制定和实施细节之间不会有延迟。

这样，上下文切换问题就被消除了。

03、确认

然而，对话本身是不够的。怎么知道我们什么时候完成了呢？故事的最后一个关键组成部分是确认，或者说"验收测试"。

验收测试是自动化测试，它以一种可扩展的方式记录了我们目前对如何交付价值的最佳理解。这需要让客户和开发者都能理解。行为驱动开发工具(如Cucumber)的增加为创建验收测试提供了绝佳的手段。

这些测试很容易被影响，它们会随着更多故事对话的发生以及软件本身的发展而轻易改变。它们也是自动的、可执行的，我们可以很容易地在任何给定的时间点知道软件是否符合我们当前对给定故事所需的最佳理解。

只要定期执行这些测试，软件和 "需求”就不会不一致。可能的话，每次向源存储库提交新代码时都应该执行。

总结

软件开发最重要的是向客户交付价值。既然这样，我们就应该使用最好的工具来确保我们交付的价值达到客户的预期。通过这篇文章，我希望能揭示为什么用户故事是完成价值交付的一个优秀工具。

更多精彩内容和视频，请关注同名微信公众号。