问题标签 [task-tracking]

是否有任何带有命令行界面的任务跟踪系统？

以下是我感兴趣的功能列表：

• 简单任务模板
  类似于带有属性：类型对的纯文本文件，例如：

• 命令行界面
  例如：

• XCopy 部署
  它应该不需要安装繁重的 DBMS

• 多用户支持
  所以它不仅仅是一个人的待办事项列表

我可能在问世界，但是否有任何基于 Windows 的软件可以轻松管理大量任务/项目以及所有可以快速导航/搜索的相关文档（电子表格、Word 文档、其他文件）。

我处理大约 10 到 20 个活跃的项目和任务，有些只持续一天左右，有些持续数周，有些持续数月。我喜欢将任何项目的所有内容都保存在一个文件夹中，但在保存电子表格、SQL 脚本时，或者如果我想将网站快捷方式拖到文件夹中以便在我可以找到它时，我似乎永远都在浏览文件夹树需要它。

我尝试了各种文件夹组织（即顶级项目目录，然后按部门或个人或应用程序细分），但无论我尝试什么，找到我正在寻找的东西仍然太耗时。最接近我正在寻找的东西就像 Lotus 在 DOS 时代在他们的议程程序中所拥有的那样，您可以在其中以多种方式组织和查看数据，我希望能够用一个不错的快速 Windows 做同样的事情将与 Explorer 完全集成的应用程序，因此当询问我在哪里保存某些内容时，它会知道我正在积极从事哪些项目，甚至可能进行一些最小的项目管理，以便当我将事情标记为完成时，它们的目录将不再出现，或者如果某物被标记为高优先级，它将显示在顶部或用颜色编码。

编辑： 将用户定义的标签添加到资源管理器，过滤可能会完成 90%；如果我可以定义 10 - 20 个标签，并且在资源管理器中有一个选项来显示单个标签，那么它将只显示任何具有标有该标签的内容的文件夹。如果您可以有一个选项卡式界面，每个标签对应一个选项卡，那就更棒了。Mac 在文件上使用颜色编码的用户标签至少 10 年了。我不想问Vista是否有这个，但如果有的话我会看看它。

我最近一直在使用Wakoopa，我觉得它很有趣。

我不知道（我有一个想法，但从来没有得到关于它的真实数据）关于我在 SO 上花了多少时间，直到这个：

替代文字 http://img396.imageshack.us/img396/4699/wakoopaim1.png

所以我的编程问题是：

如何以编程方式跟踪正在使用的应用程序？

我最初的想法是使用“tasklist”命令和“netstat”之类的东西，每 15 分钟使用一次池或类似的东西，但我认为这不是他们这样做的方式。

.NET 中是否有一个库（我猜是 C# 中的）来执行此操作？Windows 是否提供这样的某种服务？爪哇呢？

对于如何执行某些编程任务，我通常至少有一些模糊的想法，但对此我一无所知。

wakoopa 应用程序跟踪器也适用于 OSX 和 Linux，但我很清楚它们是三个不同的应用程序，每个平台一个

顺便说一句，你用了多少 SO？:)

有没有人推荐一个好的任务/时间管理工具。

理想情况下，这将只跟踪编程任务/项目以及花费的时间以及生成周末报告的选项将是有利的

我知道这与编程无关，而与时间管理有关，但我重视本网站用户的反馈。这个学期我发现自己特别忙，管理工作和学校之间的各种任务和时间表。此外，我发现自己在实验室、工作、家庭、图书馆等之间奔波。出于这些原因，我认为基于 Web 的解决方案是理想的。这就引出了一个问题，您是否有推荐的基于 Web 的个人使用任务/项目管理解决方案？Ideal 将是免费的（或几乎免费），并且可以安装在我的服务器上。会计不是必需的，只是时间和任务的管理（甘特图会很棒）。然而，svn 集成会非常好，因为我把我的学业留在那里。

谢谢！

更新

我对此给予了赏金，因为一个好的解决方案对我来说非常有价值（比代表更有价值）。到目前为止，答案都很好，但没有一个适合个人使用。理想的东西是用我可以自己托管的东西来管理文件和时间。当我们在校园实验室中使用 MAC OSX 时，这将是 MAC+PC 解决方案的一个优势。目前，SVN 和基于网络的时间管理器似乎是要走的路。

更新 2

首先，感谢您的精彩回复！FogBugz、Trac 和 Request Tracker 要么被强烈推荐，要么被多次推荐。Trac 和 Request Tracker 也是免费和自托管的，但是，它们的优势似乎在于团队开发。我将试一试 FogBugz on Demand，看看效果如何。我也将按照建议开始使用 Drop Box，好主意！此外，SVN将用于“一切”的长寿。这应该围绕 2 gig 问题和自托管需求。我正在考虑使用 SVNNotifier 来保持机器最新。再次感谢！

结论

我决定按照 Zabbala 的建议使用FogBugz 。正如他所说，它确实可以满足我从任务跟踪到时间管理的所有需求。这是 FogCreek 提供的惊人而慷慨的免费产品。谢谢大家，我真的很感谢所有的反馈。

