我喜欢 Hudson 进行持续集成构建，喜欢 JIRA 进行问题跟踪。 Eclipse 两者都有插件。
Hudson 可以监视软件存储库并重建那些使用更改的资源的项目。
如果您需要的文档超出了 javadoc 所能涵盖的范围（数量相当多），那么请考虑 Wiki。易于使用，只需一些结构，您就可以将其合并为 PDF。
源代码控制是个麻烦事。太多可供选择。对于小型开发团队来说，从 subversion 或 CVS（虽然很旧，但具有最高的 IDE 支持）开始，当您不再需要这些并了解您的需求时，然后迁移到更好的。大多数都有来自 svn 或 cvs 的迁移工具。很难从例如git 到 Mercurial，您肯定想要一个具有多个实现的版本。请记住对源代码控制存储库进行良好的备份 - 这是您的事。频繁的 rsync，通常是磁带。
编辑：您还需要像样的硬件。对于持续集成服务器，您可以负担得起的最快的构建机器。对于您自己来说，您可以负担得起的最大显示器（不是尺寸，而是分辨率）作为您的主显示器，以及您可以负担得起的尽可能多的额外显示器（包括计算机的适配器）。我发现 Mac 比 Windows 更好地使用像素，所以这也可能是一个问题。
我的主显示器旋转 90 度。这使我可以一次看到很多行而不是几行。 （出于某种原因，传统上认为编辑区域应该宽而短，这可能适用于 Word，但不适用于代码，因为行的宽度不应超过 72 个字符）
关于 Eclipse 的注意事项：使用源存储库让每个项目都有一个工作区！每次保存时，使用 Java 编辑器保存功能重新格式化代码 - 这使得代码预先更具可读性，并且可以更好地与源存储库配合使用，因为更改会标记在正确的版本中。
编辑：CI 服务器需要比您的开发机器更好的原因是因为每次您将内容签入源存储库时它都会运行所有测试。一段时间后，这将需要时间。
就我个人而言，我发现测试对于库例程效果很好。他们指定什么有效，什么无效。为整个应用程序编写良好的测试比较困难，但您可能需要从一开始就进行研究，因为它可以让您确保每次签入时一切正常。如果您不熟悉这个概念，请写下评论。
无论您为各个部件选择什么，如果它们能够协同工作，您都会很高兴。例如，Hudson 知道如何与 JIRA 交谈。 JIRA 知道如何查看 CVS。
