背景信息： 我们越来越多的工作会议让我的老板/团队思考如何在这里实施更多的“最佳实践”。（“这里”= 一个很小的应用程序开发商店。4 个开发人员）
以下是我的整个团队都同意我们需要的项目：
我相信，如果我的商店可以简单地选择一个清晰而具体的计划或一套规则，那么其他一切都会水到渠成。现在，我们陷入了关于模糊、感觉良好的想法和听起来不错的流行语的讨论中。
请向我推荐您最喜欢的书（或在线资源），其中包含用于实施指导 TDD 或敏捷团队/商店的管理方案的清晰、离散、连续的步骤。
我意识到除了 TDD 和敏捷之外还有其他范式也可以解决这些问题，但我自己的利益和偏见指向 TDD 和敏捷，所以我很想利用我的团队对变革的渴望，并朝那个方向“推动”它. 或者如果你强烈不同意我的观点，请随时扇我一巴掌！我不会冒犯的。:)
谢谢你们。
对于您的需要，我推荐测试驱动开发：通过示例(Kent Beck)。它写得很清楚，比理论更实用，并规定了经过时间考验的配方，以采用敏捷的、测试驱动的方法。
在组合中加入另一个实用程序员的头衔：Ship It！
好书 - 看看，可能适合您的管理需求。
我建议您从您同意的内容开始：夜间构建和自动化测试。每晚构建是不费吹灰之力的。对于自动化测试，我将从：
如果你这样做，你将开始获得经验。有了这种经验，就会更容易理解文献中的所有好的建议。
有很多关于良好实践的好书，但你必须弄清楚什么对你的团队有用。
还有更多的精神。主要是关注：
沟通
对变化的反应
客户导向
这可以通过多种方式实现，更重要的是找到自己的方式来做到这一点。如果您想了解这种精神是什么，您可以阅读免费的 37signals 在线书籍Getting Real。
它们不是您必须执行的大规则，但您可以尝试以下方法，看看它如何与您的团队一起使用：
快速站立会议。每天 5-15 分钟的会议，每个人都站起来，解释他已经完成了什么，需要做什么以及什么会阻止他这样做。保持在 15 分钟以内，人数最少。
为短期期限设定简单的目标，而不是几周内的大目标。
建立小团队（3 人）并在他们之间分工。把他们放在同一个房间里，确保他们有至少半天的时间工作而不会受到任何干扰。
与您的客户一起设置许多小的定期审查。不要写规范。草图、设计、原型、向客户展示、修复/调整/更改然后构建。然后再做一次。
测试、版本控制、错误跟踪是工具，而不是方法。没有人关心你是怎么做的，用什么软件只要你做。他们不是问题。
这不是一本真正的循序渐进的书，而是充满了很好的建议并且易于消化：敏捷开发人员的实践。如果您想进行内部 TDD 培训，我推荐netobjectives。我有他们的 TDD 课程，它真的让我大开眼界。
可悲的是，即使是最明确和具体的计划也可能会引起争议。
我会告诉你什么是有效的。立即启动 TDD。它有界限。这相对容易。你仍然会有一百万个问题。
你可以自由地说，“但是夜间构建呢？” “使用错误跟踪器怎么样？”
大量的思考可能意味着两件事之一。
首先，这可能意味着有人用“担忧”和“问题”搅浑水。有时这真的是对改变的不满，表达为“担忧”。有时这真的很自负（“我以为我很敏锐，现在有人说我必须对我进行改进。”）
其次，这可能意味着这非常大。因此，不要将其视为“许多新的最佳实践”。将其视为一些增量改进。你并没有从根本上改变自己（好吧，这可能会发生，但不要一开始就把它作为你的计划。）
我的经验是，你一次只能做一件事。做 TDD 直到无聊为止。然后做点别的。拥有强大的测试套件后，夜间构建通常会变得很明显。然后当这很无聊时，做一些其他小的、增量的过程改进。
一心一意。婴儿步。避免将婴儿与洗澡水一起扔掉。你想要的只是下个月比这个月好一点。
如果担心采用一个小的增量改进，请找出根本原因。谁的自尊伤痕累累？谁担心变化？
你可以打印Henrik Kniberg的 Scrum and XP from the Trenches，它更关注敏捷开发过程而不是 TDD，但它是一个简单快速的阅读。
查看 Marty Cagan 的书籍。