Testing “最佳混凝土”；“如何使用手册”；关于*管理*测试驱动和/或敏捷开发？ 我正在寻找一本易于理解的书，以提交给我的上司/团队。

背景信息：越来越多的工作会议让我的老板/团队思考如何在这里实施更多的“最佳实践”。（“这里”=一个非常小的应用程序开发商店。4个开发人员）

以下是我的整个团队都同意我们需要的项目：

• 夜间建造
• 将bug追踪器中的“bug”分解为更小、更具体的项目
• 自动测试

我们面临的问题是如何开始。 我相信，如果我的店铺能够简单地选择一个明确而具体的计划或一套规则，那么其他一切都会到位。现在我们陷入了关于模糊的、感觉良好的想法和听起来不错的流行语的讨论中

请向我推荐您最喜欢的书（或在线资源），其中包含清晰、离散、连续的步骤，用于实施指导TDD或敏捷团队/车间的管理方案

我意识到，除了TDD和敏捷之外，还有其他范式也可以解决这些问题，但我自己的兴趣和偏见指向TDD和敏捷，所以我很乐意利用我的团队对变革的渴望，并将其“推动”到那个方向。或者，如果你强烈反对我的观点，请随便打我一巴掌！我不会生气

正如其他人所说，我认为这些问题的答案最好是当受访者只列出一本书的建议，每个答案。

---

---

谢谢大家。

根据你们的需要，我推荐你们（肯特·贝克）。这本书写得很清楚，实用性强于理论性，并且规定了经过时间检验的方法，以采用敏捷、测试驱动的方法。

这本书实际上不是一本循序渐进的书，但充满了伟大的建议和易于消化的内容：。如果你想进行内部TDD培训，我推荐。我有他们的TDD课程，这让我大开眼界。

我建议你从你同意的开始：每晚构建和自动测试。夜间建造是一件不需要动脑筋的事。对于自动测试，我将从以下内容开始：

• 每个具有新功能的提交都应该至少有一个自动测试
• 修复bug的每个提交都应该至少有一个自动测试，该测试在没有修复的情况下失败，在修复的情况下成功

如果你这样做，你将开始获得经验。有了这些经验，就更容易理解文献中所有的好建议

有很多关于良好实践的好书，但你必须弄清楚什么适合你的团队。

我最喜欢的是

编辑：它完全取代了面向XP/敏捷团队的传统项目管理

---

危险在于，采用现代开发方法，然后用陈旧的项目管理和管理实践扼杀它们

可悲的是，即使是最明确、最具体的计划也会引起争议

我来告诉你什么有效。立即启动TDD。它有界限。这相对容易。你还有一百万个问题

您可以自由地说，“但是夜间构建怎么样？”“使用bug跟踪器怎么样？”

大量的思考可能意味着两件事之一

首先，这可能意味着有人正在用“关注”和“问题”来搅乱局势。有时这真的是对改变的不满，被称为“担忧”。有时这真的是自我崩溃（“我原以为自己很精明，现在有人说我必须改进自己。”）

第二，这可能意味着这个数字大得吓人。因此，不要将此视为“许多新的最佳实践”。把这看作是一些渐进的改进。你并没有从根本上改变自己（好吧，这可能会发生，但不要以此作为你的计划。）

我的经验是，你一次只能做一件新事情。做TDD，直到无聊为止。然后做点别的。通常，在拥有一个健壮的测试套件之后，夜间构建变得显而易见。然后，当这很无聊时，做一些其他小的、渐进的过程改进

一次只做一件事。婴儿步。避免把婴儿和洗澡水一起扔掉。你只想下个月比这个月好一点

---

如果对采用一个小的增量改进存在顾虑，请找出根本原因。谁的自我受到了伤害？谁在担心变化呢？

再加上一个务实的程序员头衔：

好书-看一看，可能适合你的管理需要。

你可以把他印在Henrik Kniberg的书上，它更关注敏捷开发过程，而不是TDD，但它简单易读

敏捷方法不是真正的方法。。。 还有更多的精神。主要内容包括：

• 沟通

• 对变化的反应

• 顾客导向

这可以通过很多方式实现，更重要的是找到自己的方法。如果你想知道这种精神是什么样的，你可以阅读免费的37signals在线书籍

但是有一些步骤你可以开始 这些都不是你必须执行的大规则，但你可以尝试以下方法，看看你的团队是如何运作的：

• 快速站立会议。每天5-15分钟的会议，每个人都站起来，解释他已经完成了什么，需要做什么，以及什么可以阻止他这样做。保持在15分钟以内，人数最少

• 为短期期限设定简单的目标，而不是几周内的大目标

• 组建小团队（3人）并在他们之间分配工作。把他们放在同一个房间里，确保他们至少有半天的时间不间断地工作

• 与您的客户进行许多小的定期审查。不要写规格。Ske