推行@H_404_3@ TDD @H_404_3@成效不彰，充斥着似是而非的言论；@H_404_3@TDD @H_404_3@造成额外工作量，@H_404_3@TDD @H_404_3@ 没有效益，@H_404_3@ROI @H_404_3@太低@H_404_3@……@H_404_3@
@H_404_3@为何会如此？我的观察是@H_404_3@……@H_404_3@

“@H_404_3@大家都把开发人员当贼看@H_404_3@……@H_404_3@认为只要是代码有缺陷，架构腐败，都认为是开发人员搞的，都认为是开发人员没有质量意识，千错万错都是开发人员的错。@H_404_3@”@H_404_3@

@H_404_3@大家试着同理心去想想，当大家都将开发人员当贼看时，我们又怎能会有一个合理的说法，去说服开发人员做@H_404_3@ TDD@H_404_3@？我们又怎能会有一个激情的动机，去驱动开发人员做@H_404_3@ TDD@H_404_3@？@H_404_3@
@H_404_3@另外一方面，@H_404_3@TDD @H_404_3@ 最大的限制在于@H_404_3@: TDD @H_404_3@只能反馈，由开发人员所认知的需求是通过或没通过测试。然而，在许多失败的项目中，我们往往会发现，开发人员所认知的需求与使用者所认知的需求，存在着相当大的差距的。也就是说，由于在需求上所存在的认知上的差距，而导致项目的失败，是无法用@H_404_3@ TDD @H_404_3@来弥补的。@H_404_3@

@H_404_3@
@H_404_3@所以，@H_404_3@TDD @H_404_3@要推行成功很简单，不外乎@H_404_3@……@H_404_3@
@H_404_3@1. @H_404_3@用同理心去对待，去尊重开发人员。@H_404_3@
@H_404_3@2. @H_404_3@誏真正的领域专家@H_404_3@（能从使用者的角度，将需求以领域知识的方式体现）与开发人员协同合作。@H_404_3@
@H_404_3@3.@H_404_3@ 将只会写代码，而不会测试的开发人员，归类为 @H_404_3@“@H_404_3@资料写作人员@H_404_3@”@H_404_3@；即使他（她）的技术再牛逼。@H_404_3@