在软件交付过程中，经常发现大量的网上问题并不是因为测试不足导致的，而是在更早期的需求传递给过程中，产品经理主要是以PRD文档的形式将需求同步给开发和测试人员，后期缺乏频繁和深入的沟通，因此会导致某种程度上大家对需求的理解产生偏差，而导致最终版本上线后产生问题，实际是如果这些差异能够在前期阶段进行对齐的话，是完全可以避免因为需求理解不一致而导致的后续问题。所以组织敏捷转型过程中，有2个基础的活动是我们强烈向团队去建议并进行推广的，这两个活动分别是Kick-off（开卡）和DeskCheck（验卡），这2个活动如果能执行到位的话，由于需求理解不一致而导致产品的缺陷率将会在很大程度上得到控制。
下来我们就来聊聊什么是开卡、验卡？为什么这2个活动有如此大的魅力？
首先，开卡翻译来源于英文中的“Kick-off”一次，直译过来就是开踢，标志着比赛正式开始。后来的延伸含义表示开始做某事。而用在敏捷软件开发的这样一个实践中，则意味着开始启动需求（用户故事）的开发。
实际开卡是一项质量保障活动。通过故事卡责任人讲解，确保团队成员对于故事卡上的需求理解达成一致，避免后期返工。在整个开卡的过程中，建议需要遵守以下规则：
1. 明确准入条件：
用户故事符合DoR定义，该用户故事的验收范围（或验收标准AC）
2. 规范实施过程：
开发人员选择故事卡，就其对于业务的理解、技术实现方案进行讲解，进一步确认AC验收标准、实施细节，团队内达成一致
评估开发完成时间，建议后续的DeskCheck时间
3. 主要参与人员
开发主导，产品、设计、测试参与，ScrumMaster（如非开发人员兼职，可选）
4. 开卡时间要求
建议每日站会后，相关人员一起完成当前需要开卡的用户故事
或者团队约定一个固定时间点，减少对于其他人工作的频繁干扰
10-20分钟
5. 开卡注意事项
开发提前准备，思考对需求的理解
需求讲解的同时关注风险，识别内、外部依赖
测试在故事开卡后同步启动用例设计、写作，确保开发完成后能够进行自测
开发人员对需求的理解、对技术实现的理解
开卡完成后，开发人员就进入到热火朝天的编码环节...，等编码完成并通过开发自测后，我们就要启动另一个活动：验卡。
验卡翻译自于英文“DeskCheck”一词，字面意思是桌边检查，也就是我们对于开发完成的用户故事，就在当事人的办公位旁完成验收。
验卡也是一项质量保障活动，相对于开卡环节，是需求开发完成后第一次的业务验收，确保质量满足AC要求，提前识别问题、解决问题。通常情况下，按照以下原则来实施：
1. 明确准入条件
故事卡完成，并且通过代码检视、开发自测，相关问题已得到修改
2. 规范实施过程
开发人员针对已完成的故事进行演示，产品、设计和测试人员按照AC标准参与验收，验收通过后可转入测试环节
3. 主要参与人员
开发主导，产品、设计、测试参与
ScrumMaster（如非开发人员兼职，可选）
4. 关卡时间要求
故事开发完成尽快启动，时间控制在10-15分钟
或者团队约定一个固定时间点，减少对于其他人工作的频繁干扰
10-20分钟
5. 关卡注意事项
如果验收故事卡还有问题，则提前确认好下一次DeskCheck的时间、人员，如果出现2次以上的验收不通过，需要在本轮迭代回顾上进行分析，提出改进
该阶段发现的问题可以直接反馈给开发进行修改，暂不录入Bug系统
对于DeskCheck的验收时间问题，团队内部可以协商，每天固定站会后、或者其他固定时间完成验收
以上是关于开卡、验卡活动的流程及规范要求，经过大量的实践验证，这2个活动，能够将大量问题在测试介入之前的得到很好的识别和修复，大大降低成本，这样对应了我们质量内建的原则：尽早发现问题，一旦发现立马修复。所以希望团队在落地这2个敏捷实践的过程中，了解其真正的价值，采取科学的方法，解决团队的实际问题，而不是走个过程、流于形式，偏离活动的目标要求，坚持下去，产品质量才会得到有效的保障，而团队也不会在后期疲于应付各类问题。
