TDD首先是一种个人行为

我觉得TDD本来就是个人开发寻求提高代码和产品质量的一件工具，没必要一上来就希望一个开发团队都使用他，不说培训练习的成本。就是其他人也未必喜欢用。
敏捷这东西最终还是实践，嘴上说不行，本身就是一个自我改良，不断修订的过程，如果一开始觉得路子不对，那就赶快走人，如果路子有点意思，却还要一直围观就说明问题了，敏捷本身就是一个轻便的方法，也花不了多少成本。
TDD本身也可以用到自身学习上：需要完成某一阶段的列表，执行列表，检查步骤和执行结果，改正，确认工作，下一项任务
自己实践后是好是坏，再去和其他人推介的时候，也才更有说服力

TDD本来就是一种开发的方法，而且是自底向上的，当然要由个人开始

从详细设计开始的
普通程序员就算了吧
除非你能对详细设计说了算

PS:在小公司里很容易达到大公司。。。。。特别是日企

我明白楼主的意思：TDD 首先应该产生于个人需求。

问题是这种个人需求的产生需要环境的督促。我觉得只有在看重质量远大于看重开发进度的公司里，才能促成 TDD，否则，任何推进 TDD 的工作都会无功而返。

我觉得从个人来说，要转变思维方式，习惯“测试先行”这种开发模式。
而从团队、公司的角度，如果不能深刻理解测试的意义，并从实际上支持TDD，否则个人再怎么努力，TDD也是搞不起来的。

有个误解就是TDD一定会影响开发速度。

在刚刚开始实践TDD时，实际上开发团队是在尝试一种新的开发模式。此时不可能有多高的效率，因为大家都在学习，难免磕磕碰碰。但只要坚持下来，自然就会有好的回报。熟练掌握TDD的开发团队，效率只会比以前更高，这一点是我的亲身体会。而且越是需要长期维护的项目，TDD带来的收益就越多。

质量和开发进度有冲突吗？

没学好的项目那是你没看见.....

上头要看的是开发进度，而不是整个项目的进度。

开始使用的时候会影响进度，但是用过之后应该会提高进度了，可是没有公司舍得去试验的这些时间呢！