虚拟座谈：Bug 追踪器的演变

Bug 追踪系统（Bug Tracking Systems）已经成为任何一个开发团队的必备工具之一，在过去几年中发生了很大的变化。InfoQ 组织了一场虚拟座谈，邀请了几位来自 JIRA 、 FogBugz 、 Basecamp 以及 MantisBT 的嘉宾，共同探讨了 Bug 追踪器的演变及其未来的发展。

参加此次虚拟座谈的嘉宾有：

• Jon Silvers 和 Ken Olofsen（来自 Atlassian）
• Daniel Wilson（来自 Fog Creek Softwre）
• David Heinemeier Hansson（来自 37signals）
• Victor Boctor（来自 MantisBT）

InfoQ：能描述一下过去 3 年你们产品的演变过程吗？其中最重要的里程碑是什么？

Jon 和 Ken：过去几年中，Bug 追踪器已经从追踪简单的任务变成更加复杂的软件（比如它可以管理项目的生命周期、创建用户工作流以及为未来的改进工作提供报告）。随着项目管理功能的增强，Bug 追踪器已经不仅限于开发者所涉及的领域。 特别是过去 3 年，JIRA 已经演变成高强度开发团队的核心。JIRA 最初只是一个简单却很实用的追踪软件缺陷的系统。如今，它已经能追踪管理各种各样的事务 ──从初始开发任务的 bug 到团队的招聘活动。JIRA 支持所有 Scrum 功能──从计划板（Planning Boards）到燃尽图（Burn-down Charts）。

在 JIRA 演变中的几个关键点包括它的插件架构（它允许 JIRA 能够更方便的进行扩展和自定义）、与 IDE 的连通（它能够与团队的开发平台界面集成在一 起）与 Atlassian 主要的协作开发工具整合（从持续集成服务器到结对代码复查，再到源代码的浏览，开发中需要的每一件事，都可以在这一整套工具中完成）。

而且从 JIRA 4.0 开始，能够看到一些重大的改变，包括一个全新动态的用户界面、信息面板、Gadget（它们都是基于 OpenSocial，JIRA 是一个 OpenSocial 的容器和发布商）以及社交功能，比如 ActivityStreams（它把用户活动聚合成非常容易订阅的 feed，就像 FaceBook 一样）。总而言之，JIRA 以及其他的 bug 追踪器，已经演变成拥有复杂功能的多面手。

Daniel：wow，互联网时间中的三年！回头看 5.0 版的 FogBugz，大概是 06 年 8 月份推出的，就好像在审视遥远地质时代的化石。对于菜鸟来说，显然 FogBugz 7.0 看起来要更加友好。 不过，事实的确是 FogBugz 正演变成一个完整的项目管理系统，缺陷追踪是它的核心组件。如果你仔细想一下，如果使用一个工具管理你的项目计划，再用另外一个工具去追踪开发过程中的 bug，的确是件非常麻烦的事。其实，在这两个过程中，你都做了同样的事情：描述任务、评估工作量、在时间表上跟踪项目进 度。

所以，我们把 FogBugz 7.0 设计成可跟踪整个项目，从计划到最后的发布。我们的 Subcases 功能允许你把任务细分，并且 Agile/Scrum 团队可以从任务列表中管理产品 backlog。你会按时发布，因为有我们的基于证据调度（Evidence-Based Scheduling）算法的帮忙，它会借鉴开发者过往的估算记录。不用再发邮件通知文档规范不同版本之间的变化了，因为 FogBugz 还包括有一个全功能的 wiki，可帮助你撰写、查看项目文档。

我们是在自己核心的 bug 追踪功能上构建了以上这些功能，使其更加如鱼得水。我们用 AJAX 强化的任务列表功能，使输入 bug 就像在文本编辑器上做记录一样简单。在客户支持方面，贝叶斯过滤（Bayesian Filtering）算法会阻击所有 spam，让 email 能够准确投递到相应的部门。

最后，我们还引入了插件架构，它能够使你自定义以及扩展几乎 FogBugz 的每一个功能。第一批的 Fog Creek 插件让你可以修改项目的工作流，使其与团队的工作方式相匹配，以及增加自定义项目域等等。这个平台对全部有志于开发出强大插件并使其整合到 FogBugz 的开发者都是开放的。

