强化自测、验收、联调

1. 高品质、严要求的自测

我在敏捷团队中推行高品质、严要求的自测，团队会编写用于每个迭代任务验收的验收标准，我们统称为AC。每一个被贴在物理看板上的任务卡片，都有对应的AC，这样，开发的同学每天领取对应的任务，完成后，就可以用所对应的AC进行自测，自测完成，通过验收，没有问题后，就在对应的AC后面写上PASS，代表自测通过，没有问题了。当然，对于前端同学来讲，特别是APP，对视觉的要求还是非常高的，在自测的时候还要认真的核对视觉稿，对于字体的大小、位置、色号、是否对齐，色条的色号，整个版面的视觉还原度进行检查，以尽力做到100%的还原。

上图展示子我所带团队使用的纸质版AC，大家可能会疑惑，在电子系统这么发达的当今，为什么还要打印出来，用这么原始的方式，不是在JIRA中，或禅道中，或是excel中、PDF中也可以吗？是的，当然可以，我在这里只是示例，并且我比较追寻敏捷过程中的仪式感，就像JIRA中也有电子看板，但是我还是比较喜欢物理看板，我喜欢那种直观存在的画面感，当然，大家根据自己的项目情况进行因地制宜的调整。

目前，我们在自测阶段依然使用的是纸质版的AC，绝大部分的视觉稿，现在使用的是浏览器打开的电子方式，只有个别部分会打印出来，并非全部，也并非所有团队都这样做，不做为推广的强制性要求。签字承诺，如果在电子系统中可能点击一下就过去了，作为团队的敏捷教练，要根据团队的实际情况进行选择性的调整，孰优孰劣，只有自己知道。不要在意具体的形式，形式只是表象，只要能围绕高品质交付的目标就可以了。

2. 每日事每日毕的验收

我们推崇每日任务每日闭。我们现在的团队中还是有专职的测试人员，目前让研发同学完全胜任开发和测试的双重工作，在我带的团队中，目前还做不到，离真正的敏捷团队、T型人才还有一定的差距。所以，专职的测试人员在团队中依然存在，他们主要负责验收标准的编写，每天已完成任务的验收、全量的回归测试、兼容性和安全性测试。

上图展示了一个团队每日验收的情况，开发人员每天会把自己已经开发完成的任务按照专业测试人员提供的验收标准进行自测，然后把自测完成的任务放入到物理看板的待验收栏中，测试人员从待验收栏中领取待验收的任务进行验收，验收完成后，在对应的验收标准中填写PASS或是FAIL，然后移动已经PASS的任务到已完成栏。对于每天验收发现的BUG，要求开发人员解决完成才能离开办公室，也就是要求，每天不能遗留BUG。对团队成员来说，这是一个硬性的要求，但是，在执行的过程中，如果遇到协同性的BUG，或者是真的太晚，会留到第2天解决。对团队成员的意识性要求是，发现BUG，立马解决，这是一种潜在性的意识性、责任感问题，不能拖拉，有问题立马解决。

3. 被关进“小黑屋”的联调

在迭代开发完成后，以两周10个工作日的迭代为例，在迭代的第7天，所有的开发工作会完成，在进行综合回归测试前，会把所有的开发同学聚集起来，关进“小黑屋”统一进行联调，如下图所示，联调有以下目的：

l  UI视觉联调，以APP开发为例，保证安卓APP页面和IOS APP页面相同，主要是通过同屏显示的方式，参考视觉效果图进行同界面全量对比，保证视觉原稿的还原度，防止出现平台页面效果差或元素不同的情况。

l  流程联调，保证经过一个迭代的开发工作后，APP的主要流程依然是畅通的，关键流程没有出现阻塞不通的现象，所有的开发工作可以控制在有效的影响范围内，不会不知道本次的迭代开发到底影响了那些，无底、无范围的进行盲测。

l  需求点确认，参照本次迭代开发的用户故事列表，核对具体的需求点，一点一点的进行需求还原呈现，确保迭代中要求的功能点都得以准确实现，这一步骤的关键点在于，每一个被实现的功能点都要通过验收标准的多重验证。

迭代开发过程中，为了保证快节奏下的高品质。高品质的开发、自测、验收、联调，对于开发人员来说都不可缺少，环环相扣，每一环节都是为了提升交付品质。此方法在实践中得到了长期检验，可以有效控制BUG的流出，保证开发的品质，作为团队的敏捷教练，在实践过程中可以尝试上述方法，如果能结合自动化测试，并采取更加有效的测试策略，相信可以交付的更好。