编写用户故事时常犯的五个错误

大多数敏捷软件开发和测试中关于收集需求出现的问题都来源于用户故事。的确，对于很多敏捷团队来说要以如此简洁的形式准确表达出需求并非容易的事。如何编写好的用户故事是很多刚开始接触敏捷开发流程的团队所经常遇到的问题。如果在编写用户故事的时候稍有不慎，很可能会导致开发错误的测试用例和错误地理解需求，然而最糟糕的是实现了与预期不一致的功能最终导致本次迭代宣布失败。接下来让我们来看看在编写用户故事过程中五个最常犯的错误。

用户故事简介

所谓用户故事就是指使用一段简短的描述表达出用户的需求。在很多敏捷方法如极限编程和Scrum中，都使用用户故事来表达需求。任何时候，只要有可能的话用户故事都应该由客户编写，否则，至少要由能够代表客户的商业代表或者能够代表潜在客户的代表来编写。用户故事应该尽量保持简短，而且最好能够写在3×5英寸的卡片上。卡片上的文字应该表明该用户在系统中的角色，从该用户的角度来表述的需求，以及实现了这个功能的好处。

这么做的主要目的是为了能够根据该新功能的达成条件（DoD）来估算团队完成这项功能所需要的时间。用户故事同时也促进了团队的交流，从而挖掘出更多的商业和技术需求，同时也减少了对需求的主观推测。有人会把用户故事和用例以及场景混淆，它们最大的不同就是用户故事更加简短而且不会描述程序的界面、步骤或流程。用户故事的达成要用验收测试来确认，验收测试通常来源于验收标准，验收标准有时也被叫做达成条件。在用户故事级别的估算，我们通常使用点数，理想日数或者其它单位而不是使用实际时间来衡量在某个功能特性上所需要的时间。在编写用户故事的时候，我们通常使用这样一个模板：“作为一个…我希望能够…这样我就可以…”。这里的每个空对于表达和理解需求来说都非常重要。

五个常犯的错误

1. 从用户的角度编写用户故事
例子：“作为一个用户，我希望能够管理广告，这样我就能够移除过期的和错误的广告。”

扎眼一看，你可能会觉得这个用户故事没有什么问题，因为所有需要的元素都有。但是再仔细想一想，这里说的用户到底是谁？这个管理广告的功能要为谁开发？这个用户对广告管理又有多了解呢？他是一个希望进行数据库清理和广告管理的portal管理员？还是一个希望知道自己已经都放了多少广告，并且能够移除不再需要或者有错误内容的广告的广告商呢？正如你能想到的，我只是提到了两个不同角色对系统的不同需求而已。所以，在这个例子中所缺少的是用户的角色。

2. 为Product Owner创建的用户故事
例子：“作为一个Product Owner，我希望系统能够有删除广告的功能，这样用户就能够删除广告了。”

我们从这个例子再次看到了一个拥有所有标准元素的错误的用户故事。首先，这个用户故事是很典型的“你需要一个用户故事嘛，就给你一个好了”形式。很显然，写这个用户故事的人只是为了完成任务，因为通常你只会在你的团队正在开发一个敏捷开发管理软件的时候系统中才会出现Product Owner的角色。如果出现这个问题，就表明了你的公司在实施敏捷流程的时候出现了状况。第二，这里出现的问题和第一点是一样的，就是用户故事中并没有能够代表用户期望的角色出现。

3. 为开发人员创建的用户故事
例子：“作为一个开发人员，我希望能够替换掉文件夹界面，这样我就完成了维护文件夹界面了。”

这是一个技术型待办列表或者技术型需求的典型例子。有时候，这样的用户故事代表着一个所谓的技术债务，也就是说，长期累积下来的没有进行的维护任务，例如软件升级、重构、框架修改等等。这种用户故事要完成虽说没错，但是在这个例子中它并不能表现出其中的商业价值以及对客户的价值，因此Product Owner并不会买账的。另外，从敏捷的角度来看，你需要在每次迭代之后都能够产生可交付的商业价值，而且团队需要在评审会议上展示给股东看。那么我们应该如何编写此类用户故事呢？重新以用户角色的角度来编写。例如：“作为一个商业用户，我希望系统能够同时进行多个搜索，这样我就可以更快地完成我的工作。”然后，在把这个用户故事拆分成任务的时候就可以定义一些如：“重构搜索处理机制，使其能够为单个用户进行多线程搜索”，“升级Java的版本到64位版。”这个时候，验收标准就需要定义成可以量度或者测试的。例如：“单个用户可以同时进行5个搜索。”和“搜索必须在4秒钟之内返回结果。”

4. 没有商业价值或者用户价值
例如：“作为一个商业广告商，我希望能够过滤选项。”

在这个例子中，我们既看到了角色，又看到了需求，但是却没有看到商业价值和原因。我们可以问：“为什么一个商业广告商会需要过滤选项呢？他到底想要干什么呢？”

5. 没有验收标准或者达成条件
在这里你可以使用上面的任何一个作为例子。没有验收标准通常所导致的后果就是低估了工作量，同时也会导致错误地划分任务和错误地估算。用户故事很有可能会因此无法通过测试，或者是由于误解了用户故事而导致测试用例无法覆盖正确的用例。验收标准在确认需求的理解和确定用户故事的完成中扮演着非常重要的角色。验收标准的另外一个作用就是使得Product Owner和团队之间的沟通更加频繁。一个获得验收标准的好办法就是多问“如果…会怎么样？”，“…在哪里？”，“什么时候…？”，“如何…？”等问题。同时也可以举例和画图来消除疑虑。这通常会在提炼、重新计划或者分割用户故事的时候发生。

原文地址：http://www.scrumalliance.org/articles/366--common-mistakes-we-make-writing-user-stories