票务分类策略

Question

典型工具（如JIRA或TFS / VSTS）具有与每个工作项关联的主要分类或分类字段。在JIRA中，该领域被称为＆＃34;组件＆＃34;。在TFS / VSTS中，它被称为＆＃34;区域路径。＆＃34;

假设您是一个为具有许多团队和许多不同开发范围的组织建立工具使用和最佳实践的人，您将采用什么策略或理念来对此进行分类＆＃34;您的票务工具中的字段？例如，您认为该字段应该是：

• 战术使用。这意味着每个团队都会定义分类，而不考虑其他团队或项目。
• 策略性地使用。这可能意味着企业架构团队为整个产品（或可能是组织）定义了官方分类，并且在创建工作项时教会团队如何使用此分类法。

提出这个问题的另一种方式是：你个人经历过什么策略，你从每个策略中获得了什么相对价值？

我不认为一种策略最适合所有情况......

P.S。 JIRA允许＆＃34;多选＃34;因为它的组件＆＃34;分类字段，而VSTS具有＆＃34;分层选择＆＃34;因为它的＆＃34;区域路径＆＃34;分类领域。特定于特定工具的答案很好，但作为一般哲学，我对这个主题更感兴趣。

Answer 1

为什么不两者兼而有之？至少在TFS中，您可以按照您提到的战略路线组织团队，然后允许每个团队在其中定义自己的分类。表面上看，每个团队都在研究同一个项目的不同项目或子组件，每个项目都有自己独特的组织必需品和分类。

Answer 2

您必须考虑区域/组件分类法具有一些实用方面：

• 可见性 - 开发人员查看她有权获得的区域/组件范围内的问题/工作项目
• 报告 - 管理层可以在“区域/组件”维度上构建汇总报告，例如了解错误密度

在高度受控的环境中，可见性非常重要，例如防御，人们甚至不知道存在某些东西或避免泄露敏感信息。在TFS中，这可以通过将ACL放在Area节点上来实现;我不记得JIRA具有相同的功能，但我想可以通过Issue-security实现。 在这种情况下，您必须拥有某种项目/企业范围的协议，并且在实践中我发现很多分类法类似于组织结构。

报告也很重要，在设计或更改分类时必须予以考虑，因此，当用于报告时，团队无法完全自由地定义区域/组件分类。

总之，对于非平凡的项目，区域/组件分类法具有为整个项目标准化的共享部分，而其他部分可以留给团队进行自组织。