Author / ethanhuang

预计阅读时间: 15 min The Product Ownership overview video by Henrik Kniberg  

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