Bug 追踪器的演变(bug的定位和跟踪)

推荐整理分享Bug 追踪器的演变(bug的定位和跟踪)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:bug追踪工具,如何对bug进行跟踪管理,追踪器不工作是啥原因,bug的跟踪流程,bug追踪工具,bug追踪工具,bug追踪工具,bug的跟踪流程,内容如对您有帮助，希望把文章链接给更多的朋友！

Jon 和 Ken：过去几年中，Bug追踪器已经从追踪简单的任务变成更加复杂的软件（比如它可以管理项目的生命周期、创建用户工作流以及为未来的改进工作提供报告）。随着项目管理功能的增强，Bug追踪器已经不仅限于开发者所涉及的领域。

特别是过去3年，JIRA已经演变成高强度开发团队的核心。JIRA最初只是一个简单却很实用的追踪软件缺陷的系统。如今，它已经能追踪管理各种各样的事务 ──从初始开发任务的bug到团队的招聘活动。JIRA支持所有Scrum功能──从计划板（PlanningBoards）到燃尽图（Burn-down Charts）。

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

而且从JIRA4.0开始，能够看到一些重大的改变，包括一个全新动态的用户界面、信息面板、Gadget（它们都是基于OpenSocial，JIRA是一个OpenSocial的容器和发布商）以及社交功能，比如ActivityStreams（它把用户活动聚合成非常容易订阅的feed，就像FaceBook一样）。总而言之，JIRA以及其他的bug追踪器，已经演变成拥有复杂功能的多面手。Daniel：wow，互联网时间中的三年！回头看5.0版的FogBugz，大概是06年8月份推出的，就好像在审视遥远地质时代的化石。对于菜鸟来说，显然FogBugz 7.0看起来要更加友好。

不过，事实的确是FogBugz正演变成一个完整的项目管理系统，缺陷追踪是它的核心组件。如果你仔细想一下，如果使用一个工具管理你的项目计划，再用另外一个工具去追踪开发过程中的bug，的确是件非常麻烦的事。其实，在这两个过程中，你都做了同样的事情：描述任务、评估工作量、在时间表上跟踪项目进度。

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

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

最后，我们还引入了插件架构，它能够使你自定义以及扩展几乎FogBugz的每一个功能。第一批的FogCreek插件让你可以修改项目的工作流，使其与团队的工作方式相匹配，以及增加自定义项目域等等。这个平台对全部有志于开发出强大插件并使其整合到FogBugz的开发者都是开放的。David：过去3年我们做的最重要的一件事是不做太多的改变。很容易对本来受欢迎的产品不断的添加功能，最终导致过度演变，使其变得越来越复杂，很难使用。

这并不是说我们不对产品进行改进了，恰恰相反，比如说，最近我们就通过Flash Widget改进了上传进度提示以及多文件的选取功能。我们还添加了导出成HTML的功能，所以你可以把整个项目变成一个独立的本地站点。

但可能是最重要的，我们一直在不断的精炼人们每天要面对的那些UI。像增加了在信息面板上快速浏览里程碑的功能，这样你就无需点击并放大附加的图片了。Victor：过去3年发生了很多变化，下面这些是比较重要的：插件的支持、针对CVS、SVN以及GIT的更简单/多功能的源代码控制集成、Twitter的整合、标签、改进的LDAP/AD支持、完全可自定义的缺陷域、XML导入/导出、便捷的SOAP的API、更新的Docbook手册以及46种语言的本地化，等等。

