har*_*rms 20 project-management scrum jira greenhopper
当使用Greenhopper和Jira时,很明显Greenhopper正在使用Jira问题中的"固定版本"字段来表示正在处理问题的scrum sprint.这本身就有点苛刻,因为可以想象一个问题可以在多个冲刺中进行,并且因为问题和冲刺之间的关系正是它在冲刺期间已经被处理过的,并且认识到你可能无法完成计划时间内的任务.
但好吧,它可能是一个可以忍受的黑客,至少如果没有其他任何东西试图使用"固定版本"字段的其他东西.
但我发现还有其他问题也建立在"固定版本"字段上.具体而言,应该能够看到计划在哪个版本(现实版本)中解决哪些问题,并将此信息用作验证/ QA的手段.
其他Greenhopper用户如何结合"固定版本"字段的这两种用法？您是否将sprint版本设置为发布版本的子版本？您是否在发布版本中使用了一些自定义字段？我发现这很困难,因为scrum团队正在研究多个组件,独立版本.此外,可能在同一个组件上发生错误修复版本和功能开发,发生在同一个sprint上.
总而言之,我发现团队将在同一个sprint中开发"Some Product 3.4.0"(一个功能版本),"Some Product 3.3.1"(一个修正版本)和"Other Product 1.2"是不可避免的. .将这个sprint标记为这三个版本中的每个版本(跨两个不同的组件)都是不可能的.在Greenhopper中制作三种不同的冲刺,真的会稀释Greenhopper的价值.
其他Greenhopper用户处于同样的情况吗？你是怎么处理的？
小智 13
这里有两个问题.
首先,您的sprint版本实际上是您的发布版本的"颠覆".这意味着您的故事实际上在fixVersion字段中获得了两个值.
您可以通过设置主版本在Greenhopper中进行配置.
因此,如果您有1.0版的3 sprint版本,那么您将发布日期设置为1.0并将您的故事放在sprint 1,sprint 2和sprint 3中,这样
当您在Sprint 1中播放STORY-1时,您会发现STORY-1的fixVersion为"1.0,Sprint 1"
对于您要跟踪发布但不在sprint中的项目,只需将fixVersion设置为1.0即可.
其次(这只是一个提示),您可以使用单独的项目进行冲刺工作和生产支持工作.这在大型组织中很有用
我们在各种组织中遇到了同样的问题,其中一个团队不仅处理多个版本(例如您在示例中详细说明),而且还有团队在提出客户问题时参与帮助支持组织的情况.当先前版本的用户验收测试时,立即显示"需要处理"的问题.
因此,我们引入了一个概念,其中问题与任务分离,但使用JIRA的"问题链接"功能链接在一起.问题(或我们称之为的规范)在发布项目中进行管理,而任务则在团队项目中进行管理.
发布项目中的版本控制表示发布(即2.2-patch1,1.1 ......)团队项目中的版本控制表示冲刺(sprint 10-15,sprint 10-20)
发布项目只包含错误,功能请求,查询.团队项目只包含任务,故事,......
自动化允许我们使规范和相关任务保持同步:典型情况如下
规范的转换将自动触发.规范和任务之间的这种分离概念允许您支持许多不同的项目组织 - 例如
如果有兴趣,我可以为您提供有关此主题的更多信息.
弗朗西斯马滕斯
我也一直受到同样问题的困扰,并在jira/greenhopper中找到了功能请求,为sprint添加了一个新字段,以便独立跟踪sprint和发布版本信息.
如果你想像我一样看到这变成现实,那么请转到http://jira.atlassian.com/browse/GHS-945并投票支持该问题.这句话总结道:"如果GreenHopper作为一等公民进行迭代......"
目前,我们可能不得不在jira中创建一个名为版本的新字段,并使用它来跟踪与问题相关的"真实产品版本".我们的源代码存储库中也有一个提交钩子,因此当开发人员进行提交时,它将使用与他们提交的源代码相关的"真实产品版本"更新jira票证.我们将此信息保存在配置文件中,以便提交挂钩知道要用于哪个版本的源代码存储库/路径.这不是理想的,但它是我们目前唯一的选择.