没有建立自己的错误跟踪系统的原因

Question

好几次,我已经面临一个想要建立自己的错误跟踪系统的团队的计划 - 不是作为产品,而是作为内部工具.

我听过的论点通常都是这样的:

• 想要在一些内部构建的Web框架方面"吃我们自己的狗粮"
• 需要一些高度专业化的报告,或者能够以一些据称独特的方式调整某些功能
• 相信构建错误跟踪系统并不困难

您可以使用哪些参数来支持购买现有的错误跟踪系统？特别是,什么功能听起来很容易但很难实现,或者很难和重要但经常被忽视？

Answer 1

首先,看看这些Ohloh指标:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

我们从这些数字中学到了什么？我们了解到构建又一个Bug Tracker是一种浪费资源的好方法!

以下是我构建您自己的内部错误跟踪系统的原因:

1. 你需要中和所有的bozocoders十年或两年.
2. 你需要冲洗一些钱以避免明年减少预算.

否则不要.

Answer 2

我想转过身来.为什么你想建立自己的？
如果您需要一些额外的字段,请使用可以修改的现有包.
特别报道？点按数据库并进行制作.

相信这不难吗？然后试试.详细说明,并查看功能列表和小时数增长.然后在列表完成后,尝试在实现自己的包之前找到可以修改的现有包.

简而言之,当另一个人需要进行一些调整以适应时,不要重新发明轮子.

Answer 3

程序员喜欢建立他们自己的票务系统,因为他们已经看过并使用过几十个票证系统,因此他们对此有所了解.这样他们就可以留在舒适区.

这就像检查一家新餐馆:这可能是有益的,但它带来了风险.最好再次订购披萨.

在那里埋葬了一个很重要的决策事实:做出一些事情总有两个理由:好的和正确的.我们做出决定("建立我们自己的"),然后证明它("我们需要完全控制").大多数人甚至都不知道他们的真正动机.

要改变主意,你必须攻击真正的原因,而不是理由.

Answer 4

不发明在这里综合症!

建立自己的bug跟踪器？为什么不建立自己的邮件客户端,项目管理工具等.

正如Omer van Kloeten在其他地方所说,现在付款或稍后付款.

Answer 5

还有第三种选择,既不买也不建.那里有很多好的自由人.例如:

• Bugzilla的
• TRAC

滚动你自己的bug追踪器用于学习以外的任何用途都不是很好的时间利用.

其他链接:

• 三个免费的bug跟踪工具
• 问题跟踪系统的比较

Answer 6

我只想说这是钱的问题 - 买一件你知道对你有好处的成品(有时甚至不买,如果它是免费的)比自己开发一件好.现在这是一个简单的薪酬游戏,而不是以后付费.

Answer 7

首先,反对支持建立自己的论据:

想要在一些内部构建的Web框架方面"吃我们自己的狗粮"

这当然提出了为什么要构建自己的Web框架的问题.就像那里有许多有价值的免费bug追踪器一样,也有许多有价值的框架.我想知道你的开发人员是否优先考虑他们 谁在做公司实际赚钱的工作？

好的,如果他们必须构建一个框架,那么让它从构建您的企业用来赚钱的实际软件的过程中有机地发展.

需要一些高度专业化的报告,或者能够以一些据称独特的方式调整某些功能

正如其他人所说,抓住众多优秀的开源追踪器中的一个并进行调整.

相信构建错误跟踪系统并不困难

好吧,我在几周内编写了我的BugTracker.NET的第一个版本,从没有先前的C#知识开始.但是现在,6年和几千小时后,还有一大堆未撤消的功能请求,所以这一切都取决于你想要一个bug跟踪系统做什么.多少电子邮件集成,源代码控制集成,权限,工作流,时间跟踪,计划估计等.错误跟踪器可以是主要的主要应用程序.

您可以使用哪些参数来支持购买现有的错误跟踪系统？

不需要购买.很多优秀的开源软件:Trac,Mantis_Bug_Tracker,我自己的BugTracker.NET,仅举几例.

特别是,什么功能听起来很容易但很难实现,或者很难和重要但经常被忽视？

如果你只为自己创造它,那么你可以采取很多捷径,因为你可以硬连线.如果您正在为许多不同的用户构建它,在许多不同的场景中,那么它就是对可配置性的支持.可配置的工作流程,自定义字段和权限.

我认为一个好的 bug跟踪器必须具备的两个功能,即FogBugz和BugTracker.NET都具有以下功能:1)传入和传出电子邮件的集成,以便关于错误的整个对话与错误一起存在,而不是单独的电子邮件线程,以及2)只需点击几下即可将屏幕截图转换为bug帖子的实用程序.

Answer 8

对我来说,最基本的论据是时间损失.我怀疑它可以在不到一两个月内完成.为什么要花很多时间才能有很多好的bug跟踪系统呢？给我一个您必须调整并且不易获得的功能的示例.

我认为一个好的bug跟踪系统必须反映你的开发过程.对于公司/团队来说,非常自定义的开发过程本质上是不好的.大多数敏捷实践都支持Scrum或这些类型的东西,大多数bug跟踪系统都符合这些建议和方法.不要太过官僚主义.

Answer 9

最重要的是,在完成之前,您将在哪里为bug跟踪器提交错误？

不过实话说.工具已经存在,没有必要重新发明轮子.修改跟踪工具以添加某些特定功能是一回事(之前我修改了Trac)...重写一个只是愚蠢.

您可以指出的最重要的事情是,如果他们想要做的只是添加几个专门的报告,它不需要一个全新的解决方案.此外,最后一个地方"你的自制解决方案"很重要的内部工具.如果在需要的时候完成工作,谁会关心你在内部使用什么？

Answer 10

错误跟踪系统可以成为启动初级开发人员的一个很好的项目.这是一个相当简单的系统,您可以用它来训练它们的编码约定等等.让初级开发人员构建这样一个系统相对便宜,他们可以在客户看不到的东西上犯错误.

如果它是垃圾,你可以扔掉它但你可以让他们觉得如果使用它已经对公司很重要的工作.您不能将初级开发人员的成本付诸于能够体验整个生命周期以及此类项目将带来的所有知识转移机会.

Answer 11

我们在这里做到了.我们在十多年前写了第一篇.然后,我们将其升级为使用Web服务,这是学习该技术的一种方式.我们最初这样做的主要原因是我们想要一个bug跟踪系统,它还生成了版本历史报告和一些我们在商业产品中找不到的其他功能.

我们现在再次关注错误跟踪系统,并正在认真考虑迁移到Mantis并使用Mantis Connect添加我们自己的其他自定义功能.滚动我们自己的系统的努力量太大了.

我想我们也应该看看FogBugz :-)