在我们开发上的变化是，我们转移到了Git上，把它作为我们的源代码控制工具。这大大提高了开发者的工作效率，为社区提供了一个更好的框架，可使大家自定义分支，并把新的改进提交给我们，并最终集成到核心的产品上。Jon和Ken：IDE在过去几年中也发生了很大的改变，开发者也越来越希望在IDE中就能完成所需要做的事情。我们现在通过免费的连接器对JetBrainsIntelliJIDEA和Eclipse都支持对缺陷的跟踪、创建代码复查、查看编译错误以及远端代码库中浏览。就好比你可以在iPhone上使用GoolgeReader或者Gmail一样，不用改变任何设置，我们相信开发者每天都会越来越依赖IDE，回到Web界面上进行配置并实现更复杂的功能。Daniel：大多数用户习惯在工作的时候在浏览器中打开任务列表，但是一些开发者或许想要在IDE中管理这些任务。所以，我们为VisualStudio（2005和2008）以及Eclipse都提供了相应的插件，可以在相应的面板中管理任务。至于IDE插件是否会在将来像我们的Web界面那样受到大家的欢迎，我不感确定，但是我相信它们会作为缺陷追踪工具的分支，一直存在的。David：Basecamp没有提供任何与IDE集成的组件，但是我们提供了一个功能强大的API，大家可以引用它。我并不了解这点对广大开发者来说到底有多重要，从我们来讲，并没有感觉有什么不便，我们团队内部一直在使用Basecamp进行bug的追踪。Victor：MantisBT提供了MantisConnect与EclipseIDE进行整合。在我们看来，bug追踪功能应该集成到每个人所使用的工具当中。项目经历可能需要Excel的集成，开发者则使用IDE的集成，而客户则倾向使用Web界面，等等。提供API是集成战略中的一部分，它能够让社区创建自己所需要的连接器。Jon和Ken：由于我们大部分的客户都位于防火墙后，所以可以看到我们的在线产品（JIRA Hosted和JIRAStudio）越来越受到欢迎──特别是对小团队而言，他们并不需要特定的设施。对于那些想在自己架构上搭建的客户来说，主要有两个原因：a）他们有一个本地的企业级软件需要集成；b）他们对IP的安全性非常敏感，并且不想承担任何风险。

我认为未来所有的软件开发以及部署都会在云端。而且，应用程序运行在网络上需要使用很多外部服务（比如通过Goolge Visualizations提供复杂的图表），但同时也降低了总体成本。Daniel：如果你的组织并没有控制整个系统的需求，那么，bug追踪提供商会非常了解如何更安全的托管你的数据，所以，把bug追踪当作服务来使用是一种非常不错的选择。

FogBugz on Demand越来越受到大家的欢迎，因为它非常安全（128位加密，世界级的服务器设施）以及为客户免去了很多管理上的负担。对于那些想自己掌管一切的公司，他们还是会选择FogBugz的安装版。

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

但是如果你是自己维护FogBugz实例的话，你可以安装与云端（或者自己的防火墙内）的任何服务进行交互的插件。David：把软件作为服务后，一切就会简单的多。在我印象中，现在已经很少有关于是否应当自己架设、维护系统的争论了。但是，除非你要做的是最机密的CIA项目，那就会是一个例外。Victor：没有通用的解决方案。有些组织倾向于自己架设bug追踪器、实施系统集成以及自定义。但是其他一些组织，就会倾向于这种拿来直接用的服务。这要取决于公司的策略和规模。关键的一点是，无论哪种选项都要提供给客户，MantisBT两种方式都会提供给大家。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管理非软件领域的缺陷问题。Jon和Ken：Atlassian已经把bug追踪软件引入到主流当中。7年前，我们开创了全新的、多功能基于Web的界面，那时候，大多数商业软件只提供windows单机版。在过去的3年中，我们看到了很多关于富互联网应用的创新，未来，我们会看到更多。

我们开始看到基于Web的应用程序（Gmail/GoogleReader）已经好于同类的桌面应用。我们也将会不断的提高产品中的可用性与生产率。至于HTML5会带来巨大的改变吗？很显然，对离线以及更多控制组件的支持，将会让它更容易开发出相应的功能，最终会带来生产率的提升。不过，规范中的大部分已经通过浏览器插件以别的方式实现了。HTML 5会让它变得更标准。Daniel：当然，我们仍能不断改进它的可用性。我们已经引领了这种风潮，把bug追踪器从“Web1.0基于数据库的前端界面”转变成“基于Ajax的富Web应用”。我们会聆听客户的声音，不断改进，把最顶尖的开发精英投入到最困难的可用性问题上（顺带提一下，如果任何人有对FogBugz改进的建议，请发邮件到support@fogcreek.com）。

我们都很关注HTML 5，看它的哪些功能能够改善用户体验。举两个例子，通过在后台线程中运行“Web Worker”（译者注：这是HTML 5引入的一个新概念，详情请移步这里）能够在某些情况下提高性能；“Canvas”元素对于图像显示来说，或许是Flash一个很好的替代品。David：好的可用性不会依赖于新奇的技术。一件非常重要的事情，大多数开发者都应当把它做好，而且应当投入更多的时间在那上面──应用程序中的文案（copywriting）。文案即是设计，大多数应用程序都有糟糕的文案。

HTML5拥有一些很令人振奋的特性，比如从一个窗口拖拽到另外一个。我确定马上就会看到相应的产品。Victor：bug追踪器很重要的一方面是减少汇报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追踪起之间协同工作。