上一集，我们讨论了如何让团队实施TDD，也就是用微测试来发展他们的代码。让一个团队实施TDD非常有帮助，因为这样展示了TDD的实施不仅可行，而且很有价值。下一步是如何让整个组织采纳实施TDD。没有组织的接受，在管理层或者产品负责人更换的时候，TDD就有可能被否决。这种事情随时都有发生：团队自己发现了新事物的价值，管理层换人了，不理解团队的做法，于是开始干预，并停止了相应的做法。所以，组织的采纳是对TDD未来价值的确认。这样能使TDD成为公司文化、雇佣政策和职业路径的一部分。在一个团队成功展示了TDD的价值之时，就是全面实施TDD的时候了。
步骤一、让顶层人员熟悉相关情况
包括有关的管理人员、架构师以及产品负责人
管理层应该了解实施TDD需要的付出和会有的回报，这样他们就不会以负面的形式进行干预。开发人员最不喜欢实施TDD时的不确定性。挑战包括让管理层、架构师和产品负责人熟悉TDD时，这三类人群有着完全不同的需求和对TDD不同的看法。因此，传递的消息、目的和技术对话的效果都应当有所不同。
步骤二、进一步实施
开发者需要学会如何使用单元测试库，如何重构代码，如何设置连续整合服务器，以及如何采用先编写测试的设计。这些在起始阶段都会减慢开发者的速度。即使管理层已经作出了决定，开发人员也会按照自己的想法接受或者反对TDD。虽然并不需要每个人的同意，各团队需要40%到60%的开发人员有使用TDD的意愿。增加甚至长达数年的学习激励，可以让态度“还不明朗”的开发者开始先试用TDD几个月。根据我的教练经验，这足以使TDD新手变得熟练。
我见过较好的实施方法包括，副总为每位开发者分配奖金，团队的领头人负责确立一些可实现但又有挑战性的TDD实施目标。这样，也就确定了微测试数量的目标。如上一集提到的40/4挑战一样，目标是需要在两三个月的时间段里，让开发人员实现熟练掌握TDD的效果。
步骤三、设置标准
设置标准会成为团队对任务完成最低的定义。一种便捷的方式，就是让标准透明可见，容易通过连续整合展开。下面是一个例子：
* 拥有一台连续整合服务器
* 服务器必须执行编译步骤，并让其可见
* 服务器必须执行微测试，并让其可见
* 服务器必须执行微测试的代码覆盖率评估，并让其可见
* 服务器必须执行宏测试，并让其可见
* 不能交付未通过测试的代码
* 服务器必须执行设计负债，并让其可见
* 新代码必须有90%的代码覆盖率
最后的一项对有大量历史遗留代码的情况较为困难，需要花费数年甚至数十年的时间来达到90%的代码覆盖率。因为任何理由都不可能让我们一切都从零开始来重写代码。添加到历史代码库的新类应该有很高的代码覆盖率，但是在用连续整合服务器实施检查时会较为困难。
步骤四、可持续的系统
雇佣政策需要直接地针对熟悉TDD或是对学习TDD持开放态度的人。在目前的情况下，招聘反对TDD的开发人员是不合适的。这样的招聘行为只会导致他们与同事之间的压力，以及增长整个组织负面的状况。因此，可以把TDD和结对编程作为面试的一个步骤。在实施级别薪酬的组织里，把测试自动化和代码重构作为确定级别的一部分指标。
下一集，作为开发者，如何熟练掌握TDD？
