浅谈即时验收在敏捷开发中的应用

[注]：这是2008年底写的一篇关于即时验收（即常说的BA sign off）的文章，原文发表于《程序员》杂志。从去年刚开始加入ThoughtWorks，对敏捷懵懂了解，到现在随着经历的增多，对敏捷的了解也有了越来越多的体会。即时验收是敏捷中很小、很容易被人忽视的实践，甚至很多人都不知道。但我参加了几个项目之后，越来越体会到了即时验收的重要性：每当项目中的bug数量明显增多，我都会提醒自己以及团队：是不是忽略了BA sign off这一环节？

 

敏捷软件开发相对于传统软件开发过程，在生产效率、 项目质量、成本控制等方面均有不同程度的改进与创新。这得益于敏捷开发方法中许多好的实践，仅技术相关的最佳实践就有结对编程、测试驱动开发、持续重构与 持续集成等。这些实践可以提高代码质量、提高生产效率，并最终提高项目按时交付的成功率。敏捷实践中还有另外一个比较好的实践──即时验收，它可以尽早检 验代码实现与业务需求是否契合并能协助及时发现、修复并验证bug，从而有效地提高开发效率、保证质量。

什么是即时验收
即时验收也叫BA signoff，是指迭代开发过程中，每个story开发完成以后，开发人员并不马上开发下一个story，而是由BA快速验收测试。如果验收时发现了明显的bug，或者验收条件没有达到，开发人员可以立即进行修改。如此反复，直到BA验收通过为止。
具体说来，其一般步骤包括：  
1.开发人员初步完成story的开发；
2.BA在开发环境进行验收；
3.在BA的快速验收过程中，如果发现明显bug或代码实现没有完全覆盖story中的全部业务逻辑，则开发人员立即修改代码以修复bug、补全业务逻辑。重新从步骤1开始；
4.在BA的快速验收过程中，如果没有发现bug，则开发人员可以提交代码，认为此story开发完成，进入迭代中的下一步骤：产品环境中的测试。
在即时验收过程中，特别强调简单和快速：一是验收直接在开发机器上进行，不需要搭建产品环境；二是BA不需要测试每一个细节，而只关注于story的基本功 能是否实现、开发人员是否无意中漏掉了某些情况、写入story中的验收条件是否全部满足等问题。除此之外，如果发现一些没有写入story中的业务逻 辑，也可以由BA和开发人员甚至客户讨论是否修改。
一般来说，即时验收花费几分钟到十几分钟的时间即可完成。

即时验收与QA测试的区别
即时验收强调的是简单和快速，这是为了与QA的测试区分开来，因为它并不能取代QA的测试，而是对QA测试的一个有益补充。从实践上来看，它与QA测试的区别在于：
1.即时验收是在开发者的机器上（也即开发环境下）进行，而不需要重新部署测试环境（即模拟的生产环境）；
2.BA不需要准备测试用例以及复杂的测试数据，只需通过鼠标点击或其它简单的方式验收。而QA一般需要准备详细复杂的测试用例以及完备的测试数据，按照测试用例的步骤测试；
3.BA发现问题之后，不需要创建bug，直接由开发人员修复。而QA测试一般需要创建bug，通过bug跟踪管理系统进行修复、验证与关闭；
4.从时间上来说，即时验收是在story刚刚开发完成以后立即进行，可以立即收到BA作为用户业务代表的质量反馈。而QA一般会有自己的测试计划，测试会比story的开发完成滞后一定的时间段，反馈也会较慢。

为什么采用即时验收
那么，采用即时验收有什么好处呢？
1.充分发挥了BA对story的业务理解与把握。一般情况下，BA对story了解的更全面、更接近于真实用户。BA可以从业务用户代表的角度对story进行验收，利于检验代码实现是否契合业务需求；
2. 即时验收使得反馈更及时。传统软件开发中，很可能在项目完成以后才能收到客户的反馈，而这时的反馈对开发人员的代码修改来说往往是费时而致命的。敏捷采用 迭代式开发，每次迭代都可以有可运行的产品让客户体验，并根据用户反馈进行及时修改。而即时验收让反馈更及时，频率更高。如果开发现场有客户合作并且愿意 协助进行即时验收，那么用户反馈的效果更好；
3.以最低的成本尽早发现并修复bug。在开发过程中发现的bug是最容易修复的，因为此时代码的逻 辑对开发人员来说新鲜而清晰。及时验收中BA不需要部署测试环境，也不需要像QA一样通过bug跟踪系统创建bug，包括录入复杂的bug主题、重现步骤 以及优先级等。开发人员当时就能明确bug的所在，不需要根据描述重现bug或找QA确认bug。这不仅仅节省了大量时间和人力，也尽早发现了潜在的 bug，并以最低的成本修复，确保了QA在产品环境下测试的代码的基本功能与质量；
4.能够提高代码质量和开发效率。BA的即时验收与QA的测试，双重保证了发现问题和bug，从而有效提高代码质量。通过提前发现并修复bug，减少了后期QA测试阶段发现的bug量，可以减少陷入开发-测试发现bug-修复bug-再测试-再修复的糟糕循环的几率。
即时验收的以上优点，充分体现了它在敏捷开发过程中的重要性。当然，即时验收也有一些问题需要注意：
首先就是把握好尺度。每个story完成以后，可以花费几分钟到十几分钟进行即时验收。从花费的成本与获得的收益来说，是完全值得的。但是如果即时验收花费的时间过长，反而造成时间和人力成本过高，可谓过犹不及。
其次，即时验收不是BA一个人的事情，需要开发人员的支持和配合。双方一起验收，一起讨论交流，会使得验收过程更加顺利并能发现更多bug。
除此之外，分布式团队如何使用即时验收？每一边的分布式团队最好拥有自己这边的BA（事实上绝大多数的分布式团队都有自己这方的BA），保证每个story开发完成以后，都可以进行即时验收。
即时验收在实际项目中的应用介绍

