票务分类策略

典型的工具，如JIRA或TFS/VSTS，具有与每个工作项相关联的主分类或分类学领域。在JIRA中，该字段被称为“组件”。在TFS/VSTS中，它被称为“区域路径”。票务分类策略

假设你是一个建立工具的使用和最佳实践有许多团队和许多不同的发展范围的组织，你将适用于这种“分类”栏中什么样的策略或理念在票务的工具？例如，你相信那场应该是：

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

问这个问题的另一种方式是：你亲自经历了什么样的策略？你从每个策略中获得了什么样的相对价值？

我不认为一个策略是最适合所有的情况下...

附： JIRA允许“多重选择”用于其“组件”分类字段，而VSTS对其“区域路径”分类字段具有“分层选择”。针对特定工具的答案很好，但我对这个主题更感兴趣，作为一个通用的哲学。

2016-09-30 Brent Arias

此问题是无题，因为它不在本网站适合的问题范围内，如[我可以在这里询问什么主题？]（http://stackoverflow.com/help/on-topic ）另请参阅：[我应避免询问哪些类型的问题？]（http://stackoverflow.com/help/dont-ask）您可能能够在[另一个Stack Exchange站点]（http：// stackexchange.com/sites#name），例如[pm.se]或[softwareengineering.se]。 – Makyen

为什么不是两个？至少在TFS中，您可以按照您提到的战略方向组织团队，然后让每个团队在其中定义自己的分类标准。表面上，每个团队都在研究同一个项目的不同项目或子项目，每个项目都有其独特的组织需求和分类。

来源

2016-09-30 22:48:00

你必须要考虑的是，区域/组件的分类具有一定的实用方面：

能见度 - 开发者看到问题/工作项范围的区域/组件她有权
报告 - 管理层可以构建沿面积/组件维度的汇总报告，例如了解bug密度

在高度控制的环境中，可见性可能非常重要，例如防御，即人们甚至不知道存在某物或避免泄漏敏感信息。在TFS中，这可以通过将ACL放在Area节点上来实现;我不记得JIRA具有相同的功能，但我猜可以通过问题安全来实现。在这种情况下，您必须具备某种项目/企业范围的协议，并且在实践中我看到很多分类标准与组织结构相似。

报告也很重要，设计或改变分类时，如此反复的球队不能在规定区域/组件的分类，当它被用于报告一个完全的自由必须加以考虑。

总之，对于非普通项目区/组件分类法具有被标准化为整个项目，而其他部分可以留给队为自组织共享部分。

来源

2016-10-01 08:35:07

票务分类策略

回答

相关问题