是否有关于使用问题跟踪系统的弊端的研究？[关闭]

我不喜欢问题跟踪系统，因为：

• 描述其中的问题需要花费太多时间。这不鼓励使用。
• 您创建了一个保存错误的地方。而且如果有他们的地方，人们通常不会太在意修复错误，因为他们可以将其放到那里，以便有一天有人可以（或不可以）对其进行修复。
• 随着时间的流逝，错误列表变得如此之长，以至于没有人能够处理它，这占用了我们很多时间。

我更喜欢使用白板上的便利贴来处理问题，进行面对面的对话，并在重要的bug出现后立即将其杀死。我不太在乎跟踪错误历史记录，因为我认为这样做不值得。

我一个人在这里吗？是否有关于使用问题跟踪系统的弊端（或巨大优势）的研究（书/文章/任何内容）？

描述其中的问题需要花费太多时间。这不鼓励使用。

如果您甚至无法描述错误，那么如何开始修复它？

您创建了一个保存错误的地方。而且如果有他们的地方，人们通常不会太在意修复错误，因为他们可以将其放到那里，以便有一天有人可以（或不可以）对其进行修复。

那是您的团队的问题，而不是软件的问题。

随着时间的流逝，错误列表变得如此之长，以至于没人能再处理它，这花费了我们很多时间。

再次说明您的团队存在问题。

错误跟踪软件的目的不是帮助您激励团队修复错误，而是保持记录，以便您可以跟踪错误原因并阻止它们再次发生。任何软件都无法取代良好的管理。

IMO你的出发点是有偏见的。如果开发人员无法修复错误，则无论他们是否使用适当的错误跟踪工具，贴子，石刻或根本不跟踪错误来跟踪项目，注定都会失败。如果不使用或滥用，这不是该工具的错。（也就是说，当然那里有错误的bug /问题跟踪器。。。我在一个项目上使用了完全不适合该工作的工具，所以我想我知道它有多糟糕。但是也有好的，只需很少的仪式和开销，您就可以专注于相关信息。）

但是，如果开发人员确实在乎，并且该项目的规模大于琐碎的事情，并且其中有一个以上的开发人员，并且涉及某种管理（所有这些在现实世界的项目中都是很常见的） ），不久就会出现类似以下的问题：

1. 哪些打开的错误应首先修复？（注意：在合理的项目中，这应该由产品所有者和/或管理层决定，而不是由开发人员决定-他们必须意识到这一点所有打开的错误！）
2. 我们有多少个打开的错误，严重性如何？
3. 在准备发布之前，必须解决其中哪些问题？
4. 有多少时间计划这些修复程序-通常会导致：平均需要花费多少时间来修复错误？
5. 客户端在上一版本中报告了多少错误？
6. 谁修复了此漏洞，何时以及此修复涉及哪些（代码/配置/数据）更改？
7. 我们即将发布的版本中包含哪些错误修复程序？
8. ...

您能否重复，可靠且有效地回答此类问题[更新] [/更新]根据您的便条纸？

是的，将错误数据输入到问题跟踪器会带来一些开销。但是，通过从存储的错误数据中查找和创建上述报告来节省时间和精力，这远远超过了补偿。

您的方法可能适用于程序员数量有限的非常小的项目。一旦项目规模扩大，拥有问题跟踪系统对于不同团队之间的协调就变得尤为重要，尤其是如果修复程序将在不同的代码版本中发布时，则尤其如此。复杂的项目将有许多活动的部件/组件，并且确保问题的计划和修复是良好的问题跟踪实施的重要部分

您可能会感兴趣的一些文章/研究包括这篇文章，讨论Zend对Jira的使用，以及这篇法语研究，讨论Bug跟踪系统的使用。

可能有研究，但更好的是该领域人员的来之不易的经验。大多数问题跟踪系统受驱动其设计的过程的困扰。问题跟踪程序通常需要支持2种不同的用户类别：

1. 开发团队
2. 系统的用户

Cal Henderson（以前是Flickr的人）在许多问题跟踪器的设计以及为什么他更喜欢GitHub问题跟踪器（我也喜欢）方面写了一篇很棒的文章。此外，Garrett Dimon讨论了Sifter的设计，并说明了一种简化过程以更有效地跟踪问题的方法。我从这两个帖子中都采纳了一些想法，以帮助简化团队的问题跟踪工作流程。

综上所述，它仍然取决于流程和工具。我的一般想法是，问题跟踪程序倾向于创建您必须管理的积压。在分类期间，人们更有可能合理化错误的存在与否。在我们的流程中，我们几乎在错误提交后就立即决定是否是问题。做出决定后，该错误就会进入Pivotal Tracker。区别在于我们使用Tracker进行优先级排序，而不是将其用作我们不想做的事情的握笔。实际上，当Icebox开始变得太大时，我会主动删除项目，包括错误。如果问题足够大，需要解决，那么它将再次出现。

我们很少需要错误历史记录。有时，有人可能会提到错误的症状，我们可能会进行搜索以查看它是否与我们已经处理的某些问题有关。但是，那是罕见的。

TL; DR专注于您的过程，选择简单的工具并解决出现的问题。

尽快消除重要的错误

听起来您好像在这里闯入门户。无论是否使用问题跟踪程序，重要的错误都会尽快被“杀死”。

• 哦，“出现时”部分很滑BTW。在一个项目中，我们遇到了一个重要的错误，该错误会威胁到整个产品的停产（还有什么会更重要？）。这非常复杂（体系结构错误），我们知道修复该过程将花费很长时间。客户友好地同意给我们一年的维修时间（在丢弃我们的产品之前），并且我们在大约一年的时间内完成了维修。

对于问题跟踪器，我已经使用了将近十年了，通常，我周围的所有程序员都花很少的时间在跟踪器上（请注意，我在说的是程序员；经理们的故事是不同的）。我曾经（很少）看到情况并非如此-在所有这些情况下，都发生了严重损坏。

关于面对面对话与问题跟踪的研究，再次感觉就像您在这里闯入大门。问题跟踪是一种典型的书面交流。有很多研究显示，商量事情，面对面商务沟通比更有效的在电话这又有效得多比写。

• 实际上，考虑到您询问f2f的感觉，就好像您在（使用）跟踪器来讨论事物一样-这不是其目的。要确定其预期用途，只需缓慢且清晰地拼写其名称：问题跟踪系统。

错误列表变得很长

以我的经验，以上是优点而不是问题。

利用冗长的错误列表，开发人员可以建立队列并计划更远的修复程序。这是有生产力的。对我来说，当我有这样一个队列需要工作时，这基本上是一个必杀技。首先错误-修复-完成，第二个错误-修复-完成后，接下来的错误-修复-做等等等等，没有愚蠢的中断，没有痛苦与分心哦，所以，高效的F2F交谈，纯流动。

• 我只记得一个问题，那就是长长的错误列表是一个问题。当高级管理人员的一个白痴决定制定一项政策，迫使开发人员几乎每天都要从50-100个漏洞中挑选下一个bug时，事情就发生了。真是浪费 我们花了几个月的时间才知道如何将其升级到他的头上并将其修复。
  在设法建立方便的工作流程后的一段时间，我们发现“无休止的积压”变得空无一物。