如何逐步引入TDD

一、团队为什么会抵制TDD

（1） 时间压力

由于团队忙于交付，所以团队不可能分心出来执行TDD，因为执行TDD需要更多的时间。所以，团队比较担心投入TDD会进一步影响进度。

（2） 学习成本

TDD不是很简单的就可以使用的，而是需要一定学习的。团队已经很忙了，还要分身学习，这对团队的直觉来说的话，一定是会更进一步降低速率，所以，团队在效果不确定的情况下，一般也不会愿意投入。

（3） 指标压力

团队一旦使用TDD，就要向管理层汇报测试的覆盖率等等，这等于是额外为自己增加了更多的负担。

二、 可能的解决办法

（1） 引入比较擅长TDD的外部资源

因为外部比较成熟的能够执行TDD的团队能够直接将TDD引入，并且带来实际的效果，所以对于团队来说，比较容易看到立竿见影的效果。这样团队就比较容易接受，并且去学习TDD。

（2） 减缓交付速度

如果允许的话，可以通过减缓交付速度的方式来腾出学习TDD的时间。但是有很多团队可能并不具备这样的条件。

（3） 减少浪费的时间

很多团队之所以忙于眼前的任务而无暇分身的首要原因是因为团队本身对于时间的使用不够科学，导致没有时间去提升团队。所以从长远来看，减少浪费的时间这个策略可以更好的提高团队整体的士气以及团队的能力。所以，这个是最为推荐的策略。

这个改善本身需要通过一定的观察，来找到团队的时间浪费点。

不过，以大多数的团队情况来看 ，下面几个方法都可以达到立竿见影的效果。

a. 改善会议

1) 会议召开之前问一下：是否所有的人都要参加，是否所有的人都要参加所有的部分？ 2) 会议召开的时候遵守时间盒 3) 会议召开的时候，不要让大家岔开话题。 4) 会议不要自动充满预约的时间。 5) 尽量减少会议。

b. 引入和强化时间盒

1) 对于一个Junior的程序员需要调查4个小时而一个senior只要几分钟就能够解决的问题，就不要浪费这么多的时间。因此设置时间盒，当一个简单问题超过20分钟无法解决的时候就要询问比自己有经验的人。

2) 比如，交付一个模块的时间也应该有时间盒。在时间盒没有到来之前，需要检查进度（这里有另外一个话题，如何检查进度，简略的说，不要用百分比来统计进度，那个数据没有任何参考价值）。这样可以提前预知什么模块会造成延迟。从而提前采取必要的措施来改进。

c. 减少等待

1) 根据帕金森定律，工作会自动充满工作时间。所以，统计每个人的时间是如何使用的，可以发现，其中的大量等待的存在。所以，减少这部分的等待，可以转化为学习TDD的时间。

2) 在瀑布式开发流程下，等待都是很明显的，比如：需求分析阶段，开发和测试团队基本上出在“无事可干”的状态。开发阶段，测试人员也处在“设计测试用例”状态，可是怎么那么凑巧，测试人员的测试用例设计时间“恰好”和开发人员开发所需要的时间一样呢？所以必然有一方在某个时间段处在等待状态。测试期间，开发人员在等待Bug的出现。

3) 等待还非常的多，不一一列举了。

（4） 改善约束点

a. 团队的交付管道可能会遇到很多约束点。比如：“集成”。这个可以通过度量数据来得到具体数据。可以看到集成过程中每个人的时间是如何使用的。到底有哪里是造成约束的。比如：集成的时候，只有几个人能够在处理集成的操作，其他人只能等待。

b. 改善约束点的方法有很多，包括：拓宽管道，绕过约束点，或者将约束点的操作向前移动。这里也不一一列举具体的做法了。

（5） 提高团队“做入质量”的意识

a. 做入质量是提高成本意识以及质量意识的重要入口。当团队都有这个意识的时候，会自然而然的要求使用TDD。而无需外部要求。所以，这个是长久生效的策略。

b. 为了能够让团队提高这个意识，需要从实际统计数据出发。让团队明白，后测质量带来的问题所在，以及时间浪费。比如，bug的re-open率。以及TDD所带来的数据上的变化。

c. 最重要的是，让团队看到效果。看到效果是团队能够自动吸收TDD的最佳策略。而让团队看到效果的话，不要参考别人的成功案例。团队会找到很多借口，比如：时间不够，人员经验不够等。一定要让团队亲自去感受到TDD的效果。