您将如何主张不使用共享电子表格来跟踪错误/问题？

在我们公司中，开发人员希望使用适当的错误跟踪工具来管理应用程序中的问题。但是，管理层坚持使用共享电子表格（以前是共享的excel文件，现在是基于Web的解决方案上的电子表格，允许并发访问）。

他们的观点是，电子表格可以使他们对项目状态有一个更高级的了解，因为他们可以快速浏览一下打开了多少个错误。这也使他们能够看到谁在处理每个错误，并估计关闭它们所需的时间（因为开发人员需要填写他们正在处理的错误的时间估计）。

如您所知，这对于开发人员来说实际上并不实际（错误跟踪软件的发明是有原因的）。那么，我该如何倡导错误跟踪软件来简化开发人员的工作呢？

作为奖励，您建议使用哪种软件可以让管理层从高层次的角度获得他们的反馈（打开的漏洞数量，正在研究的漏洞，时间估计）？

那么，我该如何倡导错误跟踪软件来简化开发人员的工作呢？

鉴于此声明：

电子表格使他们可以更快速地了解项目状态，因为他们可以快速查看打开的错误数量。

您需要查看具有报告工具的系统，这些工具可以有效地“实​​时”（或尽可能接近）创建电子表格。当您发现其中之一时，说明让开发人员使用“适当的”系统将意味着（希望）他们感兴趣的数据更加准确和最新（例如）。

电子表格的哪个最新版本？谁拥有该电子表格？

任何体面的bugtracker只会做电子表格可以做的事情：

• 发生变化时将通过电子邮件发送给相关方
• 提供最新信息的单一规范来源
• 允许汇总报告，以提供项目状态的高级视图

对于我的个人项目，我使用Mantis（只是因为它很容易设置）。Work将Trac与Mercurial集成在一起使用。

Mantis提供开箱/关闭/分配的错误数量之类的东西，我想大多数Bugtrackers都会提供。我不知道时间估计，因为我没有打扰。Trac（或正在使用的安装）确实具有时间估计，并且编写自定义报告很容易，例如，将汇总每个里程碑的估计。

其他人的答案都很好。我想到了另一方面。

电子表格的安全性如何？管理层不应该担心任何随机的开发人员可能会意外按下CTRL + A，DELETE按钮并真的搞砸了吗？一个适当的错误跟踪系统将不允许这种数据损坏。而且，这甚至都不能解决恶意问题。如果某个特定的开发人员想要更多的信誉并开始将所有缺陷修复重新分配给自己怎么办？真实的系统将具有审核记录，这种情况将很明显。电子表格不会。

您需要向管理层表明他们的要求将得到满足。

他们的观点是，电子表格可以使他们对项目状态有一个更高级的了解，因为他们可以快速浏览一下打开了多少个错误。这也使他们能够看到谁在处理每个错误，并估计关闭它们所需的时间（因为开发人员需要填写他们正在处理的错误的时间估计）。

因此，设置一个虚拟系统并向其展示演示，他们可以获得的信息与使用电子表格一样好，甚至更好。

到目前为止，每个人都提出了类似且适当的回应。有一个重要方面尚未谈到。为了跟踪错误并确保没有漏洞通过，您需要做两件事：

• 良好的报告，包括摘要和详细信息-以后可以进行搜索
• 每个人都需要知道最新副本在哪里。

在几乎所有提倡使用Excel电子表格的环境中，每个人的计算机上都有该电子表格的不同副本，而且没有一个是相同的。这使得审查进度的过程极其困难且适得其反。

集中式服务器（例如Trac，RedMine，JIRA，Mantis或任何您想要的东西）可以解决这两个问题。在那时，最适合您公司需求的问题。根据您的环境，这些工具可以与您的IDE集成在一起，就像版本控制系统一样（Eclipse具有此功能）。这使解决分配的错误变得容易得多。

我不知道您的环境，但是对于Visual Studio用户，我强烈建议使用TFS。它具有完整的报告功能，集成了源代码控制和问题跟踪。它还提供了权限层次，完整的历史记录跟踪（即谁在何时以及是否设置了错误的情况下更新了错误），使您能够区分“错误”，“问题”，“增强”以及您需要执行的其他任何操作喜欢，并与Visual Studio IDE完全集成。它将一个错误与已检入的代码联系在一起，可以将其绑定到特定的版本。还有更多。

