应用错误收集

时间：2013-03-14 22:07:24

标签： tfs tfs2012 versionone

[这闻起来像是“哪个更好”的问题，但事实并非如此。]

我们正在使用Team Foundation Server 2012进行版本控制和错误跟踪（这不会改变）。我们正在转向敏捷，并被要求使用VersionOne来管理流程。

我参加了一些关于VersionOne的网络研讨会。我无法就他们的Team Foundation Server集成故事得到明确的答案。我找不到Team Foundation Server 2012没有的重要功能。

我错过了什么？是否有更好的现有整合故事？有没有人有这两种产品一起工作的经验？有谁知道任何陷阱？

- 更新 -

我们已经并肩工作了一段时间，我可以分享我们的经验：

设置自动同步是（如预期的）可怕的。预计会出现停机时间和永久性的一般性瑕疵。
V1 Visual Studio插件几乎没用。它允许您从IDE中进行某些更新，但不是全部。它没有正确同步。它不提供上下文。您无法可靠地链接到任何项目。它严格来说不仅仅是来回Alt-Tabbing。
我们发现在V1（团队室，子团队，讨论）中有用和使用的少数功能将在TFS 2013中出现并且工作得更好（特别是如果您使用Lync for IM）。

TL，DR：V1非常适合它，但它是一个孤岛。所有集成都是拼凑而成的。你失去了TFS提供的几乎所有集成的好处 - 不要误会我的意思，TFS有很多很多很多瑕疵，但是能够把故事链接到一个缺陷到一个缺陷讨论到一个将团队Wiki上的文档发送到特定版本只是非常好笑。

- 更新 -

我们刚开始使用Coded UI进行白盒测试，而且功能非常强大。在这一点上，不得不使用VersionOne只是讨厌。

答案 0 :(得分：2)

如果你正在使用TFS 2012，那么我仍然会质疑为什么你认为你需要另一种工具来“敏捷”。

我相信TFS 2012的最新更新已经改善了敏捷的工作支持，所以这仍然可以正常工作。根据您选择的敏捷工作实践，您可以选择Scrum或Kanban风格。

可能引起更多思考的一些问题：

说实话，如果你需要的话，你可能只是在粘滞便笺上“敏捷”。

答案 1 :(得分：1)

我碰巧找到了这个答案，寻找其他的东西，这是我亲自回答的一个，所以无论如何我都在这里，我觉得这是一个更真实的答案。

V1集成对开发人员非常有用（您可以根据任务需要检查代码）。我用过这两个。也许对于开发人员来说，TFS更好（假设他们只是检查代码），但对于优秀的Scrum Master和产品负责人来说，*

VersionOne击败TFS在线动手

*。主要原因是V1更快地管理和操纵故事，组织，确定优先级并且报告更好。

TFS online在Scrum / Sprint方面有很多不足之处管理。

如果您正在创建，拆分，合并故事并将故事分解为任务，那么这将是缓慢而繁琐的。在V1上执行相同操作的过程效率提高100％，更容易，更快。如果我不得不使用TFS来管理积压工作，那么我会把头发拉出来，而V1则报告了敏捷开发的报告。

TFS中的一个示例是，您无法将接受标准细分为单个测试，并在计划日为其分配时间，这会导致您的sprint计划失败。你能用TFS来管理它吗？确保定制和链接到其他工作类型，但这是一个痛苦的对接。

V1具有发布预测，未来两周内您的团队的容量规划，为离岸团队构建的扑克规划以及为敏捷开发而构建的整体规划。

您的开发人员只需要针对任务检查代码即可。您的Scrum主/产品负责人住在该工具中，应该真正使用最适合他们的工具。

所以两者兼用。它没有错。在线使用TFS只是为了存储您的代码。将V1用于其他一切。

答案 2 :(得分：0)

我整合了两个用于演示。客户已强制要求VersionOne 和 TFS。我无法回答你为什么会这样做，但就如何做到这一点来看看他们的开源项目：

二进制文件在这里：

您基本上运行一个msi，它安装一个Web服务，该服务从TFS注册事件并转发签入或构建数据到VersionOne。

然后，您可以安装他们的签到策略，要求开发人员将用户故事与签到关联起来。

我个人觉得整件事情有点笨重。例如，一旦你编辑代码就会弹出他们的故事选择器对话框，而不是当你准备好登记时。他们的插件至少崩溃了我的Visual Studio实例一次。

所以底线，你可以使用甚至整合两者，但我认为当TFS本身运作良好时，没有理由增加笨拙。