验收条件（AC）应该由PO和程序员一起写的8个原因

验收条件（AC）应该由程序员写的8个原因

ETHAN HUANG，CST，Agile Coach

在我的Scrum课程、教练和咨询工作中，我发现敏捷团队在实现BDD/ATDD时，大多数人都认为应当由 Product Owner 负责编写验收条件（AC），而不是程序员。

按照这样的做法，程序员会自然而然的要求PO编写非常详细的验收条件，并由程序员评审，作为新Sprint的“开工标准（Definition of Ready)，形成习惯后往往PO编写的非常详细的AC最终成为需求文档。

其实最佳实践是反过来的 — AC应该由程序员写而不是PO。正确的做法是双方一起进行头脑风暴，PO给出想法，细节，指导，澄清，甚至对于“如何实现“的想法，但最终应该由程序员来编写AC。

许多书，包括Bob大叔的《The Clean Coder》, Matt Wynne 的 《Cucumber：行为驱动指南》都讨论了PO编写AC的实践，但似乎没有多少敏捷团队遵循它。所以，每当我们开始讨论为什么AC必须由程序员编写时，我总是与别人分享我的8个理由。

1. 让程序员编写AC可以帮助他们更好地理解需求细节。读一遍和写一遍，哪一种方法能帮助人们对事物有更深的理解？答案是很明显的。
2. 当团队在编写AC时，他们实际上是在与PO一起，将用户故事分解成更小的子功能。例如看这个用户故事:“作为一个在线购物者，我希望能够登录网站，这样我就可以安全地访问登录页面。你会认为这是一个小功能还是一个大功能？可能一眼看过去，你会觉得一个登录界面是一个一两天能搞定的简单功能，但一名经验丰富的开发者，你便能够想出30多个AC，包括正常流程，备选流程，异常流程，“记住我”，“Https支持”，“安全问题”，“使用其他帐号登录”，“扫描二维码登录”，“第三方登录”等等。然后他们会发现这个用户故事是一个史诗级的大功能，可能需要整个团队花费几个sprint才能交付所有内容。
3. 因此，在程序员在冲刺计划会做出承诺之前，他们应该和PO一起头脑风暴出优先级高的用户故事所属的AC，这样他们就可以避免因为误判功能的规模而导致过度承诺。
4. 当团队开始编写AC时，他们实际上开始考虑设计。如果你换到程序员的角度，那么当你在和PO讨论AC的时候，你的大脑中在思考什么？“怎么做！”
5. 如果团队正在实践BDD，并且在AC中使用Given/When/Then关键字，当编写Given< precondition >时，他们实际上是在识别技术依赖关系。例如，如果你在Uber应用程序的“地图视图”中为“当前位置”功能编写AC，你可能会这么写：

Given [ GPS位置信息已经获取]

When [我打开地图视图]

Then  [我的图标应该定位到地图当前位置]

程序员会开始思考：如果我获取GPS位置信息失败该怎么办?

6. 将AC写出来以后，估算就变得容易了，因为​AC颗粒度更小。其实如果团队习惯写AC以后，估算都不需要做了，直接数AC的个数更好​。
7. 当程序员开始编写AC时，他们开始与PO共创需求。他们不再认为PO是他们工作的上游，两者之间的关系从对立变为协作。
8. 当程序员开始写AC以后，PO就从繁琐的文档工作中解放出来了。他们可以把更多的时间花在更重要的事情上，例如考虑如何盈利，优先级排序等等​。

综上，大部分团队会认写AC是PO的基本工作。其实正确的实践是反过来的 – AC应该由程序员写而不是PO。正确的做法是双方一起进行头脑风暴，PO给出想法，细节，指导，澄清，甚至对于“如何实现“的想法，但最终应该由程序员来编写AC。

但是这不代表PO的工作会变少，他们依然要思考、要和程序员一起头脑风暴共创细节，程序员写完AC之后还要确认。