开卡（Kick-off）和验卡（Desk-check）是2016年我在ThoughtWorks University做教练时，学到的实践。
这两个迭代开发中进行质量内建的重要实践，能让团队“投资少见效快”地持续纠偏和又快又好地交付软件。
做开卡和验卡前，要做好如下准备工作。
在迭代开发的需求梳理会上，团队讨论下一迭代的用户故事，拆分故事，编写验收条件（主流程）和测试用例（全部流程，包括主流程）。
这些验收条件和测试用例，就是开卡和验卡的物料。
开卡过程
- 开发人员每次开始为一个新用户故事卡编写代码前，自己阅读该故事卡的用户故事、验收条件和测试用例，思考其中的疑问点和风险，并记录下来。
之后请来相关的需求和测试人员，三人当面澄清和讨论这些疑问和风险。
此时，需求和测试人员，可以请开发人员用自己的话，讲述一下这些验收条件和测试用例，确保三方理解一致。
为什么要请开发人员讲验收条件？因为怕“知识的诅咒”——需求和测试人员自己很理解验收条件，也天然地认为开发人员也同样能理解。但事实却经常恰恰相反。
况且需求和测试人员之间，也会出现对验收条件理解上的差异。所以让开发人员自己讲一遍，也会启发需求和测试人员发现他们之间的理解也是不同的。
开卡由开发人员驱动，针对其将要编写代码的一个故事而做，而不是团队一起开会开卡，这能提高什么质量？
这能提高开发人员对于故事卡的需求的思考质量。
因为开发人员马上就要写代码了，会比团队需求讨论会的思考更深入，因为那时候还不知道谁要开发哪个故事卡。
为什么开卡能解决网上程序员最怕产品“改需求”的段子中所说的矛盾？
因为这些段子中的矛盾，往往源自程序员在写代码前，没有做开卡确认，而是基于对需求错误的理解编写代码，能不出错吗。
开卡能降低什么成本？
开卡能降低修改代码的成本，因为“改需求”的成本在代码编写之前趋近于零，而在代码编写之后会急剧上升。
开卡能在编写代码前澄清最新的需求，减少改需求的几率和成本。
若需求和测试人员在开卡过程中，发现之前编写的验收条件和测试用例有问题，则立即修复。
开发人员完成开卡后，就把卡片从看板的“本迭代待办项”移至“开发中”，并贴上自己的头像。
验卡过程
- 开发人员每写完一个用户故事的代码，并在“非本地”测试环境上测试通过，则找到需求和测试人员，按照验收条件，为他们进行演示（即验卡）。
为什么一定要在“非本地”环境验卡？
程序员的另一个段子是：“啥？在测试环境上运行不了？可刚才明明在我电脑上运行的好好的。”
环境的差异也需要解决，所以验卡要在“非本地”环境进行。
验卡应该是由开发人员驱动，针对其刚刚编写完代码的一个故事验卡，而不是一次验多个卡。这能提高什么质量？
能做到持续纠偏，又快又好。
这能省什么时间？
能节省一次验多个卡所发生的等待时间。
- 若验卡时发现问题，开发人员立即修复。这能省哪4个时间？
- 能省测试人员在系统中记录和跟踪软件缺陷的时间
- 能省开发人员在系统中阅读软件缺陷的时间
- 能省开发人员切换思路进行修复的时间
- 能省开发人员很晚才返工所耽误的时间
开发人员修复完成后，再次验卡。测试人员对于验卡所发现的问题不必在系统中记录软件缺陷。
若在非本地测试环境验卡时，未发现问题，则开发人员将故事卡移交测试人员进一步进行测试，并把卡片从看板上“开发中”移至“待UAT测试”一列。
想要“投资少见效快”地提高软件开发团队代码质量，优先尝试开卡和验卡。
