故事卡片限制了敏捷

人们使用故事卡片的方法不对。我知道这么说很大胆，但我认为，大部分人使用故事卡片的方法确实不对。就我工作和指导过的团队而言，这点毫无疑问。不要误解我的意思，相比我们过去常用的传统的具体规范文档来说，故事卡片（storycards）是有很大提高，但我觉得，我们可以做得更好。我指导大家用传统方式来创建故事卡片已经很多年了，但发现故事卡片正限制着敏捷。

故事卡片是敏捷开发中用于跟踪需求的一种常用工具，这些需求可以来自业界、来自客户或来自产品经理。但目前故事卡片常用的格式会令我们放错重点、得出错误结论、浪费时间、浪费机会。其实，我们只要对故事卡片做一个巧妙而重要的改动，就能克服这些问题并获得在市场中的优势。

大概 90% 的团队会采用下列格式来创建故事卡片：

作为 __（角色）___

我想要 __（功能或特性）___

以便于 __（商业价值）____

以前我在西雅图 FUEL:Coffee 公司任职时，跟一帮朋友讨论过包括敏捷、精益和生活在内的各种话题。我们谈了很多方面，主要是围绕着产品经理的角色与重要性。我们还讨论了精益创业（Lean Startup）运动以及它如何影响了敏捷开发。正是在那次对话中，我开始为大部分敏捷方法没有关注到开发和交付之前与之后的活动而叹息。是的，理论上敏捷方法会关注那些活动，但实践中并没有连贯的行动来支持它（当然除 DSDM 以外）。产品经理们只是把故事卡片按客户价值归类存放，仅此而已。故事的反馈和修改，主要发生在向产品经理演示产品的过程中。

这让我看不下去了。故事卡片如果不是由客户（一个真正的客户）直接创建、而是由产品经理或客户代表创建的话，那么它所记载的故事就是假故事。产品经理创建的故事不过是假设和符合专业能力的猜测而已，是他们自认为客户想要的东西。产品经理们试图理解客户的心理。但在生产出产品或服务之前，他们不会真正知道市场反应怎么样。所以，若采用“作为... 我想要...”这种无条件的陈述格式，那么就容易造成误解，让我们误以为产品经理真的知道客户想要什么，而忘了那只是个假设。

由于每一个特性都需要一定工作量去完成，有的多一些，有的少一些。假如把故事写成“作为... 我想要...”这种无条件陈述格式，我们会误以为他确定是真的。如果最终我们发现这个假设是错的（经常如此），那时我们可能已经浪费了很多工作量。就算现在的项目不像过去那样经常到了部署阶段才成为败局（别忘了福特公司的“埃德赛”汽车和微软那个会说话的大头针），但即便有办法来检验假设，仍然会浪费不必要的时间和精力。可是，既然它从未被说成是一个假设，那么就没有人会去质疑它。

如果由项目经理来创建故事卡片，我认为采用如下格式更好：

我们（或我）认为 __（客户）___

想要 __（功能与特性）___

以便于 __（商业价值）____

为验证之，我们将 ­___（假设检验）________

把第一行改成“我们认为”，这样你就知道这个故事是假设了。如果只说“作为”的话，大家会误以为这是事实、肯定对客户有价值。说“我们认为”是在提醒大家，我们说的只是假设。如果一个故事真是由客户创建的，而且故事真的是他们“作为（客户）”讲出的，那么完全按照传统格式的故事卡片就行。甚至可以把客户的名字也写在上面。“我是张三，我想要...” 这样更好。这样，你不仅有真实客户，还有人的真名与这则故事相关联。当你在开发过程中对需求有疑问时，就可以去找这个人讨论。

按照这个方法，我们将有两类故事：（1）真实客户故事，格式为“作为...” （2）有待检验的假设性故事，格式为“我们认为...”。对于第二类故事要格外小心，因为你不确定它的有效性。如果这个故事规模很大很复杂的话，那么团队在投入精力去开发它之前，应当先认真考虑有没有简单办法来验证这个假设。

如果你用物理黑板，或者你的管理软件支持的话，我强烈建议采用不同颜色或视觉上有显著差异的卡片来区分假设性故事与真实客户故事。这样就容易看出精力投入到了哪里。都是真实客户故事？或者基本上是创新性假设检验？

创新性假设检验未必是产品或服务的实际开发，而是验证客户要不要这个产品或服务。这是精益创业的核心原则。问题不是“这个产品能造出来吗？”而是“应该造这个产品吗？” [1] 所以，我们围绕着概念而不是产品或服务来构造假设检验。Eric Reis 在他的书《精益创业（The Lean Startup）》中举了一个 Groupon 的例子。Groupon 在初期没有实现自动化，没有高性能服务器，也没有高速网络连接，甚至计划中的都不是一个团购平台。在尝试创建一个叫做“The Point”的病毒式营销平台失败后，Groupon 团队建起了一个提供匹萨店打折优惠券的网站。他们人工发出电子邮件，然后等收到回复后，再把优惠券以 PDF 格式发出去。就这么简陋！没有自动回复，没有强大的电邮营销自动系统。你的故事也可以这么做。

“为验证之，我们将 ­___”用于陈述你进行检验假设的步骤。这样做的好处是，它可以在演示或部署结束前完成验证，得出故事成功与否的结论。若是成功的，那么很好，你猜对了！若是不成功，你也有收获，你至少证明了这条假设是错的，现在该换个方案尝试了。你得到了经验！你知道了客户喜欢什么，不喜欢什么，而且理解了客户和变化——这也是敏捷所讲究的。

故事之间也可能存在潜在冲突。现实中，人们想要的东西未必一致。所以，在真实易懂的故事卡片和进行故事验证（用户需求或假设）之间，你会发现存在矛盾。你可能会有两个真实客户，他们想要不同的东西，或者你的假设性故事与真实客户故事相悖。在真正的创新工作中可能会碰到这样的情况。你该怎么做？这是产品经理该管的事。亨利福特有一句经典名言——如果我当年去问顾客他们想要什么，他们肯定会告诉我：“一匹更快的马”。假如你正在创造一个真正突破性的东西，那么普通用户给不了你提示。这正是为什么你要用假设性故事来探求客户还没有意识到的新想法。

敏捷方法的一个优势在于，它是持续改进的。我记得当我第一次提出增加“以便于”的时候，那对团队来说是一个伟大的突破。增加“以便于”这句话，有助于令我们在创建故事时专注于客户价值，进而专注于持续交付对客户有价值的东西。明确区分用户需求与假设检验，将有助于团队理解故事的重点：提供用户需要的服务，或者验证假设。这可以让产品经理看清精力放在了什么上面。一个组织如果要创新、要取得重大突破，它的假设性故事会多于客户需求。通过为假设性故事采用不同的卡片格式，我们可以在有效性和透明性上得到改善。

关于作者

Joseph Flahiff 是 Whitewater Projects 公司总裁兼 CEO，他的新书《Being Agile in a Waterfall World: A guide for complex organizations》即将发售。 他专注于解救在困难商业环境中工作的人们，帮他们弄清这些看似冲突的方式方法和文化。

Joseph 在传统和敏捷交付的执行、指导、咨询与培训领域有超过 15 年的经验，他参加过的项目既包括大规模复杂企业级 IT 项目，也包括小型经纪公司。Joseph 生动愉快且充满活力的授课与主题演讲在美国和欧洲都很受欢迎。Joseph 目前正效力于 PMI-ACP 的内容支持团队。

[1] 精益创业原则

原文英文链接：Your story cards are limiting your agility

感谢侯伯薇对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。