我的开发团队仅增长了100％（从1个开发人员增至2个）。我的新成员想投资Bug跟踪软件。这样小的团队对于这种软件有好处吗？

我认为所有“是”的答案都对认可该想法大有帮助。但是我将放弃这一决定是基于以下几个问题的想法：

• 您想如何以团队沟通？ 现在有2个开发人员，您现在成为一个团队。您想如何交流？大量敏捷团队随身携带讨论和白板草图。但是他们也可能会写下一些东西，特别是如果它是一个在一段时间内不在优先级列表中的错误的bug。
• 您想如何与客户沟通？我不知道这个答案，但是如果您有任何理由要发布错误（或版本发布文档中的已修复错误），那么最终将最终把它们写下来。最好选择一个低压力的错误管理系统并完成它。
• 保存历史是否有价值？ 答案可能是“不是现在”，但是如果您认为将来会希望看到错误的趋势，那么您可以查看用户遇到问题最多的地方，或者可以花一些时间检查的地方并在主要版本发布之前进行审核-然后获得错误跟踪系统。关于历史的事情是，您想要记录的日期不是您应该开始保存记录的日期。

IMO，这些问题的答案更多地是关于您看到产品走向何方以及如何发展团队的，而不是关于“ 2个人=错误跟踪系统的原因”。更大的问题可能是“错误跟踪系统是否值得配置和管理以及购买成本？”

1，但前提是无痛。例如，GitHub有一个非常简单且可用的问题跟踪器，为一个小型团队提供了足够的功能。Bugzilla，Trac或其他工具都不错，但是它们都需要硬件，安装和配置才能使用，而且维护费用绝对是非零的。

第一次使用错误跟踪软件时，我们的团队非常小，我惊讶于我们一直认为需要修复多少东西，而这些问题从未得到解决。无论您的团队多大，这都是完全值得的。

是。是一千次。

甚至不要将其视为错误跟踪，而应将其视为票证跟踪。

能够查看故障单中的所有任务具有巨大的优势。您可以将一项任务的历史记录保存在一个地方。您知道谁在何时进行此工作。您可以说出在某天完成某项任务的详细程度。

对于错误跟踪，您可以将所有错误放在一个地方，并跟踪已完成的错误和仍在进行的错误。

它可以帮助您更好地管理事情。

一个或多个团队是值得的。

面对现实，无论您是否购买正式的软件解决方案，您都将拥有错误/功能跟踪系统。它可能在记事本中，可能是即时贴，也可能在代码顶部的注释块中。但是，除非您只是随机开发，否则您将在某个地方写下您的待办事项清单。为什么不使用可以与您的团队一起成长的更有组织的系统？

还值得考虑的是：许多错误跟踪器可供很小的团队（1-2）免费使用，因此这并不意味着您为此付出了大笔费用。

只要团队中的每个成员，您都不需要任何错误跟踪软件

• 具有完美的摄影记忆，并且
• 可以将他们的想法与团队中的每个其他成员保持同步。

简短的答案是肯定的。

原因如下：

1. 能够记录针对特定版本发现的错误。
2. 知道哪些（已知）错误尚未修复的能力。
3. 跟踪谁修复了此错误，此错误已被再次发现。
4. 开发人员周转率-允许知识转移，即使您遇到了麻烦。

您可能希望查看不需要花费很多时间进行设置/管理的内容。我还建议您寻找一种包含将其与源代码控件集成的功能的东西。

该答案是在参数的“是”侧增加权重。

我主要是一个团队。我将问题跟踪（redmine）与SVN集成一起广泛使用。

它确实很棒，没有它我会发疯。我的质量会下降，因为我会忘记一些事情，而我会松懈地跟踪需要做的事情。

生产力工具：

• 体面的IDE
• 问题跟踪
• 源代码控制

问题跟踪; 不要没有它就离开家

如果您少于3个，那么我想也许可以使用google docs电子表格。但是，实际上，在某个地方安装bugzilla或类似工具的成本与程序员的成本非常之低，以至于您最好这样做。（另外，当您增长到7岁时，它已经存在了）

