3.5 提议一些策略，来填补团队要成功地建立产品所需缺漏的技能或能力
验收测试驱动开发（ATDD, Acceptance Test Driven Development）
我们日常的软件开发中，大多数的问题都来自于需求不清晰。开发带着对需求模糊的理解开发，很多东西做的模棱两可，经不起推敲，到测试就会暴露一部分问题，有些可能还会遗漏到线上。由于需求不清晰而造成的返工和浪费，占很高的比例。
如何能够提高需求的清晰度，在开始写代码之前，让整个团队在需求层面达成一致的理解，ATDD是一个比较好的方法。但这个能力大部分团队都不具备。那么，如何使团队逐步建立起这个技能呢？近年来，在工作中不断摸索，做了一些尝试。
使用ATDD的方式来澄清需求，大致的过程如上图，包括几个步骤：
1. 从目标中获取范围
2. 协作制定需求说明
3. 举例说明
4.提炼需求说明
5. 自动化验证时不修改需求说明
6. 频繁验证
7. 演化出一个文档系统
在实践中，我发现团队的主要困难和问题有如下几点：
1. Backlog梳理会没有效果，基本上是走过场，讨论的比较粗，需求共识也是比较粗粒度的共识，落在开发上很多需求模棱两可，开发可能就按自己想当然的方法实现了
2. 测试用例管理比较乱，逻辑结构不清晰，不能体现产品功能的具体逻辑关系及相关场景的验证
3. 自动化程度不够，先写代码后写测试，导致测试并不能体现业务逻辑，而更多的是技术角度的验证
通过解决以上问题，把整个团队的节奏建立起来，形成一个正向的循环。
针对三个问题，分别分三个方面来进行：
1. Backlog梳理会：
1）通过培训和分享，使团队认识的到需求清晰的重要性
2）通过跟踪一个具体的项目，分析每一个返工，使开发人员看到，这些返工大部分都是由于需求不清晰导致的
3）设计一个Backlog梳理会的议程， 并反复引导，直到团队熟练
4）在讨论需求时使用实例化需求的方法，哪怕一个迭代只有一个需求这样做
5）培养Scrum Master能够独立引导Backlog梳理会，辅导并随时给予反馈
2. 规范测试用例
1）测试人员共创测试用例标准
2）用例库和执行分离
3）用例库管理比较好的团队样板
4）每个团队的用例走查
5）辅导、交叉学习、人员轮换，逐步磨合形成测试用例标准执行的一致性
* 与编写用例的人有关，与逻辑思维能力有关，可能是复杂的网状结构，需要特别清晰的思路
3. 自动化工具支持
1）用例管理系统与自动化测试管理一致（功能测试与自动化测试都是测试用例，在管理上一致，只是执行方式不同）
2）用户故事与自动化用例关联
3）验收条件Given-When-Then可执行
4）支持回归
5）收集用户反馈
6）辅导
除此之外，这个工作本质上改变的是开发测试人员的工作思维和习惯，需要很长的时间来改变。
1）从小的开始，需要有一些练习，辅助建立ATDD的能力，形成肌肉记忆，才能将这个能力应用于实际的工作
2）积累起来形成良性循环
3）形成一定的良性循环之后，在Backlog梳理时就建立可执行的Given-When-Then（失败的），成为真正的ATDD
4）建立业务、开发和测试充分协作的工作环境
团队要成功地建立产品所需缺漏的技能或能力，常见的还有：持续集成
