Answers:
您的团队成员是否真的同意代码审查和单元测试是件好事，只是没有时间了？
还是他们只是以此借口拒绝这个主意？
在第一种情况下，解决方案是立即开始做。（好吧，如果您处于重要里程碑之前的最后几天，也许您可以等到之后才开始-但再也没有。）我们在我以前的工作场所遇到过这种情况，我是质量工程师，负责改善编码实践并总的质量。我们一直将代码审查的开始推迟到下周。有一天，我意识到我们已经做了一个月左右的时间，除非我尝试其他方法，否则可能会一直持续到最后。因此，我宣布了该周的首次代码审查。我告诉大家“没问题，如果它不完美，或者我们还不完全知道该怎么做，我们将立即开始做，看看它会如何发展，并在我们学习的同时改善自己的状况”。至少在我离开公司之前一直奏效。
在第二种情况下，您可能需要更多的教育和与团队进行公开讨论。讨论代码质量问题，询问他们在开发过程中（或缺少这些问题）/在代码/测试等中所看到的问题。并共同讨论如何解决这些问题。最终目的不一定是进行代码审查-只是手段，而目标是改善开发过程和其输出质量。事实证明，还有其他更痛苦的问题可以更轻松地加以改善，更快地带来更多利益；然后先拿这些。它们甚至可能是环境或过程中的琐碎变化。所有这些都将改善团队士气，建立相互信任并帮助团队凝聚力。
最重要的是，您不能对任何人强加质量-您只能消除创造质量的障碍。通过在团队事先未达成共识的情况下执行严格的规则和强制性措施，您可能会疏远团队并最终阻止您期望的质量改进。OTOH通过公开讨论并就团队面临的最紧迫问题以及如何改善情况达成共识，您更有可能获得团队的支持。从长远来看，这将在保持质量改进动力方面发挥关键作用。
经典问题。没有足够的时间来正确地做它，总是有足够的时间来重做工作。在人们开始采取最佳做法之前，似乎永远没有足够的时间进行最佳做法。特别是因为胜利对发展之外的人是看不见的。
代码审查的关键是您希望尽快审查尽可能少的代码。这样一来，您就可以更轻松地花费时间进行审查，使代码变得新鲜，并且可以轻松实现建议的改进。在极端情况下，您要检查每个签到。http://code.google.com/appengine/articles/rietveld.html就是一个自动化的好工具。这是Google内部使用的一种工具变体，可在每次签入时强制执行代码审查。
几十年前，经典的“计算机编程心理学”中描述了代码审查的挑战。问题是程序员倾向于将自己的形象与编程技能联系在一起。这意味着，每当程序员面对证据表明他们的技能没有达到标准时，就有一种将其个人化的趋势。这可能导致严重的冲突。如果您选择了史蒂夫·麦康奈尔（Steve McConnell）的经典《快速开发》（Rapid Development），他将为您提供许多有关如何建立代码审查过程的建议，以减少此类冲突的可能性。（一个关键要素是确保管理过程中永远不要参与任何事务。）请注意，这减少了冲突的可能性，但并不能防止发生冲突。
也就是说，收益远远超过成本。仅举一个指标，IBM发现代码审查是一美元一美元的查找和消除错误的最有效方法。这不会以任何方式取代您的质量检查部门。但这导致他们发现的问题少得多。而这是在您获得收益之前，它涉及到如何加快学习速度，传播知识等。
不要给他们选择。强制进行测试和审查。如果他们不合作，则可以采取强硬手段，例如拒绝未经测试或未经审查的促销活动。如果情况真的很糟，请解雇最严重的罪犯。
我已经看到了一些团队总是落后于计划的情况，因为他们总是在修复应该由测试和审查发现的错误。从长远来看，更多的工作可以节省更多，而您越早使团队加入团队，团队就会越好。
不幸的是，这可能需要一些时间才能真正看到结果。为了鼓励这种做法，您可以开始绘制错误报告率，错误修复平均时间和功能实现率的图表。我通常会发现，经过大约六个月的测试和审查，这些指标将得到改善，您的团队最终将获得它。