Jira实战 | 解决结果Resolution字段说明

什么是解决结果？

解决结果回答了：“问题关闭的原因是什么？”如果工作完成了，问题可能会被注记为"Done"或是"Fixed"；但如果问题和其他问题重复的情况，这个理由会被注记为"Duplicate"；又如果问题无法重现，解决结果可能会是"Won'tDo"或是"Won't Fix"，

 

尽量避免使较长的状态名称，如"Closed as Complete"或"Closedas a duplicate”。解决结果通常在问题"已解决"的情况下进行设置，问题的解决结果字段一般都是"未解决"，直到这个字段的值设置后，才会呈现"已解决"。

 

 

陷阱

有一家公司有太多的解决结果，以致于他们为特定项目创建自定义字段展示一个解决结果的子集。然后使用工作流的后处理功能来复制自定义的值到解决结果字段，自定义字段和解决结果的差异产生了前端和后端应用程序上的错误。公司应该限制解决结果的选项适用于所有的项目，而不是去解决这个问题。

 

建议

一旦问题被注记为“已解决”，你的用户将会访问你之前置放在工作流中的移转界面，或者，你可以使用后处理功能来自动设置解决结果，最好是能够让用户来设置适当的值，但是即使是通用的值如"Fixed"都好过关闭问题后呈现默认的"未解决"的值。

 

当问题重开的时候，可以使用工作流移转的后处理功能来清空“解决结果”字段的值。

 

 

批量更新解决结果

当清理混乱的情况，就像之前提到的例子，最好能够使用“批量变更”的功能，但是你不能够用这样的方法来更新问题的解决结果，这就表示你必须使用有点特殊和变通的策略来帮助你清理解决结果列表，每个策略都有优点和缺点，请慎重使用。

 

工作流转换

建一个临时性的工作流移转来使用后处理功能更新解决结果。 

 

• 优点:  这个动作会留下审计的线索，因为变更会被记录在问题历史的一部分。

• 缺点:  你需要在每一个状态、每一个工作流之中创建一个新的移转和后处理功能，可以意味著有大量的手动工作，另外，每个变更都会产生大量的邮件通知。

 

第三方插件

你可以使用类似“ScriptRunner for JIRA”的插件来实现这件事情，这个插件具有"BulkFix Resolutions"的功能。

 

• 优点: 这个变更非常的快速，你不需要创建任何一个新的工作流的移转行为而且没有任何邮件通知。

• 缺点:  这个变更不会留下审计的痕迹，问题更新日期不会变更而且审计日志的不会有任何记录。

 

其它

虽然存在其它的选项，但是不推荐，这取决于问题的范围，可能是最好或是最容易地去修正新问题(issue)“遗漏的解决结果”的问题(problem)，并且保持既有的问题正常。

 

（1）在其它应用上去修正 (例如Excel)

导出有故障的问题，新添解决结果的值并且重新导入问题，"外部问题导入"的功能能够提供问题的更新，只要在其中提供单一键值去映射即可，或者，你可以导入到新的项目。

 

（2）向后转换

将问题向前移转到未解决的状况，在工作流的移转添加设置解决结果，并且将这些问题批量关闭或是将他们批量移转到适合的状态。

 

 

（3）数据库上直接更新

任何直接在数据库上变更的方法都是不建议的，如果你决定承担风险，至少这么做：

• 备份数据， 

• 验证备份，

• 在非生产环境上完整地测试这个变更 ，

• 让数据库管理员待命，

• 有一个健全的回滚计划来防止任何意外的结果。

 

陷阱

有一家公司有34种解决结果的选项，其中包含特殊的选项如，"Rejected by Security Team"和"Rejectedby Finance Team"，此外，没有其他部分能拒绝请求的选项可选，许多的选项可能是不合理的。例如，问题呈现已解决的解决结果，怎么可能同时又处在“进行中(In Progress)”的状态？

 

有一家公司没有在工作流进行中设置解决结果，结果，不管问题状态如何，用户看到所有的问题都呈现在“分配给我”的仪表盘小工具上，这是因为小工具的查询假设所有结果结果呈现未解决的问题都是未完成的。

 

建议

把"未解决"当做一个保留字，绝对不要添加这个保留字到你的解决结果选项列表。

 

将解决结果选择列表(其它的也是如此)按照字母排序，好让用户能够轻易发现他们熟悉的术语。

 

不要使用"On Hold"或是"None"做为解决结果的选项，这些听起来就像是问题没有真正解决，这些选项的类型都是不建议且令人混淆的。

 

不要使用"Wrong Project"或"Wrong Type"做为解决结果的选项，如果问题创建在错误的项目之中，被注记为已解决会是个麻烦事，相反地，使用"移动"的功能将问题移动到正确的项目才是好的作法。

 

不要创建极为特殊的解决结果，例如你可能不会需要类似"Rejectedby Finance"、"Rejected by Legal"和"Rejected by CEO"，简单通用"Rejected"的选项已经足够了。只有当特殊需求或是当数据需要经常被查询的情况才会使用非通用的选项。

 

关于本书

本文节选自《JIRA策略管理实战手册》，为应用程序管理员提供配置、清理和维护Jira的模板。

此实战手册包含：

• 152条建议- 帮助您设置、清理和维护Jira

• 50个工作表，以及其他相关模板、代码片段和示例- 帮助您建立和简化主要工作

• 33个需避免的反面真实案例

• 每个管理区域的最佳实践和注意事项

• 我作为管理员犯下的十大错误

此实战手册向您展现：

• 精心策划并得以实施的行动项

• 工作流管理的简单方法

• 如何审计及清理应用程序

• 维护和扩展Jira的方法

• 如何创建可重复的流程

• 如何远离“Jira沼泽”

 

推荐阅读

Jira实战 | 关于IssueType

Jira实战 | 用户访问策略