使用Scrum /看板时，传统的问题跟踪器有什么作用？

从很高的角度来看，在我看来，通常有两种类型的项目管理工具：

1. 传统问题跟踪工具，例如Fogbugz，JIRA，BugZilla，Trac，Redmine等。
2. 虚拟卡板 /敏捷项目管理工具，例如Pivotal Tracker，GreenHopper，AgileZen，Trello等。

当然，它们以一种或多种方式重叠，例如，可以将Pivotal Tracker任务导入JIRA，GreenHopper本身是在JIRA问题基础之上实现的，但是我认为仍然可以看到这两种工具在方向上的差异。

甚至在进行敏捷项目管理的公司中也使用传统的问题跟踪器。我的问题是，为什么他们要这样做？我也觉得我们应该在公司中使用问题跟踪器，但是当我考虑它时，我实际上不确定我们为什么需要它。

例如，Trello开发似乎是通过使用Trello本身来管理的（请参见此虚拟墙），即使他们可以访问Fogbugz（周围最好的问题跟踪者之一）也是如此。因此，当我们使用一种敏捷的PM工具以一种敏捷的方式完成100％的工作时，也许我们不需要传统的问题跟踪器？

团队可以有（至少）三种不同的工作方式。选择一个适合您的团队的人。

1.详细信息与高级概述

使用问题跟踪器可以跟踪各个任务。使用纸板可以大致了解主要功能，作为问题跟踪器中任务的摘要。

2.错误与功能

使用问题跟踪器可以跟踪各个错误和客户服务请求。使用卡板跟踪开发中的新功能。

3.里程碑软件交付与连续软件交付

如果您不定期交付大量新功能（例如，如果您是Windows团队并且每隔几年有一个新版本），请使用问题跟踪器。对于将大型完整项目一次交付给客户（包括游戏，嵌入式软件和基于年度或半年度发行的传统软件）的开发过程而言，它是理想的选择。

如果要在开发新功能时不断向客户交付新功能，请使用纸板，例如，在具有连续或非常频繁地向客户交付价值的网络团队中。在这种情况下，您的软件开发过程几乎像一条装配线，而不像一个有头有尾的项目。

我认为简单的答案是传统的问题跟踪软件可以帮助您管理积压，而Scrum板可以帮助您跟踪当前的冲刺和发布。

当然，可以使用这两种工具中的任一种来完成这两种工作，但是最终您不得不做出一些让步。

全面披露：我有点偏见，因为我是Atlassian的GreenHopper产品经理，但我也很长时间以来一直从事Atlassian以外的敏捷开发工作

仅拥有一个敏捷计划工具或一个问题跟踪器绝对是可行的。问题在于它是次优的。根据我的经验，它是次优的，因为：

• 产品计划通常发生在待办事项的史诗和故事级别。敏捷计划工具在这里很棒
• 然而，正如俗话所说，没有计划能够在与敌人第一次接触中幸存下来。在这种情况下，最初发布几个版本后，您肯定会遇到由质量检查，客户，支持等记录的错误（以及其他反馈）。这些错误需要反馈给您的计划，但又不能使计划不堪重负

因此，仅拥有一个敏捷的计划工具就很好了，但是随着产品的成熟以及您获得更多的外部输入，有效管理该输入变得越来越难。这些外部贡献者中的一些根本无法以“托管敏捷积压”类型进行贡献，他们只是想提交自己的问题并继续前进。在这里，使用问题跟踪程序可以使您与这些贡献者互动，并成功地管理持续进行的业务，以保持产品开发的进展。

我会说您需要两个工具。您还确实需要将它们集成在一起，否则您将花费​​所有时间尝试使两者保持同步。

有些产品针对故事和任务而不是缺陷进行了一些优化，但实际上并没有太大的区别。任何不会在强制结构或必填字段方面增加过多开销的优秀敏捷PM工具都可以轻松地用于缺陷跟踪。我当前的项目正在使用单个工具来处理任务和缺陷，并且除了产品是POS之外，它还可以正常工作：）

我们运行了一个名为DoneDone的问题跟踪器，该问题跟踪器在Joel的回答中排名第三-Bug跟踪器的更传统的角色。的确，我们之所以建立它，是因为我们的咨询公司历来以不定期的间隔交付大量代码（以网站形式）。

但是，一个月前，我们对DoneDone用户群进行了一些推广，其中许多人要求与Trello和Sprint.ly类似的前端，因为它们的代码/发布周期更连续。另一个有用的见解是，这些人中的许多人在进行质量检查之前就使用了DoneDone，因此随着项目（或功能）在周期之间移动，他们希望将所有数据集中在一个地方。

我的两分钱是应用了一点工作流程的所有数据。真正的区别在于UI，以及如何容纳团队以及他们当时处于哪个方法论和/或项目阶段。

问题跟踪不是项目管理，即使许多工具被设计为允许您同时执行，因此一个系统并不能真正替代另一个系统，

看板板为您提供了当前工作和出色工作的出色概览，让您一眼就能知道优先级是什么，而问题跟踪程序则使您可以将问题与版本控制系统联系在一起，并更好地工作作为记录应该保存在看板积压清单中的所有内容的一种方法，但是带有其他详细信息，否则会使您的看板变得一团糟。

问题是这两个概念可以很好地协同工作并相互支持。当然，如果您拥有一个可以在一个简洁的应用程序中同时兼顾两全其美的系统，那么它可能会使界限模糊一些，但是概念仍然保持合理的分离。

我不知道是否有明确的答案，所以我只是在报告我的经验...

多年来，我对真正的bug跟踪系统完全发售，喜欢的FogBugz，吉拉，Trac系统，等等。但是，最近我找了一份工作，我们是敏捷（真正成为敏捷，不只是在做敏捷）。我们没有历史悠久的Bug或精美物品清单。

这样的工具是没有用的。任何重要的事情，我们都可以快速入门。没什么重要的，那有什么意义呢？

没有大量积压的东西是很自由的，我们知道我们没有时间去做，而与此同时又知道我们每天都在提供最大的价值。