在jira项目中使用组件的最佳实践

时间:2009-08-02 16:00:10

标签: jira

我们在日常开发中大量使用Jira。我想看看在Jira中创建项目组件是否有任何最佳实践?

例如,在您看来,为Jira中的每个开发模块创建组件是否更好?或者您的团队更喜欢更精细的组件?

8 个答案:

答案 0 :(得分:27)

组件就像小子项目。当人们将人们聚集在一起时,项目似乎最有用。我向客户推荐JIRA项目在某种程度上反映了社会组织,至少在项目数量变得非常大之前。

另外,请避免使用名为“Misc”或“Other”的组件。它们往往成为人们不关心的问题的废物堆。

答案 1 :(得分:17)

关于组件最重要的是明确而不是太多。在我们的团队中,我们正在迁移到3级层次结构(在GreenHopper意义上):

  • 在顶层你有BA组件很少,并由团队(下面,后端,GUI)划分 - 这有助于BA人员将请求路由到指定为组件负责人的正确DEV团队经理。
  • 第二级是实际过程(在Unix意义上)。这是非常明确的定义。如果问题映射到多个进程,我们将其分配给其中一个进程(BTW,GreenHopper不允许多个叶子组件,但普通的JIRA会这样做)。这是由DEV管理员完成的。
  • 第三级是可选的,很少使用,表示过程中的子系统。当相关部分问题与代码中明确定义的部分相关并且我们想要单独跟踪它们时,我们使用它。这通常由处理该问题的开发人员完成。

为了使这种渐进式细化工作,您需要了解谁在分配哪个组件以及谁在处理分配给它的问题。后者由Component Lead表示,前者未得到JIRA的明确支持(或者我们可以说BA只看到他们的组件,DEV管理员,只有他们的子组件+所有BA等)。

答案 2 :(得分:12)

我会将组件与您的模块/工件/ jar进行匹配,因此每个问题都可以由特定模块拥有(尽管它可能与其他模块具有依赖关系/关系)。

如果您能够提出比模块级别更精细的问题管理,请考虑为什么您不会将相关模块分开。

通过这种1-1映射有助于阐明您的发布计划,您可以轻松地解决项目版本X的问题,以及需要集中精力的模块。它还有助于简化Jira,构建系统和SCM之间的关联,例如:如果您使用Bamboo,则每个模块可能会有一个构建项目,因此您只需添加关联。

答案 3 :(得分:11)

从4.2.4开始,无法对组件进行版本控制,只能对项目进行版本控制。如果您想使用路线图功能,请记住这一点。

长期(7年以上)要求为组件添加版本控制:

http://jira.atlassian.com/browse/JRA-3501

答案 4 :(得分:10)

为每个主要模块或甚至系统层(例如Backend,Frontend)创建一个组件。我不会低于模块级别的粒度。 您可以添加支持活动的组件,例如BA,测试(同意mdoar)...... 组件与版本/发布正交

答案 5 :(得分:5)

我现在有另外一个组件。
对于客户,我将“组件”字段称为:

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.

因此,要再次回答原始问题,请问自己是否按团队或您提到的罚款级别分配问题?
可能是前者。

答案 6 :(得分:2)

JIRA旨在让项目的每个组件都具有相同的版本号集,因此如果您希望组件具有独立的版本号,您需要为每个组件设置不同的项目或使用我开发的插件允许组件特定的版本号,同时允许将组件分组到一个包中。该插件为"Component/Subcomponents/Bundle Versions for JIRA",可在Atlassian Marketplace中找到。有关更多信息,请访问atlassian plugins help page。另一种选择是强制团队的每个组件具有相同的版本号集。否则,很难为组件选择正确的版本号。

答案 7 :(得分:1)

我们使用2级组件层次结构(感谢greenhopper ......) - 主题和史诗。 Greenhopper Themes和Epics中的构建不会让我们聚合并报告我们想要的方式,这很好地解决了这个问题。