David：过去 3 年我们做的最重要的一件事是不做太多的改变。很容易对本来受欢迎的产品不断的添加功能，最终导致过度演变，使其变得越来越复杂，很难使用。 这并不是说我们不对产品进行改进了，恰恰相反，比如说，最近我们就通过 Flash Widget 改进了上传进度提示以及多文件的选取功能。我们还添加了导出成 HTML 的功能，所以你可以把整个项目变成一个独立的本地站点。

但可能是最重要的，我们一直在不断的精炼人们每天要面对的那些 UI。像增加了在信息面板上快速浏览里程碑的功能，这样你就无需点击并放大附加的图片了。

Victor：过去 3 年发生了很多变化，下面这些是比较重要的：插件的支持、针对 CVS、SVN 以及 GIT 的更简单 / 多功能的源代码控制集成、 Twitter 的整合、标签、改进的 LDAP/AD 支持、完全可自定义的缺陷域、XML 导入 / 导出、便捷的 SOAP 的 API、更新的 Docbook 手册以及 46 种语言的本地化，等等。 在我们开发上的变化是，我们转移到了 Git 上，把它作为我们的源代码控制工具。这大大提高了开发者的工作效率，为社区提供了一个更好的框架，可使大家自定义分支，并把新的改进提交给我们，并最终集成到核心的产品上。

InfoQ：对于 bug 追踪器与主流 IDE 的集成，你怎么看？你认为最终会发展成什么样子？

Jon 和 Ken：IDE 在过去几年中也发生了很大的改变，开发者也越来越希望在 IDE 中就能完成所需要做的事情。我们现在通过免费的连接器对 JetBrains IntelliJIDEA 和 Eclipse 都支持对缺陷的跟踪、创建代码复查、查看编译错误以及远端代码库中浏览。就好比你可以在 iPhone 上使用 Goolge Reader 或者 Gmail 一样，不用改变任何设置，我们相信开发者每天都会越来越依赖 IDE，回到 Web 界面上进行配置并实现更复杂的功能。

Daniel：大多数用户习惯在工作的时候在浏览器中打开任务列表，但是一些开发者或许想要在 IDE 中管理这些任务。所以，我们为 Visual Studio（2005 和 2008）以及 Eclipse 都提供了相应的插件，可以在相应的面板中管理任务。至于 IDE 插件是否会在将来像我们的 Web 界面那样受到大家的欢迎，我不感确定，但是我相信它们会作为缺陷追踪工具的分支，一直存在的。

David：Basecamp 没有提供任何与 IDE 集成的组件，但是我们提供了一个功能强大的 API，大家可以引用它。我并不了解这点对广大开发者来说到底有多重要，从我们来讲，并没有感觉有什么不便，我们团队内部一直在使用 Basecamp 进行 bug 的追踪。

Victor：MantisBT 提供了 MantisConnect 与 Eclipse IDE 进行整合。在我们看来，bug 追踪功能应该集成到每个人所使用的工具当中。项目经历可能需要 Excel 的集成，开发者则使用 IDE 的集成，而客户则倾向使用 Web 界面，等等。提供 API 是集成战略中的一部分，它能够让社区创建自己所需要的连接器。

InfoQ：你认为什么时候适合把 bug 追踪器当作一种服务以及一个组织什么时候需要在自己的架构上安装这种软件？你认为云计算会对上面两种方式有什么帮助吗？

Jon 和 Ken：由于我们大部分的客户都位于防火墙后，所以可以看到我们的在线产品（JIRA Hosted 和 JIRA Studio）越来越受到欢迎──特别是对小团队而言，他们并不需要特定的设施。对于那些想在自己架构上搭建的客户来说，主要有两个原因：a）他们有一个本地的企业级软件需要集成；b）他们对 IP 的安全性非常敏感，并且不想承担任何风险。 我认为未来所有的软件开发以及部署都会在云端。而且，应用程序运行在网络上需要使用很多外部服务（比如通过 Goolge Visualizations 提供复杂的图表），但同时也降低了总体成本。

