当您在visual studio 2013/tfs2012中签入与任务关联的工作时，您可以"关联"或"解析"该任务。将其设置为"resolve"将自动将sprint积压工作和看板上的任务移动到"Done"。这很好，因为作为一名开发人员，您只需要使用正确的状态进行登录，并且任何地方的状态都可以：-）。
"Bug"类型的工作项似乎不是这样——在这里，我只能在vs2013中选择"关联"，然后我还需要手动输入web访问权限，并将Bug设置为"完成"。所以我做了两次同样的工作。
我可以在不自定义TFS工作项类型或流程模板的情况下将此错误状态设置为"已解决"吗？
这绝对是可能的-我们对每个bug都使用"resolve"（在敏捷模板下），因为它节省了很多时间。在挂起的更改中，只需关联bug（键入其工作项id，或将bug拖放到挂起更改的区域），然后您就可以"关联"或"解决"它。（之后，创建者可以验证修复并关闭它）
我认为你使用的模板没有提供这种功能，所以也许可以将你的模板与标准敏捷模板进行比较，你可能会找到允许这种行为所需的调整。您使用的模板是否支持Bug的"已解决"状态？也许它不见了？
如果只是你的bug模板跳过了"已解析"状态，那么重命名等效状态（也许只是因为没有正确命名或不在正确的组中而没有被UI选中？）或使用WIT编辑器插入一个新状态都是微不足道的。
在签入时设置bug确实不是一个好主意。编码器是否验证了完成的输出符合done的定义？他们怎么可能希望在办理入住手续之前做到这一点呢？
一个bug，就像PBI一样，当开发团队作为一个团队决定输出是完整的，并且他们已经达到了要求质量的标准时，就会变成灰色。
在Scrum模板中，Bug是向国防部确认的产品级项目。然而，您可以在sprint计划会议上将该错误分解为多个任务，这些任务都可以得到解决。错误的工作流程是：
1） 测试人员由于测试失败而创建的Bug。
2） Bug被开发团队接受进入sprint。
3） Bug被分解为至少用于编码和测试工作的任务。
4） 编码器修复了错误并解决了他们的任务。签入将此任务标记为"完成"。
5） 测试人员对测试用例进行验证，以证明bug的存在。他们将任务标记为完成。
6） 开发团队与国防部会面并评估Bug的完成情况。如果完成，他们会将其标记为完成。
错误流与任务不同。
- 出现错误（测试人员/用户/开发人员）
- Bug已修复（开发人员）
- Bug已测试（构建、集成到主构建、部署、由测试人员测试）
- 错误已完成（由发起人签字）
是错误的一般流程，TFS ALM假设修复和测试将由两个不同的角色完成。
如果要更改此项以反映任务工作流，则必须更改模板
我们也使用Microsoft。VSTS。行动。签入操作以在开发和QA状态之间转换错误。开发人员可以关联或解析，并且解析会触发状态更改尝试。但是，如果转换中需要任何字段，例如"根本原因"，则转换将失败，不会出现任何错误消息。这很不幸。如果错误弹出并说"请输入此字段"，那就太好了。如果在签入之前填写了必填字段，那么状态转换就会按预期进行。