我正在一个团队，我试图说服我的队友采用TDD（因为我已经看到它在我以前的团队中工作，并且设置类似）。另外，我个人认为，至少在开始时，如果TDD和结对编程都是一起完成的话，这确实有帮助。这样，两个没有经验的（在TDD中）开发人员可以互相帮助，讨论要编写哪种测试并取得良好进展。
另一方面，我的经理认为，如果我们一次在团队中引入两个新的开发实践，那么两者都很可能会失败。所以，他希望保守一点并介绍任何一个。
我如何让他相信这两者都是互补的而不是正交的。或者我错了吗？
答案 0 :(得分：13)
我不确定是否有更多人不知道他们在TDD中做了什么会有所帮助。它会很快进入你们两个人的谷歌搜索主题，或者你们俩都在争论TDD究竟是什么/不是什么。
我认为你最好让团队中的某个人成为某种特定技术的传播者（有人去读TDD，有人去阅读配对编程）并让这些人进行推广和试用那些事。是的，两者都可以同时发生，但不必在整个项目团队中使用。你可以让你的团队中的一小部分人进行编程，然后报告他们的经历。
答案 1 :(得分：9)
答案 2 :(得分：7)
建议他们在TDD上阅读这些书：
Michael Feather's Working Effectively with Legacy Code
Kent Beck's classic Test-Driven Development - By Example
Gerard Meszaros' xUnit Test Patterns - Refactoring Test Code
Test-Driven Development in Microsoft .NET
或结对编程中的这些网站：
Pair Programming (Wikipedia)
Corey Haines
Pair Programming Illuminated
答案 3 :(得分：2)
你绝对正确的是，配对编程在学习新东西时会有很大的帮助。我同意你的意见，你应该努力做到这两点。
也许为你的经理提供最好的方法并不是说你要求同时介绍这两件新东西。相反，建议您认为开始实施TDD的最有效方式是，在完成工作的同时，只需要两名开发人员作为“TDD调查团队”，让他们共同努力，以便设置适当的工具，学习技术，测试它们，并找出在环境中应用它们需要做什么。一旦你有了这个工作，并有两个人有一点经验，然后让他们分开，每个人与另一个开发人员坐下来几天，让其他开发人员加快新技术的速度。重复，直到所有开发人员都学会了TDD。
答案 4 :(得分：1)
你没说服力。告诉他你认为两者合作的原因，可能会提供一些证实这一点的数据，并让他做出决定。如果你需要说服每个人这是一个好主意，我敢打赌，没有人会把它当作太好看。自然的反对。
答案 5 :(得分：1)
就我个人而言，我发现配对编程最适合经验丰富且缺乏经验的人。
即我的目标是在程序员的技能/ exp上有所不同，而不是试图均衡地匹配技能。
越有经验的人从解释中获得更多的东西，被迫构建思想，而没有经验的人有机会反弹想法并选择“最佳实践”。
至于TDD，我是个粉丝。 exp再次帮助缺乏经验的人，因为它有助于真正突显测试的重点。即你不想测试绝对的一切......它增加了焦点。我经常发现人们在编写测试而不关注他们想要实现的目标。单位测试是必不可少的...毕竟，有些工作人员不会在2年内到达那里。如果没有什么可以验证其功能，你如何改变现有代码？
答案 6 :(得分：0)
那么，根据经理的说法，你可以在XP文献中指出这些实践相互依赖的一些论点。例如，如果您没有可靠的单元测试，请不要无情地重构。
我建议你逐步接近它，因为配对只是为了计算TDD，就像任何协作努力解决一个新的难题，而不是“所有生产开发都将成对完成。” / p>
答案 7 :(得分：0)
虽然一种做法不需要另一种做法，但有一种“偷偷摸摸”的方式可以一次引入一点点。
首先使用一个可用的xUnit框架实现TDD。找一个兼容的同事，并询问他们是否愿意每天约一小时愿意与你合作。 “肖恩，我正在尝试这个新工具，你会帮助我确保我做得对吗？”效果很好。
与肖恩呆了几天后，和苏珊一起重复......
答案 8 :(得分：0)
无论如何都要这样做。如果经理抓住你配对，请说出“Code Review”的神奇字样 假设：显然，该对应该受到纪律处分/集中注意力，并在会议结束时生成工作代码
答案 9 :(得分：0)