本文翻译自 Clear Acceptance Criteria for User Stories with Examples
在一个理想的完美的世界之中，人们之间的相互理解会很简单快捷，不会产生困惑。但是，在现实世界中，我们不得不去找到一种清晰的沟通方式，这样，对方就不会产生误解。

在软件开发中，AC可以帮助我们获知客户的对产品的期望。像是诸如“我想要一个牛掰的APP，并且在人群中非常的火爆”这种AC，并不能带给我们太多的东西。通过对每个user story定义一个清晰的AC，可以减少客户和开发团队之间的误解。

在这篇文章中，我们会讨论在敏捷方法（例如Scrum和 Kanban）中的AC，并且给出一些比较好的AC的例子。

在2020年，Scrum，user stories 和acceptance criteria不再仅仅是流行语

我们在之前已经提到Scrum过了。Scrum是一个敏捷框架，帮助软件开发团队完成任意复杂度软件的开发。

你可以从这里找到更多关于Scrum的消息。

在Scrum（或者其他的敏捷方法）中，我们使用 user story 和AC等概念来确保对于终端用户如何使用APP和开发团队如何满足每一个需求有一个清晰的描述。

当我们开始创建一个产品，我们跟客户合作来定义user story。user story使用下面的格式来写：

作为一个（用户的类型），我想要（做一些事情）以便我能（实现一些目标/获得一些结果/得到一些有价值的东西）。

user story的目的是解释用户在系统中的角色，他们想要的活动，他们想要完成什么。对于敏捷团队，user story是识别他们的需求的最简单的方法。

定义AC

那么，我们要怎么确保一个user story被正确地完成了，并且满足了客户的要求。这就是为什么要有AC。AC是一系列要求的列表，保证user story被完成，并且所有的场景都被考虑到。简而言之，AC明确了在哪些条件下user story是被满足的。简洁书面标准帮助开发团队能够避免对客户需求的歧义和沟通上的错误。

AC是非常重要的，不仅仅体现在使你能够以客户的角度看待产品，还体现在开发流程上。不同的人会在不同的角度上看待同一个问题，这是很自然的事情。明确的书面标准能够给你要实现的功能一个简单的解决方案。

AC的作用

• 定义边界。AC帮助开发团队定义user story的边界。换句话说，AC可以帮助你确认，当功能跟我们的期望一致的时候，我们的user story就完成了。

• 达成一致。AC是开发团队和客户的一种同步。开发团队能够准确的知道什么样的条件应该被满足，就像是客户知道他们期望从产品中得到什么。

• 作为基本的测试。AC是一个系统是否能够如预期运行的基础。

• 能够准确的计划和预估。AC的场景可以准确的将user story划分为任务，这样就可以更准确的进行计划和估计。

谁来写AC？什么时候来写？

客户或者开发团队来写AC。有一条规则是，由PO（客户）所写的AC需要开发团队的成员来评估，以便确认该AC对于开发团队是清晰明确的，并且从开发的角度来看是没有技术上的限制的。如果PO有软件开发的经验并且懂得如何写项目文档，这种合作方式是极好的。

如果更倾向于让开发团队来写AC，那么就应当由PM或者QA来执行这项任务，因为他们懂得技术栈和特性的可行性。

你知道自动化测试是检验产品是否达到AC的最有效的方法从这里可以了解更多的自动化测试的相关内容

请记住，AC应该是开发前明确，永远不要滞后于开发。因此，开发团队和PO应该就交付内容达成一致，交付内容应该是满足PO需求的最小的功能集合。

如何写AC

AC有几种类型。最流行的是面向规则（rules-oriented）和面向场景（scenario-oriented）的。面向规则的是列表形式，面向场景的是使用场景阐明每个标准。在敏捷团队中，更倾向于面向场景的，因为它有助于了解需求，设想各种用例。并且手动测试和自动化测试也能从中获益。*

使用面向场景的方式来描述AC的一个通用模板为Given/When/Then，这是从BDD中衍生出来的。Given/When/Then格式被用来写AT。AT能够确保所有指定的需求都被满足。

这种格式不仅符合人类的思维逻辑（因为其类似于因为所以这种逻辑）而且也适用于自动化测试工具，例如Cucumber和RSpec。举个例子，我们创建一个有两种类型的用户的网站，登陆用户和非登陆用户。我们会写一个给登出用户的登入特性的user story。

作为一个登出用户，
我想要登入这个网站，
以便我能获取到我自己的信息。
场景：系统用户使用有效的密码登陆
考虑到（Given）我是一个登出用户，
并且我在登陆页面
当（When）我填入用户名和密码，
并且点击登入按钮的时候，
那么（Then）我就登入了系统。

Given/When/Then模板帮助你减少写测试用例的时间，因为你已经提前描述了系统的行为。我们更倾向于使用第一人称“我”来写AC，因为它帮助我们从一个用户的角度来看待问题，并且将客户的需求记在心里。

这里有一些tips，可以帮助你写一些好的AC：

• 你的AC应该是定义明确的，这样你的团队成员才能明白你所表达的内容。
• 确保你的AC是可实现的。把你想要交付的内容尽可能的细化，这样你才可以专注于要交付的内容。换句话说，不要想着去描述每一个细节，因为这样你会是你的backlog聚集，并且淹没在许多小的任务上。
• 跟所有的干系人配合，你的AC是建立在一致的基础上的。
• 创建可测量的AC，这样你可以充分的估计开发时间，不会导致预算或者时间不够的情况。
• 考虑提供一个checklist，这样你就能够知道你的AC覆盖了哪些user story。

acceptance-criteria.jpg

AC的例子

在这一章节中，我们给出几个AC的例子。

Example #1

我们的第一个例子描述了网页搜索功能。

作为一个网站用户，
我想要在网页上搜索，
以便我能找到必要的信息。

根据Given/When/Then模板，AC应该是

场景：用户通过名字搜索
考虑到我是一个注册或者非注册用户，
当我打开产品页面的时候，
那么系统会给我显示产品列表
并且系统会在屏幕的右上角显示搜索区域
当我在搜索的输入框中输入已有产品的名字，
并且点击Apply按钮或者敲击enter按键的时候
那么系统会在搜索结果区域给我展示符合搜索结果的产品名字的列表，
并且系统会显示搜索结果的数目