Daniel：如果你的组织并没有控制整个系统的需求，那么，bug 追踪提供商会非常了解如何更安全的托管你的数据，所以，把 bug 追踪当作服务来使用是一种非常不错的选择。 FogBugz on Demand 越来越受到大家的欢迎，因为它非常安全（128 位加密，世界级的服务器设施）以及为客户免去了很多管理上的负担。对于那些想自己掌管一切的公司，他们还是会选择 FogBugz 的安装版。

至于云计算会对哪种方式有所帮助，这要看客户的具体需求。我的意思是，FogBugz On Demand 从定义上是一种云计算服务。但是我们都非常担心安全和带宽的问题，所以我们通常不允许在线插件（它会为云端的外部服务请求提供响应）。

但是如果你是自己维护 FogBugz 实例的话，你可以安装与云端（或者自己的防火墙内）的任何服务进行交互的插件。

David：把软件作为服务后，一切就会简单的多。在我印象中，现在已经很少有关于是否应当自己架设、维护系统的争论了。但是，除非你要做的是最机密的 CIA 项目，那就会是一个例外。

Victor：没有通用的解决方案。有些组织倾向于自己架设 bug 追踪器、实施系统集成以及自定义。但是其他一些组织，就会倾向于这种拿来直接用的服务。这要取决于公司的策略和规模。关键的一点是，无论哪种选项都要提供给客户，MantisBT 两种方式都会提供给大家。

InfoQ：你认为 Bug 追踪器如何更好的适应组织的内部流程？如何适应那些软件开发流程框架，比如 Scrum 和 Lean？

Jon 和 Ken：通常情况下，bug 追踪器现在都已经可以很容易的为每个团队自定义工作流。因为每个公司都有各自的开发模式（瀑布式或者敏捷），应用程序必须拥有足够的灵活性以满足不同的团队。 以敏捷为例，我们提供了对 JIRA 的扩展──GreenHopper，它可直接的支持敏捷实践，比如通过把问题描述成一个虚拟的索引卡片，使得迭代计划和任务的执行更加方便。但是我们同样也允许客户把 JIRA 连接到其他的敏捷项目管理工具上。如果你运行在一个封闭的环境内，是不可能称之为一个成功的 bug 追踪器的，所以，我们尽可能的把 JIRA 开放出去。

Daniel：我们最初创建 FogBugz 是为了满足我们在 FogCreek 自己的工作方式。我们喜欢简单的任务工作流，它可以自动把完成的任务赋给创建者使其审核，然后让任务域的数量最小化。 插件最令人称道的是他们能够使 FogBugz 适用于任何组织。我们的自定义工作流插件（Custom Workflow Plugin）让客户创建自定义的任务目录、状态以及任务赋予规则。自定义域的插件让客户能够很轻松的创建一个或者两个他们所必须的额外域。

并且，因为 FogBugz 是一个完整的项目管理系统，它提供了对各种软件流程框架的良好支持。比如，我们在 FogBugz 7.0 支持 Agile/Scrum 方法，它引入了燃尽图、backlog 管理插件以及更简单的管理短周期项目里程碑的方式。

David：在 Basecamp 里，我们试图保持所有事情尽可能的简单，所以我们没有强迫使用任何特有的方法。其中我们主要追踪 bug 的方式就是把他们发布到优先级 todo 列表中，把这些 todo 项链到相应的说明文本上。 我认为很容易使你的软件过度专业化，变成某一种特定的风格，然后便会很快地发现他们有多么的麻烦。

Victor：MantisBT 允许用户自定义项目状态、工作流、默认问题域、自定义域、报告等等。实际上，社区已经为 MantisBT 开发出了一个 Scrum 插件。我们还了解到，有人也在使用 MantisBT 管理非软件领域的缺陷问题。

InfoQ：bug 追踪软件的可用性在过去几年中呈上升趋势。你认为这其中还有可改进的地方吗？你认为某些技术（比如 HTML 5）会对其产生多大的影响？

Jon 和 Ken：Atlassian 已经把 bug 追踪软件引入到主流当中。7 年前，我们开创了全新的、多功能基于 Web 的界面，那时候，大多数商业软件只提供 windows 单机版。在过去的 3 年中，我们看到了很多关于富互联网应用的创新，未来，我们会看到更多。 我们开始看到基于 Web 的应用程序（Gmail/Google Reader）已经好于同类的桌面应用。我们也将会不断的提高产品中的可用性与生产率。至于 HTML 5 会带来巨大的改变吗？很显然，对离线以及更多控制组件的支持，将会让它更容易开发出相应的功能，最终会带来生产率的提升。不过，规范中的大部分已经通过浏览器插件以别的方式实现了。HTML 5 会让它变得更标准。