我已经使用了许多不同的源代码控制系统（VSS，SVN，TFS ...）和许多错误跟踪系统（自定义专有系统，Tracker，SharePoint，甚至是Excel），但是为了我的钱（这是TFS是一个很大的变化），值得花时间和金钱进行投资。

是的，您可以导出到Excel（或从Excel导入）。

为了帮助您过渡到适当的问题跟踪器，您应该尝试找出管理当前系统存在的问题（注定是“如果...会很好”），然后看看您是否无法解决这一问题。为他们。

阅读管理层的论点

他们的观点是，电子表格可以使他们对项目状态有一个更高级的了解，因为他们可以快速浏览一下打开了多少个错误。这也使他们能够看到谁在处理每个错误，并估计关闭它们所需的时间（因为开发人员需要填写他们正在处理的错误的时间估计）。

我同意所有人的观点，JIRA会见到每个人（我提到JIRA只是因为这是我使用的方式，我敢肯定还有其他有价值的候选人）

您需要强调的是，使用JIRA之类的工具，它们不仅保留了当前设置的所有优点，而且还将获得许多新的优点。

讲故事的时间。

几个月前，我从一个星期的假期回来，发现我的整个公司倒闭了。开发部门的另一个部门几个月来一直在进行的项目突然变得紧迫而紧迫，整个团队都被撤出了他们正在努力的工作，以期将其淘汰。在当天的会议上，公司的所有者要求我们当天剔除几块，第二天其余部分剔除，我们会保持良好状态。

六个星期后，经过几乎不间断的工作/睡眠周期，我们终于交付了该产品。

我们“完成”的标准是客户没有更多反馈。以前从未出现过的每个版本的反馈（通过电子邮件发送给我们）都会出现新颖而令人兴奋的事情，而且他们所说的每个字词都立即成为规范的一部分（以短语“让我们完成就可以了”） ”）。

一天晚上很晚，我刚刚通过电子邮件和带选中标记的打印输出来管理错误报告，使HAD IT完全陷入困境。我在测试服务器上安装了螳螂，并将我刚刚收到的反馈文档加载到了其中。我将管理员设置为用户，并在我关闭问题时让他开始从中接收电子邮件。

在大约6个小时内，我整个团队就完成了。PM正在将客户端电子邮件过滤到Mantis中，开发人员正在声明并处理问题列表。更好的是，他们能够请求系统内部的澄清和沟通，从而获得了有关每个项目的详细信息的无纸化笔迹。

第二天，他们要求我由Tech Lead负责该项目的其余部分。这有点像被送上了一个手榴弹，但我还是随身携带了它。两周后，我们终于用尽了客户拉动鼻环并将其投入生产的能力。螳螂现在是我们管理错误的方式，并且可能会成为我们从项目开始就处理功能请求的方式。

TL; DR：自行安装并开始将其用于自己的东西。让它自己证明自己的价值。

顺便说一句，这是我遵循的关于版本控制的相同策略。我们在需要锁定的策略下使用Subversion，因为我的经理不信任文件合并。很好，但是在签出SVN项目后，我立即为其创建了一个本地git存储库，供我自己在开发中使用。

我们正在使用Atlassian Jira。

它有许多类似这样的报告：

您需要创建一个电子表格，当经理打开它时，所有必需的报告数据都将从您选择的应用程序中更新。如果使它起作用，则没有任何论据。

网络共享上的错误跟踪电子表格可能出错的地方：

• 当有人打开它，然后锁定工作站并去吃午饭时，没人能对其进行编辑。
  • “显而易见”的解决方法是保存新版本以进行编写。这将创建一个分支-Excel合并不好。某人的工作将会丢失。
• 该文档可以使用隐藏的行进行保存，一个问题在数周内被忽略。
• 任何内容都可以删除，历史记录跟踪功能微不足道。“我上周输入的详细问题分析发生了什么？”
• 向“受限”字段添加值很容易。“此错误的严重性如何标记为'Epic Fail'？”
• 剪切和粘贴会覆盖公式。计算很容易成为常数。

我经历了所有这些。而且我们仍然设法实现了交付……仅延迟了三个月，并花费了数千个计划外的加班时间。

“免费！” 通常是一个很好的论据。Pivotal Tracker是免费的，不需要安装，并且与低级电子表格相比，可以轻松地为您的经理提供更好的高层视图。

编辑：

令我非常烦恼的是，它刚刚宣布Pivotal Tracker不再免费提供了更长的时间。:(