在團隊敏捷開發(fā)方法落地的過程中，經(jīng)常會引入大量優(yōu)秀的實踐來幫助團隊改善軟件質(zhì)量，其中開卡和驗卡就是兩項重要的實踐活動（參考前文介紹 http://www.itdecent.cn/p/d0bdfb77f629）。在迭代的開發(fā)過程中，作為產(chǎn)品人員（PO或者BA），會要求其參與到這2個實踐活動中。但是在實際的實施過程中，產(chǎn)品人員（有時會是業(yè)務(wù)方或客戶）不愿意參花費太多時間去投入，尤其是在驗卡環(huán)節(jié)-也就是對開發(fā)人員完成的用戶故事進行驗收。

在溝通中，我們發(fā)現(xiàn)有幾方面的原因：

第一點，驗卡活動是基于需求的最小顆粒度-用戶故事來展開的，對于產(chǎn)品人員來說，不是一個完整的需求，他們更希望是進行該需求所包括的用戶故事都完成之后再啟動一次性驗收，省時省力。

第二點，產(chǎn)品人員的工作節(jié)奏容易被打亂，在實際的操作過程中，我們希望產(chǎn)品人員隨時能夠及時的參與到驗收中，盡快給與開發(fā)完成的用戶故事進行反饋，而產(chǎn)品人員本身也有自己的工作任務(wù)和安排，隨時驗收也往往對他們形成一定的干擾。

第三點， 驗卡的活動要求，本身要求就比較高，除了在早期需要將單個需求拆分成顆粒度適中的用戶故事以外，還需要基于用戶故事和需求分別進行AC（驗收標準）的設(shè)計，無形中也增加了產(chǎn)品人員的工作成本。

但是，既然從產(chǎn)品人員的角度來看，驗卡環(huán)節(jié)有諸多“不便”，哪為什么還要去推行這個活動呢？

首先，我們了解到，在敏捷宣言中我們提到“可工作的軟件勝過詳盡的文檔”、“客戶合作勝過合同談判”，這2條宣言中首先先明確了客戶希望看到的是可工作的軟件，那么什么是可工作的軟件呢，對于產(chǎn)品來說，可工作的軟件并不等同于可發(fā)布的軟件，了解用戶故事INVEST原則的同學(xué)都清楚，用戶故事本身就是需求承載的最小單元，是獨立的、可驗證的，所以就單獨用戶故事本身來講，我們希望它是可以被獨立驗收的。從另外一方面，我們希望加強與客戶的溝通（在這個活動中產(chǎn)品人員代表客戶進行驗收），而不是到了最后再與客戶去討論為什么我們做出來是這個樣子，不是他想要的，所以我們通過驗收環(huán)節(jié)讓客戶參與進來，提升客戶的參與感同時，降低了后期溝通成本。

其次，縮短反饋環(huán)，降低修復(fù)成本。對于產(chǎn)品人員來講，開發(fā)隨時完成隨時驗收，確實很容易對其當前的手頭工作造成一定的影響，但是這個時間安排是可以協(xié)商的，我們有碰到做的好的團隊，開發(fā)和產(chǎn)品協(xié)商，上午或者下午固定一個時間點進行當天的故事卡驗收，這樣既不會頻繁打擾產(chǎn)品人員，也不會將驗收的時間拖得太久。從另一方面來講，每當完成一個故事看開發(fā)后，對于開發(fā)人員來講，如果能夠快速的得到確認和反饋，一方面出現(xiàn)了問題立馬可以進行修復(fù)，大大降低了后期修復(fù)的成本，同時也是對于開發(fā)人員前期工作的肯定，試想當你完成一個又一個小的任務(wù)后，被任務(wù)的接受者得到認可，無形中對于開發(fā)人員也是一種激勵，緊接著他又興致高昂的投入到下一個任務(wù)的開發(fā)環(huán)節(jié)中去。

再者，站在產(chǎn)品人員的角度來看，在通常情況下，單個故事卡展現(xiàn)的并非一個完整的需求（當然這個并非絕對，也有部分小顆粒度的需求是可以通過一個故事卡來承載的），所以產(chǎn)品人很容易覺得，既然你沒有做完，為什么要跟讓我驗收呢，等所有的都開發(fā)完成了再一次性驗收不好么？我為什么要投入這么多時間在單個的故事卡上呢？其實這種想法也很正常，大家都不想做重復(fù)的事情。但是我們在倡導(dǎo)質(zhì)量內(nèi)建時，希望能夠盡早的發(fā)現(xiàn)問題、盡早修復(fù)，所以站在這個角度來看，單個故事卡雖然說不完整，但是盡早驗收更利于在早期發(fā)現(xiàn)問題。我們也遇到過類似的情況，在一個完整需求涉及到的3個故事單獨開發(fā)完成后，產(chǎn)品再進行驗收，最后發(fā)現(xiàn)第一張故事卡里涉及的一個接口參數(shù)不合理，而這個參數(shù)的修改，又跟后面的2個故事有一定關(guān)系，幾乎都要有不同程度的改動，如果我們能夠在第一張故事卡完成后就發(fā)現(xiàn)這個問題，我們修復(fù)的工作量是不是大大減少呢？如此帶來的浪費也會大大降低。

最后，想要說的是，要做好用戶故事的快速而高效的驗收，每一個故事卡準確的描述以及清晰的驗收標準（AC）就非常關(guān)鍵，這些都是作為開發(fā)人員高質(zhì)量完成需求開發(fā)和自測的依據(jù)。如果在前期的這些節(jié)點上都已經(jīng)做好了，開發(fā)人員對于這張故事卡要做成什么樣、要達成什么預(yù)期目的也往往心中有數(shù)，避免了在驗收時才發(fā)現(xiàn)，漏做了或者多做了一些功能，降低了雙方溝通的成本。

所以，再從全局角度來考慮，從“產(chǎn)品人員所投入的所有時間+開發(fā)測試修復(fù)的時間”的綜合實踐考慮，花費在驗卡環(huán)節(jié)的時間是不是要比最后再驗收出現(xiàn)問題時再修復(fù)所花費的總時間更少呢？所以要站在團隊角度去看待該問題，到底哪種方式能夠幫助團隊節(jié)省時間，而且有利于保障產(chǎn)品的質(zhì)量的提升，希望能夠給到大家一些思考。