即使是一个团队，也可以从某种错误跟踪器中受益，无论是注释文件的文本文件，还是某些功能全面的软件。对于2个开发人员，我建议仅花时间建立一些错误跟踪系统，而不要花钱。根据项目的不同，您可以通过在纸上写下错误，通过共享的在线文档维护列表或使用免费的错误跟踪软件（例如Trac或Bugzilla）来获得良好的结果。Fogbugz还可以免费试用45天。

是。

您需要跟踪它们的方式！

问题是您有多少个bug，而不是多少个开发人员。在处理一些bug时，您可以使用excel表进行管理，但是即使那样也不是最好的。

有明确的好处-即使在个人项目上，我也使用错误跟踪软件。它不仅对跟踪错误有用，而且对跟踪“ TODO”和功能请求也很有用。

我一个人工作时到处都用过bug。通过将错误信息与源保持在一起，它可与DVCS一起使用。由于不需要中央服务器，因此开销非常低。缺点是您必须小心，将新错误输入到哪个分支中以确保它们及时传播，尽管如果您最想跟踪自己的错误以及最新拉动中已解决的问题可能并不重要。而不是整个团队的状态。

刚开始使用一个

如果您只是开始使用它，那么您将开始在实践中体会到它们的便利性，就像版本控制软件，或分布式版本控制一样。

发展成熟度

不管您的团队人数是100还是1，我都只为自己使用错误跟踪和分布式版本控制（由于本地提交而有意义），而我已经在另一个层次上感到了，但是唯有如此，我才可以在另一个层次上管理我的工作……而无需投入更多精力就可以达到一个可以扩展的水平。

通过使用跟踪器，您可以预见问题并确定工作的优先级，错误/问题跟踪器不仅适用于错误/问题，还适用于项目管理，每个项目都应具有此功能。

对我来说，这不仅与软件有关，而且与软件有关。在担任测试经理的日常工作中，我基本上生活在其中，它提供以下好处：

我发现这对于2个以上的测试人员和3个以上的开发人员确实非常有效。

开发人员错误修复工作的管理

我们积极管理开发人员的“错误队列”，以控制他们分配给他们的工作量，并确保我们在团队中对错误修复工作进行平均分配。

确定什么可以解决，什么不能解决

在日常流程中尝试新的错误是一种很好的方法，可以帮助您专注于您要做什么和不应该做什么以及何时进行修复。在项目的早期，您想要修复所有问题。最后，您只想修复显示停止器，错误跟踪工具非常适合

需要指标时

对我而言，最大的事情是指标，即，当您希望能够查看错误的发现和修复趋势，代码的错误区域在哪里，测试人员发现和重新测试错误的速度如何时。现在该是一个错误跟踪系统了。

我同意一个团队成员足以开始需要错误跟踪程序的普遍观点。在您拥有一个或两个真实用户之后，我将其描述为强制性的，但在您的第一个版本发布之前就显得尤为重要。

就个人而言，我喜欢使用化石进行源代码控制和错误跟踪。这是一个完整的低礼式分布式SCM，可以很好地集成到错误跟踪器和Wiki。它是一个可单执行的安装，具有广泛的移植性，并使用内部Web应用程序作为其GUI。实际上，其主页几乎完全由化石副本提供。

通过与修订控制紧密集成的跟踪器，您可以轻松地将更改链接到票证，并在与修订（和Wiki页面编辑）相同的时间线视图中查看票证更新。

是的，是的，是的，是的！能够跟踪，确定优先级和管理问题是成功开发软件的关键。与一个人一起，您可以（几乎）摆脱电子表格并压缩旧的源代码树。即使在项目中添加一个开发人员，也会发生很大的变化-突然，必须进行问题跟踪和源代码控制，否则您将丢掉问题，改写功能，并且时间通常很惨。