Daniel：当然，我们仍能不断改进它的可用性。我们已经引领了这种风潮，把 bug 追踪器从“Web 1.0 基于数据库的前端界面”转变成“基于 Ajax 的富 Web 应用”。我们会聆听客户的声音，不断改进，把最顶尖的开发精英投入到最困难的可用性问题上（顺带提一下，如果任何人有对 FogBugz 改进的建议，请发邮件到 support@fogcreek.com ）。 我们都很关注 HTML 5，看它的哪些功能能够改善用户体验。举两个例子，通过在后台线程中运行“Web Worker”（译者注：这是 HTML 5 引入的一个新概念，详情请移步这里）能够在某些情况下提高性能；“Canvas”元素对于图像显示来说，或许是 Flash 一个很好的替代品。

David：好的可用性不会依赖于新奇的技术。一件非常重要的事情，大多数开发者都应当把它做好，而且应当投入更多的时间在那上面──应用程序中的文案（copywriting）。文案即是设计，大多数应用程序都有糟糕的文案。 HTML5 拥有一些很令人振奋的特性，比如从一个窗口拖拽到另外一个。我确定马上就会看到相应的产品。

Victor：bug 追踪器很重要的一方面是减少汇报 bug 中的阻力。所以，新技术的应用都是为了实现这一点。比如，提供离线支持、富用户体验等等。但是，对于那些使用过时浏览器的用户，我们仍有为其提供支持，并且持续为他们提供多种连接与工作方式。

InfoQ：你认为 bug 追踪器在不远的将来会发展成什么样子？你希望看到哪些新功能？

Jon 和 Ken：Atlassian 会在以下两个领域持续创新：- IDE 和界面的整合：前面我也提到了，把丰富的用户体验混入到不同类型的客户端界面当中去，使其成为一个 IDE、好用的 Web 应用或者可添加到其他 Web 应用程序（例如 Gmail）的组件（比如 Gadget）──为用户提供更大的自由度、更顺畅的体验以及更少的场景转换。OpenSocial 是这其中的关键一环。

- 改进社交功能以及用户关联度：我们相信我们是这条路上的领航者，但是社交功能应当是任何协作工具都应当与生具来的功能。扩展现有的社交功能，比如 ActivityStreams、人际网络、高级用户档案等等是这部分的关键之处。

Daniel：作为一名软件开发者，我们最喜欢的新功能就是那些使 bug 追踪的过程更简单、更愉快，这样我们才能专注做出好的软件。FogBugz 的未来版本会专注于使终端用户更加愉快，因为缺陷跟踪只有在人们愿意参与进来的时候，才会真正起作用。

David：我们不断的令它保持简洁。这 5 年多来，我们一直都是在用我们的产品改进自己的产品。我不认为 bug 跟踪与其他的任务跟踪有什么特别的不同。就像我所说的，bug 并没有什么特别的。他们只是待做事情的一部分，与功能以及其他方面的改进列在一起，只是排了一下优先级而已。

Victor：下面是我对 bug 追踪器在不久将来发展的一些看法： 应用于小团队 / 甚至是单人团队 - 现在已经比你当初自己购买、安装、托管 bug 追踪器的成本减少太多了。现在，你可以免费在 SourceForege 上使用，在托管商那边也只需要 1 键安装。

移动接入 - 随着越来越多的人使用移动电话来完成工作并接入互联网，提供一个富移动体验将是非常关键的。

离线接入 - 随着 HTML 5 兼容的浏览器逐渐获取市场份额，提供离线接入会大大提高 Web 应用程序（包括 bug 追踪器）的生产率。

互用性 - 越来越多的工作需要在 bug 追踪器之间协同完成，从而管理相关的上游和下游 bug。理想的目标是构建一种标准的方式用于不同 bug 追踪起之间协同工作。

查看英文原文： Virtual Panel: The evolution of bug trackers 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。