结论
即时验收作为敏捷开发过程的一个重要实践，对提高敏捷开发效率有重要的作用。但是在实际的敏捷开发的实践过程中，有的团队为了节省时间，有意无意间忽视了这一最佳实践。
即时验收的本质是投入尽可能低的成本，收到尽可能快的反馈，尽早的发现并修复bug，从而达到提高生产效率、保证产品质量的目的。希望所有的敏捷团队都能尝试或者坚持（如果已经在使用）这一实践，体验即时验收给项目带来的好处。

可否考虑开发人员自己验收呢？有何利弊？

以前有交叉测试这么一说。不过我想如果有自动测试框架的话，做完一键运行，就知道测试是否有bug。这样即时验收也可以算可有可无的部分了。还有在结对编程中也可以让一个开发人员和一个测试人员配对，那么所谓的即时验收其实也在结对编程中完成了。

我想大概是这种区别吧:
即时验收更关注业务方面的内容，而BA是对业务最了解的,因此让BA来配合验收,
需要实现的业务功能是否都已经实现,已经实现的功能是否跟具体业务流程有偏差等.
QA测试则更关注技术方面的内容,已经实现的功能是否都已正确无误的实现.

开发人员倾向于认为自己做的没有任何问题──而很多情况下是有问题的。
对复杂story，Dev和BA可能理解角度不同，做完后有BA的确认会更好。

TDD甚至100%单元测试，也不可避免地会产生Bug。这些Bug不仅仅是功能性的，也包括对story的理解误差、UI的细节等很多方面。BA不必像QA一样锱铢必较，但是能提前避免许多问题。

“一个开发人员和一个测试人员配对”你是指开发吗？我们没有这样尝试过，会不会浪费QA？

谢谢分享敏捷的重要实践

俺也来分享下俺们对日外包重要实践之双需求评审

大家都知道俺们对日外包，大都是码农滴干活，敏捷啥的俺们就不奢望去高攀了，俺们还是传统姿势：瀑布
大家都知道一般需求最难搞，人家XP要拥抱变化，俺们对日外包当然也要积极响应客户的花样（更多花样才有更多的钱拿嘛）

恩，客户已经准备好了基本设计书，
恩，你以为弄清楚了客户的心思，
于是，迫不及待地让码农们硬上，很快，完事了，
于是，漫长的bug对应期开始了....

痛定思痛，我们开始了对日外包重要实践：双需求评审

详细设计阶段：
1.编写详细设计书之前，评审码农们是否理解了基本设计书
2.编写完详细设计书后，评审码农们写好的详细设计书是否正确反映了基本设计书

coding阶段：
1.coding之前，评审码农们是否理解了详细设计书
2.coding完后，评审码农们写好的代码是否正确反映了详细设计书

这两个阶段的的评审只关注需求，也就是业务
评审也是在码农们机器上进行，也不开bug票，....
总之，强调简单，有效

难道即时验收不是根据验收测试用例的？如果有验收测试用例，开发完全可以作阿。

使用自动化测试用例或者自测试报告，这样的输出是可以评审并且可以不断更新的，是否可以替代即时验收？

我这样想：对于正在做的项目，如果觉得自动化测试(不管啥类型)用例，可以完全替代楼主说的BA的作用，那么就就用自动化测试去做。如果发现不能替代，那么就用两者互相补充。

不过对于在公司内人数较少的BA，我不知道是否能长期稳定的呆在一个项目中。比如某公司里，一个项目做的是管理模块，做到一半，又要开始一个新的数据处理与分析的项目，该BA会不会被抽调到新的项目中相当长的时间，从而导致第一个项目的及时验收无法继续。不知道楼主是否有这样的困扰，怎么解决的？