如何处理 JIRA/Greenhopper 中的计划外物品
我已经设置了 Jira 和 Greenhopper 并设置了初始冲刺。在我这些年里，我主要通过白板和面对面的交流来完成 Scrum。我想知道我应该如何使用 greenhopper 处理计划外的物品？我不想只是添加一张新卡并让它搞乱统计数据。当冲刺完成时，如果能够了解计划外工作的数量，那就太好了。我最初的猜测是在任务板上添加一个新卡并将其标记为计划外。但我似乎没有找到 Card 的任何 unplanned 标签。
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经使用 Greenhopper 大约 1 1/2 年了。它工作得很好，对我们的团队来说非常宝贵，但不能替代井上日常站会的便利贴。在 1.5 年里，我们最终在 Jira 中收集了许多任务、错误和其他不是立即积压的项目。管理它们是 Greenhopper 中最困难的。这些是计划外项目。
我在 Greenhopper 中设置了这些版本：
未安排：这是一个存放栏，用于存放我们可能抽出时间或可能抽不出时间的数百件物品。有些是想法，有些是我们目前无法修复的错误。
未清理的错误：当我们发现与当前冲刺工作无关的新错误时，它们会进入此处。大约每周，我们都会检查它们并将它们放入其他版本之一。
短期路线图：我们很快就会实现的内容，但不会在本次冲刺或下一个冲刺中实现。
Sprint 计划：这是我们在计划期间处理的积压工作。这是优先级较高的项目。
v2.3 - Sprint 2（或我们当前正在工作的任何版本/冲刺）：这是冲刺积压工作。
在当前的冲刺期间和冲刺计划会议之前，我会组织待办事项并将高优先级项目放入冲刺计划中，以便我们接下来处理它们。会议结束后，我们将注册的待办事项放入 v2.3 - Sprint 2 中，并由他们进行日常管理。
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
我认为当您说“计划外项目”时，您指的是需要尽快完成的关键“热修复”任务。在我的小组中，我们采用分成小组的方式。我们有一支致力于冲刺的团队。核心团队。它们是我们计算以确定在冲刺中可以完成的工作量的唯一资源。另一个规模小得多的团队称为“消防员团队”，专门负责处理计划外的关键项目，例如下一个版本中可能需要的项目。
我们并排跟踪这些。核心团队绝对不允许参与修补程序项目。然而，如果消防队员目前没有任何关键物品，则可以将其作为“仆人”的技能借给核心团队。我们对一个项目的划分通常是 4Core/2Firefighter。我们在每个冲刺中轮换消防员成员，注意不要将某人从跨多个冲刺的大项目中间的下一个冲刺中删除。到目前为止，一切都很好。我现在遇到的唯一问题是以有意义的方式跟踪并行冲刺的内容。当它成为一个真正的问题时我会解决这个问题。
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
请参阅我对 Atlassian 的功能请求并为其投票。
https://jira.atlassian.com/i#browse/GHS-11139
See my feature request to Atlassian and Vote for it.
https://jira.atlassian.com/i#browse/GHS-11139