在团队敏捷开发方法落地的过程中，经常会引入大量优秀的实践来帮助团队改善软件质量，其中开卡和验卡就是两项重要的实践活动（参考前文介绍 https://www.jianshu.com/p/d0bdfb77f629）。在迭代的开发过程中，作为产品人员（PO或者BA），会要求其参与到这2个实践活动中。但是在实际的实施过程中，产品人员（有时会是业务方或客户）不愿意参花费太多时间去投入，尤其是在验卡环节-也就是对开发人员完成的用户故事进行验收。

在沟通中，我们发现有几方面的原因：

第一点，验卡活动是基于需求的最小颗粒度-用户故事来展开的，对于产品人员来说，不是一个完整的需求，他们更希望是进行该需求所包括的用户故事都完成之后再启动一次性验收，省时省力。

第二点，产品人员的工作节奏容易被打乱，在实际的操作过程中，我们希望产品人员随时能够及时的参与到验收中，尽快给与开发完成的用户故事进行反馈，而产品人员本身也有自己的工作任务和安排，随时验收也往往对他们形成一定的干扰。

第三点， 验卡的活动要求，本身要求就比较高，除了在早期需要将单个需求拆分成颗粒度适中的用户故事以外，还需要基于用户故事和需求分别进行AC（验收标准）的设计，无形中也增加了产品人员的工作成本。

但是，既然从产品人员的角度来看，验卡环节有诸多“不便”，哪为什么还要去推行这个活动呢？

首先，我们了解到，在敏捷宣言中我们提到“可工作的软件胜过详尽的文档”、“客户合作胜过合同谈判”，这2条宣言中首先先明确了客户希望看到的是可工作的软件，那么什么是可工作的软件呢，对于产品来说，可工作的软件并不等同于可发布的软件，了解用户故事INVEST原则的同学都清楚，用户故事本身就是需求承载的最小单元，是独立的、可验证的，所以就单独用户故事本身来讲，我们希望它是可以被独立验收的。从另外一方面，我们希望加强与客户的沟通（在这个活动中产品人员代表客户进行验收），而不是到了最后再与客户去讨论为什么我们做出来是这个样子，不是他想要的，所以我们通过验收环节让客户参与进来，提升客户的参与感同时，降低了后期沟通成本。

其次，缩短反馈环，降低修复成本。对于产品人员来讲，开发随时完成随时验收，确实很容易对其当前的手头工作造成一定的影响，但是这个时间安排是可以协商的，我们有碰到做的好的团队，开发和产品协商，上午或者下午固定一个时间点进行当天的故事卡验收，这样既不会频繁打扰产品人员，也不会将验收的时间拖得太久。从另一方面来讲，每当完成一个故事看开发后，对于开发人员来讲，如果能够快速的得到确认和反馈，一方面出现了问题立马可以进行修复，大大降低了后期修复的成本，同时也是对于开发人员前期工作的肯定，试想当你完成一个又一个小的任务后，被任务的接受者得到认可，无形中对于开发人员也是一种激励，紧接着他又兴致高昂的投入到下一个任务的开发环节中去。

再者，站在产品人员的角度来看，在通常情况下，单个故事卡展现的并非一个完整的需求（当然这个并非绝对，也有部分小颗粒度的需求是可以通过一个故事卡来承载的），所以产品人很容易觉得，既然你没有做完，为什么要跟让我验收呢，等所有的都开发完成了再一次性验收不好么？我为什么要投入这么多时间在单个的故事卡上呢？其实这种想法也很正常，大家都不想做重复的事情。但是我们在倡导质量内建时，希望能够尽早的发现问题、尽早修复，所以站在这个角度来看，单个故事卡虽然说不完整，但是尽早验收更利于在早期发现问题。我们也遇到过类似的情况，在一个完整需求涉及到的3个故事单独开发完成后，产品再进行验收，最后发现第一张故事卡里涉及的一个接口参数不合理，而这个参数的修改，又跟后面的2个故事有一定关系，几乎都要有不同程度的改动，如果我们能够在第一张故事卡完成后就发现这个问题，我们修复的工作量是不是大大减少呢？如此带来的浪费也会大大降低。

最后，想要说的是，要做好用户故事的快速而高效的验收，每一个故事卡准确的描述以及清晰的验收标准（AC）就非常关键，这些都是作为开发人员高质量完成需求开发和自测的依据。如果在前期的这些节点上都已经做好了，开发人员对于这张故事卡要做成什么样、要达成什么预期目的也往往心中有数，避免了在验收时才发现，漏做了或者多做了一些功能，降低了双方沟通的成本。

所以，再从全局角度来考虑，从“产品人员所投入的所有时间+开发测试修复的时间”的综合实践考虑，花费在验卡环节的时间是不是要比最后再验收出现问题时再修复所花费的总时间更少呢？所以要站在团队角度去看待该问题，到底哪种方式能够帮助团队节省时间，而且有利于保障产品的质量的提升，希望能够给到大家一些思考。