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

ash*_*osh 58 jira

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

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

mdo*_*oar 27

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

另外,请避免使用名为"Misc"或"Other"的组件.它们往往成为无人关心的问题的废物堆放.


ddi*_*rov 17

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

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

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


Ric*_*ler 13

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

如果您能够建立一个比模块级别更精细的问题管理,那么请考虑为什么您不会将相关模块分开.

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


M. *_*ley 12

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

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

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

  • 我开发了一个插件,该插件允许JIRA中的组件级别版本号。它还允许使用通用版本号对捆绑包中的组件进行分组。您可以在插件的帮助页面上找到更多信息:http://jiraplugins.denizoguz.com/plugin-help/ (2认同)

Vla*_*iev 10

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


mdo*_*oar 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.

那么,要再次回答原始问题,请问自己是否按团队或您提到的精细级别分配问题?
可能是前者.