我很惊讶没有人提到StackExchange的母公司FogCreek，但是他们的FogBugz软件是我使用过的最好的问题跟踪应用程序。高速，低阻力且价格适中，尤其是如果您使用它们的托管解决方案。他们曾经有一个免费的托管试验，我相信有两个免费的用户许可证-情况可能不再如此，但我建议您检查一下。

这是我的2美分。

对于错误跟踪，我只使用Google文档电子表格，我可以邀请任何我想要编辑或查看的人。它免费，所以投资不多。我跟踪那里的所有任务，只是错误。

我还在我的虚拟主机上运行SVN，这不会增加虚拟主机的任何额外费用。

一些客户要求使用unfuddle或其他类似的项目管理/错误跟踪软件，但我更喜欢上面提到的免费解决方案。

如果您有一个简约的Bug跟踪器，我想说这对一个团队来说也很有用。在我朋友的一个项目站点QuokForge上，他们基本上为每个项目提供了Red Mine实例。在我看来，Red Mine具有良好的Bug追踪器（即使有时有些奇怪）。这是因为您可以通过仅在一个字段中输入文本来提交错误。我以前也使用过FogBugz。2人以下免费。而且它还具有相同的简单性，只需填写一个文本字段即可提交错误。（它还提供图表和其他有用的东西）

基本上，不要使错误提交成为一个严格而正式的过程，这需要您拨出30分钟的时间来填写错误报告（BugZilla，我在找您）。这只是意味着人们不会使用它。

最后，拥有一个错误列表（即使每个错误都包含大约50个字符的文本）也非常有价值。“嗯，回合发布1.0版。我想我已经修复了最后一个错误。” 对于经理们来说，看到您实际上在做某事也很棒:)。在团队中，这是更有价值的，因为你们俩都没有试图在脑海中保留一组不同的心理任务清单。它修复了“您是否修复了（确实是严重的安全漏洞）？嗯，是的，我想是这样。那么，让我们发布1.0。”

我也喜欢跟踪功能。这是可选的，但是我仍然可以从减轻将待办事项清单保留在脑海中的精神任务中受益。

另外，看看乔尔对此有何评论

您刚刚达到了这个数字... 2！尽管即使您是唯一的开发人员，我仍然可以看到使用错误跟踪软件的好处...但是当开发人员总数为1时，您就可以不用它。

但是，一旦您拥有两个或多个开发人员，就没有理由不拥有错误跟踪软件，而没有一个。

是。推荐使用bitbucket http://www.bitbucket.org。它们提供免费的bug跟踪以及免费的Mercury 私有存储库。

一。在这种情况下，它更像一个待办事项列表。

我认为通过投资是您的平均时间。有很多免费的错误跟踪系统，对于两个人的团队来说应该没问题。在没有更大的团队之前，我不会研究商业产品。

我认为您的问题突出了您的误解。因为不是团队需要错误跟踪，而是产品。

那么，是否需要在软件中进行错误跟踪？好吧，那会有所帮助，您不觉得吗？

如果满足以下两个条件，则可能不值得：

1. 问题的寿命很短。在这种情况下，只需要一个简单的任务板就足够了（因为出于很多其他原因，可视化工作流很聪明）。但是，如果您不能快速解决问题，请执行f.ex。快速修复错误，您会发现跟踪问题很有用。
2. 通过自动测试将代码更改记录为有效文档。即，bug和修复在出现时会通过失败的测试进行记录，而通过的测试将成为修复后的回归测试。-通过自动验收测试（例如，使用某些BDD工具（例如FitNesse或Cucumber））记录了功能更改。这样的文档应该可以从像Jenkins这样的CI服务器轻松获得。

如果不存在1或2，则可以从问题跟踪中受益。

没有

不要跟踪错误，请对其进行修复。

团队的大小并不重要，而是您愿意在修复列表之前先查看列表中的错误有多长时间。

如果您使用的是敏捷/ TDD，则错误列表将很短，并且这些错误不会在列表上停留太长时间。在这种情况下，任何跟踪系统就足够了。