我已经在《突破传统定义：你不知道的RAID动态分析法》中详细介绍了RAID的定义和分析方法，在本文中我会将其应用到故事卡的验收标准上，讨论一下为什么故事卡需要验收标准。
开发人员的困扰
对于一个开发人员来说，经常受到两件事情的困扰：
- 故事卡中只有一句话，没有任何其他信息，开发人员需费力理解故事卡内容。
- 故事卡的需求在开发完成后被修改了，开发人员不得不在测试人员发现实现和需求不一致后重新修改实现。
这些困扰并非开发人员造成，但他们却常常独自承担，仿佛责任全在自己。
这些困扰会给开发人员带来糟糕的开发体验，而糟糕的开发体验会导致产品质量下降、开发效率降低以及团队合作不畅。我们需要从团队和项目的角度来看待这些困扰，而不是直接抛给开发人员。
造成困扰的本质是什么？
造成困扰的本质是团队的前置反馈循环失效，即团队既无法有效的对假设和依赖收集反驳信息，也无法有效的规避风险。
一张故事卡包含着三层假设。第一层假设是，故事卡能够表示史诗卡要完成的一部分功能。第二层假设是，故事卡的需求能够表示故事卡要完成的功能。第三层假设是，代码实现能够表示故事卡的需求。
上述提到的开发人员的困扰集中在第二层和第三层假设，这两层假设的前置反馈循环处于失效状态。对于第一个困扰，故事卡的需求是不可被讨论的，只存在于某些人的记忆里，这就导致我们无法去有效的收集反驳信息，更不要提规避风险了。对于第二个困扰，收集反驳信息的机制发生了问题，导致无法及时识别风险。
如何解决这些困扰？
既然困扰源于前置反馈循环失效，那么解决问题的关键就在于如何重建这一循环，办法就是要在故事卡有验收标准的前提下改善团队流程。
为什么要以故事卡有验收标准为前提？因为验收标准是对故事卡需求的拆解，是讨论的基础，没有讨论就无法建立起前置反馈循环。验收标准能够激发团队讨论，通过复述验收标准，可快速发现理解偏差并引发讨论。 基于验收标准的讨论，可以帮助我们发现遗漏的需求、错误的需求和不确定的需求。基于验收标准的讨论，还可以帮助我们发现遗漏的实现，错误的实现和不确定的实现。
如何改善团队流程？我们要围绕验收标准来改善团队流程，给团队制造讨论和更新验收标准的平台。在敏捷团队中，我们已经有很好的流程设计，例如Kick Off, Code Review, PR Review, Desk Check等。但在这些流程中我们大多数认为验收标准是静态的，是不能改变的，而从RAID分析的角度看，它应该是动态的，是有可能有遗漏和错误的，是需要能够在讨论的基础上修改的。所以，我们需要在这些流程的基础上设计出符合团队上下文的需求变更流程，唯一的要求是所有的变更都要经过团队讨论，不论是从上发起的还是从下发起的。在后面的讨论中我们将需求变更等同于验收标准变更。
以我所在的团队为例。所有团队成员在任何阶段都可以提出需求变更，但需要先与BA和TL进行讨论，在达成一致之后由BA变更需求。如果需求变更发生在测试之后，我们就新建故事卡来完成变更的需求。如果需求变更发生在测试之前，我们就直接在当前故事卡进行变更。如果是上游提出的需求变更，BA和TL需要与上游进行讨论，在达成一致之后，由BA创建新故事卡或变更当前迭代的故事卡。你可能已经注意到了，团队讨论可以有不同的理解，我所在的团队将团队讨论理解为有BA、TL和需求变更提出者参加的讨论。
什么时候需要变更需求？当团队讨论过某个需求但故事卡没有体现时，我们就需要将这个需求添加到故事卡，因为这个需求是团队关心的需求，需要我们时刻关注它是否为真。这里的需求可以是团队发现的遗漏的需求、错误的需求或不确定的需求。我们也不是要事无巨细的把所有需求都添加到故事卡中，只需记录那些有人提出并经过讨论的需求即可。
谁来变更需求？这应该属于需求变更流程的一部分，但我在这里再次提出是因为这是造成开发人员困扰的核心。一般开发人员都希望他们得到的需求是正确的，完善的，稳定的，高质量的，而保证这些的应该是BA或其他角色，而不是开发人员。但在实际项目中，有的团队没有BA，有的团队虽然有BA，但团队内部沟通不畅，开发人员很难让BA或其他角色来变更需求，这该怎么办？这是一个很大的问题，我不敢妄下结论应该怎么做，但即使从个人利益出发，在无法改变外部依赖时，开发人员将自己认为重要的验收标准更新到故事卡是一个减轻自己困扰的良好开端，既有助于需求实现，也有助于出现问题之后的讨论。
总结
敏捷软件开发宣言中说个体和互动 高于 流程和工具，工作的软件 高于 详尽的文档，但我们不能忽略流程，工具和文档的价值，它们是个体和互动、工作的软件的基础，没有它们，我们就无法建立起前置反馈循环，软件开发的质量和效率也将无法提升。
所以，我觉得团队沟通和工作的软件不是故事卡可以不写验收标准的理由，更何况大多数时候团队沟通并没有那么顺畅，工作的软件也没那么容易实现。只有通过先在故事卡中添加验收标准，然后不断改善团队流程才能提升软件开发的质量和效率。
