个人站点地址：nowherewoman.com
通常在planning meeting的时候会由团队成员一起写出每个story的AC(Acceptance Criteria), 但是不可避免的有的场景在会议中无法全部覆盖，或者会议过程中的AC没有得到及时的记录（如果全部记录需要很长时间），或者在编码或者测试过程中都有可能出现新的想法和变动，于是就有了AC Refine的这个过程，保证AC实时更新
什么时候做？
在开发人员编写代码之前的设计过程中，将会议上的AC进行梳理，以免需求上的不清楚或者遗漏
谁负责?
由开发和测试负责人一起编写，并且记录。如果没有条件，可以是开发编写测试review，或者测试人员编写开发人员review。总之要保证开发和测试对这个story的AC达成共识。通常在这个过程中会发现很多问题，这个情况很有意思，不可避免的是，总有很多人在会议上不理解需求，但是不提问的。
AC用什么格式编写
通常会用GIVEN-WHEN-THEN的格式来编写AC。 这么做的好处
1. 这种格式最容易举例子，specific by example.
2. 如果是用specflow或者ruby编写自动话测试代码，那么这种格式的场景可以直接用于自动化。
3. 这样的语言用户容易理解，可以直接用做功能文档.对于传统的软件开发来说，要有test case，功能文档，在敏捷开发中减少了写文档的时间，但是主要的功能点可以通过这种方式得以保存
用什么软件记录AC
JIRA，用这个软件，可以为每个story加一个标签，每个标签对应相应的功能点，方便以后能够快速的找到想要功能的AC.