检查项驱动开发CheckList Drive Development

我找一个木匠订做一个饭桌。几天后，木匠做好了找我验收，我一斧子劈上去，桌子开了个口。我说这测试没通过，你这不防劈。木匠虽然很生气，为了拿到钱还是回去改，这次改成了包铁的。我倒上一瓶稀硫酸给他腐蚀了，说测试没通过，不防腐蚀。如此几次后，木匠终于忍不住和我打了起来，当然我最后也没得到想要的饭桌。

在软件开发中，很容易在进入测试验收阶段的时候产生撕逼的情况。测试、产品、开发，各有各对产品需求的理解，产生分歧很正常。在产生分歧后，返工修改、发现Bug修改，都会导致人力上大量的浪费。我们知道，从提交Bug、修复Bug、验收Bug修复，这个流程非常花费时间。在我以前的一个前端App产品中，差不多要花一半的时间在这个过程中。往往一个冲刺，我们要在一半的时间内完成功能开发，剩下一半用来使功能通过测试。

那么如何解决这种分歧，使开发敏捷起来呢？我们可以采用检查项驱动开发。对UserStory的编写，我们都知道有INVEST原则，其中T是Testable，可测试的。既然UserStory是可测试的，那么产品和测试就可以定义出来这个User Story的测试项目，也就是我们说的检查项。检查项不必像Test Case那么精准，要求每一步做什么期望看到什么，而是可以用简单自然语言描述测试目的即可。这样的描述不精确，但能适应变化。比如对用户登录功能，可能有这么些检查项：三次输入密码错误锁定账号10分钟；账户密码错误给提示；连续三次错误后必须输入图片验证码；有了这些检查项后，开发人员在开发中，就要按照这些检查项要求编写代码，并在测试的时候一一对比这些检查项确定软件符合检查项的要求。当大家都按照统一的标准来执行开发、测试、验收，那么相互之间的撕逼就会减少，发现Bug-修复Bug-验收Bug修复这个过程的次数就会减少，整个的开发效率就会提升。

那么有人会说了，传统PRD也都有这些内容。确实，详细的PRD确实包含这些内容，但PRD的格式导致这些内容散落、隐含在巨量的文档里面，不能精准地体现出来，程序员阅读容易遗漏，也浪费阅读时间。当产品把这些场景都提炼出来，形成简单的检查项，我相信能大大提高团队生产力，也会让大家更加更加和谐，避免流血事件的情况发生。