在jira项目中使用组件的最佳实践
我们在日常的开发中大量使用Jira。 我想看看是否有任何在Jira中创build项目组件的最佳做法？
例如，你认为最好为Jira中的每个开发模块创build一个组件，或者你的团队更喜欢细粒度的组件？
组件就像小的子项目。 将人们聚在一起时，项目似乎是最有用的。 我向客户推荐JIRA项目在一定程度上反映了社会组织，至less在项目数量变得非常大的情况下。
另外，避免使用名为“Misc”或“Other”的组件。 他们倾向于成为无人关心的问题的浪费。
对组件最重要的是明确而不是太多。 现在在我们的团队中，我们正在迁移到3级层次结构（GreenHopper意义上的）：
- 在顶层，您拥有很less且由团队（infra，backend，GUI）描绘的BA组件 – 这可以帮助BA们将请求发送给作为组件负责人指派的正确的DEV团队经理。
- 第二个层次是实际的过程（在Unix意义上）。 这是非常明确的定义。 如果问题映射到多个进程，我们将其分配给其中的一个（顺便说一下，GreenHopper不允许多个叶子组件，但是普通的JIRA不会）。 这是由DEV经理完成的。
- 第三级是可选的，很less使用，表示过程中的子系统。 当相当一部分问题与代码中明确定义的部分相关时，我们使用它，我们希望分开跟踪它们。 这通常由开发人员处理这个问题。
为了使这种渐进的改进工作，你需要知道谁分配给哪个组件以及谁处理分配给它的问题。 后者由Component Lead表示，前者没有被JIRA明确支持（或者我们可以说BA只能看到他们的组件，DEVpipe理器，只看到他们的子组件+所有的BA，等等）
我会用你的模块/工件/ jar来匹配组件，所以每个问题都可以由一个特定的模块拥有（尽pipe它也可能与其他模块有依赖关系）。
如果您可以提供比模块级别更好的粒度问题pipe理，请考虑为什么您不会将相关联的模块分开。
有了这个1-1映射有助于澄清你的发布时间表，你可以很容易地发现你的项目的版本X有什么问题，以及哪些模块需要集中精力。 它还有助于简化Jira，构build系统和SCM之间的关联，例如，如果您使用的是Bamboo，则可能每个模块都有构build项目，因此您可以简单地添加关联。
从4.2.4开始，不可能对组件，只有项目进行版本化。 请记住，如果你喜欢使用路线图function。
有一个长达7年以上的要求来为组件添加版本控制：
为每个主要模块创build一个组件，甚至可以是系统层（例如后端，前端）。 我不会去模块级以下的粒度。 您可以添加支持活动的组件，例如BA，Testing（与mdoar同意）…组件与版本/发行版是正交的
我现在又拿了一个组件。
对于客户，我将“组件”字段称为：
A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.
然后我说：
If you don't care about automatic assignment, just treat the components field as a convenient system field.
所以要再次回答原来的问题，问问自己是否按团队分配问题或按照您提到的优先级别分配问题？
可能是前者。
JIRA旨在使项目的每个组件都具有相同的版本号集合，所以如果您希望组件具有独立的版本号，则需要为每个组件设置不同的项目，或者使用由我开发的允许特定组件的插件版本号，同时允许将组件分组。 该插件是“JIRA的组件/子组件/捆绑版本”，并在Atlassian Marketplace上提供。 有关更多信息，请访问atlassian 插件帮助页面 。 另一个select是强制团队的每个组件拥有相同的一组版本号。 否则，为组件select正确的版本号非常困难。
我们使用2级组件层次结构（感谢greenhopper …） – Themes和Epics。 在Greenhopper主题和Epics中的构build不会让我们聚集和报告我们想要的方式，这个技巧很好。