跟进

只是为了跟进这个项目。我已经使用 FogBugz 两个星期了；再开心不过了。我已经开始将LiveScribe 的 SmartPen与 FogBugz 结合使用。我将长期项目保留在 FogBugz 中，并将本周的项目复制到道路的“期刊”中。SmartPen 使数字化“日记”变得轻松。

为了管理文件，我混合使用了 FogBugz、DropBox、SVN 和 Unison。我使用 DropBox 在网络上共享，例如在家庭和实验室之间共享，并使用 Unison 在更大的 SVN 工作副本中同步 DropBox 文件夹（并非所有内容都在 DropBox 中）。

长期跟进

我一直在使用fogbugz 来支持LiveScribe 的日记。似乎传统的笔和纸具有难以超越的效率。关于 LiveScribe，我遇到了一些问题，这让我对他们的文件格式感到不舒服。他们的文件在命名约定和格式上都被掩盖了。如果他们有一个开放的格式，我会觉得把我的数据委托给它会好得多。

长期随访（3 年以上）

我已经改用维基媒体来记录我的工作/时间/研究。对于任务管理，我一直在使用 Google 应用Insightly。这种组合感觉更自然，并且“卡住”了。wiki 路线真的很有用...

*更长期的随访（7 年以上）*

我已经切换到使用 Trello 板进行任务管理。在我的一个错误导致数据库丢失后，我已经不再使用 wikimedia。

在默认的 TFS 设置中，存在三种工作项类型：方案、任务和错误。最后一个非常简单，而且任务也很简单：这是团队成员要完成的特定工作。但我认为场景有点模糊。

我通常为更大和更一般的工作单元创建一个场景：例如“创建功能以将员工行添加到雇主”。更小、更具体的工作项将是任务，例如：“创建详细信息表单。”、“在服务器上创建保存方法。”等

当我签入更改时，我将更改集链接到场景和特定任务。这是一个好习惯吗？你如何处理任务和场景？最佳实践的任何资源？

我也听说场景实际上是针对用例的，是这样吗？

在工作中，我们目前使用 Trac 来管理我们的测试用例。但是，我们有不少 TC 列在测试计划 wiki 页面而不是票证上。

我的经理最近对更好地记录手动测试的结果产生了兴趣。虽然这是一个崇高的目标，并且 QA 团队中的一些人对这个想法非常热衷，但我实际上觉得如果执行不正确，这样一个系统的开销可能是灾难性的。事实上，我能想到的唯一合理的非 Trac 集成解决方案只是一个简单的任务管理器，我们可以在其中存储和管理更随意的结果，例如“X 在 Env blah 上运行了组件 Y，并且存在这些问题”。我认为从 wiki 移植几个 TC 编号和内容需要很长时间，并且某种系统，如“X 在 Y 时验证 TC 23423432 并且它正在通过”仅适用于有那么多测试用例（以及一个小团队）。

我见过一些用于 Trac 的插件，它们允许您创建测试计划等并报告结果 - 但没有什么令人兴奋的。有没有人有使用这些工具的经验？与 trac 集成将大大减少开销，但我们仍然存在并非每个 TC 都作为票证提交的问题，我们必须解决这个问题。

你对这样的项目有什么建议？你有过类似的情况吗？您的意见将不胜感激，因为我不想成为团队中唯一的反对者并且看起来很懒惰，因为我认为在如此小的团队中过度组织手动测试将是有害的。

我有一个小型软件项目，有几个客户。我正在寻找具有以下能力的东西：

1. 客户端可以提交功能请求、错误或任务
2. 客户可以看到打开和关闭问题的状态
3. 客户端可以看到更改日志
4. 我发布更新或新闻的地方

很高兴拥有：

• 客户只能看到他们发布的问题；不是其他客户的
• 托管解决方案

到目前为止，选择似乎是压倒性的。我看过Mantis和Hiveminder。Unfuddle 似乎非常接近。我已经避免了 FogBugz 的价格（这似乎有点矫枉过正）和 Trac 因为我试图避免自己托管一些东西。大多数现有解决方案似乎都面向开发人员团队，而不是针对开发人员-客户关系。有人有什么建议吗？

Git中有没有办法为分支提供“描述”？

虽然我尝试使用描述性名称，但在单个分支上工作一段时间有时会削弱我对为什么创建其他一些主题分支的记忆。我尝试为分支使用描述性名称，但我认为“描述”（关于分支目的的简短说明）会很好。

每当我在 git 中创建主题分支时，我一直在开发一个系统来保留 BRANCH_DESCRIPTION 文件。就像其他人提到的那样，我有时也会忘记我创建分支的目的，即使我尝试给它起一个描述性的名称。

我一直主要解决 SO 问题如何告诉 git 始终选择我的本地版本以在特定文件上进行冲突合并？，但是我遇到了没有调用自定义合并驱动程序的情况，因此合并的主题分支中的文件会覆盖本地分支。例如：

此时 BRANCH_DESCRIPTION 将被简单地覆盖，因为无论是否为文件设置了自定义合并驱动程序，主分支的描述都没有改变。

有任何想法吗？