5

我正在寻找一本易于理解的书来介绍给我的老板/团队。


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

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

  • 每晚构建
  • 将我们的错误跟踪器中的“错误”分解为更小、更具体的项目
  • 自动化测试

我们面临的问题是如何开始。

我相信,如果我的商店可以简单地选择一个清晰而具体的计划或一套规则,那么其他一切都会水到渠成。现在,我们陷入了关于模糊、感觉良好的想法和听起来不错的流行语的讨论中。

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

我意识到除了 TDD 和敏捷之外还有其他范式也可以解决这些问题,但我自己的利益和偏见指向 TDD 和敏捷,所以我很想利用我的团队对变革的渴望,并朝那个方向“推动”它. 或者如果你强烈不同意我的观点,请随时扇我一巴掌!我不会冒犯的。:)

正如其他人所说,我认为当受访者每个答案只列出一本书推荐时,这些问题的回答最好。


谢谢你们。

4

9 回答 9

3

对于您的需要,我推荐测试驱动开发:通过示例(Kent Beck)。它写得很清楚,比理论更实用,并规定了经过时间考验的配方,以采用敏捷的、测试驱动的方法。

于 2008-10-08T18:04:58.510 回答
3

在组合中加入另一个实用程序员的头衔:Ship It!

好书 - 看看,可能适合您的管理需求。

于 2008-10-09T02:45:49.550 回答
2

我建议您从您同意的内容开始:夜间构建和自动化测试。每晚构建是不费吹灰之力的。对于自动化测试,我将从:

  • 每个具有新功能的提交都应该至少有一个自动化测试
  • 每个修复 bug 的提交都应该至少有一个自动化测试,没有修复就失败,修复成功

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

有很多关于良好实践的好书,但你必须弄清楚什么对你的团队有用。

于 2008-10-08T18:56:05.520 回答
2

敏捷方法并不是真正的方法......

还有更多的精神。主要是关注:

  • 沟通

  • 对变化的反应

  • 客户导向

这可以通过多种方式实现,更重要的是找到自己的方式来做到这一点。如果您想了解这种精神是什么,您可以阅读免费的 37signals 在线书籍Getting Real

但是您可以从一些步骤开始

它们不是您必须执行的大规则,但您可以尝试以下方法,看看它如何与您的团队一起使用:

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

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

  • 建立小团队(3 人)并在他们之间分工。把他们放在同一个房间里,确保他们有至少半天的时间工作而不会受到任何干扰。

  • 与您的客户一起设置许多小的定期审查。不要写规范。草图、设计、原型、向客户展示、修复/调整/更改然后构建。然后再做一次。

  • 测试、版本控制、错误跟踪是工具,而不是方法。没有人关心你是怎么做的,用什么软件只要你做。他们不是问题。

于 2008-10-23T12:11:43.990 回答
1

这不是一本真正的循序渐进的书,而是充满了很好的建议并且易于消化:敏捷开发人员的实践。如果您想进行内部 TDD 培训,我推荐netobjectives。我有他们的 TDD 课程,它真的让我大开眼界。

于 2008-10-08T18:38:21.703 回答
1

可悲的是,即使是最明确和具体的计划也可能会引起争议。

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

你可以自由地说,“但是夜间构建呢?” “使用错误跟踪器怎么样?”

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

首先,这可能意味着有人用“担忧”和“问题”搅浑水。有时这真的是对改变的不满,表达为“担忧”。有时这真的很自负(“我以为我很敏锐,现在有人说我必须对我进行改进。”)

其次,这可能意味着这非常大。因此,不要将其视为“许多新的最佳实践”。将其视为一些增量改进。你并没有从根本上改变自己(好吧,这可能会发生,但不要一开始就把它作为你的计划。)

我的经验是,你一次只能做一件事。做 TDD 直到无聊为止。然后做点别的。拥有强大的测试套件后,夜间构建通常会变得很明显。然后当这很无聊时,做一些其他小的、增量的过程改进。

一心一意。婴儿步。避免将婴儿与洗澡水一起扔掉。你想要的只是下个月比这个月好一点。

如果担心采用一个小的增量改进,请找出根本原因。谁的自尊伤痕累累?谁担心变化?

于 2008-10-08T21:01:19.713 回答
1

你可以打印Henrik Kniberg的 Scrum and XP from the Trenches,它更关注敏捷开发过程而不是 TDD,但它是一个简单快速的阅读。

于 2008-10-23T11:51:21.537 回答
1

查看 Marty Cagan 的书籍。

于 2014-12-18T22:12:16.673 回答
0

我最喜欢的是规划极限编程

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

危险在于,采用现代开发方法,然后用过时的项目管理和行政实践扼杀它们!

于 2008-10-08T19:17:27.677 回答