我们在日常开发中大量使用Jira.我想看看在Jira中创建项目组件是否有任何最佳实践?
例如,在您看来,为Jira中的每个开发模块创建组件是否更好?或者您的团队更喜欢更细粒度的组件?
mdo*_*oar 27
组件就像小子项目.当人们将人们聚集在一起时,项目似乎最有用.我向客户推荐JIRA项目在某种程度上反映了社会组织,至少在项目数量变得非常大之前.
另外,请避免使用名为"Misc"或"Other"的组件.它们往往成为无人关心的问题的废物堆放.
ddi*_*rov 17
关于组件最重要的是明确而不是太多.在我们的团队中,我们正在迁移到3级层次结构(在GreenHopper意义上):
为了使这种渐进式细化工作,您需要了解谁分配给哪个组件以及谁正在处理分配给它的问题.后者由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
我现在有另外一个组件.
对于客户,我将"组件"字段称为:
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.
那么,要再次回答原始问题,请问自己是否按团队或您提到的精细级别分配问题?
可能是前者.
| 归档时间: |
|
| 查看次数: |
57372 次 |
| 最近记录: |