Как обращаться с незапланированными предметами в JIRA / Greenhopper - PullRequest
1 голос
/ 18 февраля 2011

Я установил Jira и Greenhopper и настроил начальный спринт. Я в основном занимался скрамом в течение своих лет через доску и общение лицом к лицу. Интересно, как мне обращаться с незапланированными предметами, используя greenhopper? Я не просто хочу добавить New Card и заставить его испортить статистику. Было бы неплохо иметь возможность получить показатель количества незапланированных работ, когда спринт сделан. Моим первоначальным предположением было добавить New Card на Task Board и пометить его как незапланированное. Но я не вижу тега unplanned для Card.

Ответы [ 3 ]

5 голосов
/ 20 февраля 2011

Я использую Greenhopper около 1 1/2 лет. Это работает довольно хорошо и неоценимо для нашей команды, но не заменяет пост-он на хорошо для ежедневного противостояния. За 1,5 года мы собрали множество задач, ошибок и других элементов в Jira, которые не являются предметами немедленного отставания. Управлять ими - самое сложное в Greenhopper. Это внеплановые предметы.

У меня установлены следующие версии в Greenhopper:

Внеплановое: это ручка для хранения нескольких сотен предметов, которые мы можем или не можем найти. Некоторые - идеи, некоторые - ошибки, которые мы не можем исправить на данный момент.

Неубранные ошибки: поскольку мы находим новые ошибки, которые не связаны с работой текущего спринта, они появляются здесь. Каждую неделю или около того, мы просматриваем их и помещаем в одну из других версий.

Краткосрочная дорожная карта: материал, к которому мы скоро вернемся, но не в этом или следующем спринте.

Планирование спринта: это отставание, из которого мы работаем во время планирования. Это предметы с более высоким приоритетом.

v2.3 - Sprint 2 (или любая другая версия / спринт, над которой мы сейчас работаем): это отставание спринта.

Во время текущего спринта и перед нашей сессией по планированию спринта я организую отставание и помещаю высокоприоритетные элементы в планирование спринта, чтобы перейти к ним в следующий раз. После собрания мы помещаем элементы, которые мы регистрируем, в v2.3 - Sprint 2, и они управляют им ежедневно.

0 голосов
/ 03 сентября 2014

См. Мой запрос на добавление Atlassian и проголосуйте за него.

"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"

https://jira.atlassian.com/i#browse/GHS-11139

0 голосов
/ 08 февраля 2013

Я думаю, что когда вы говорите «незапланированные предметы», вы имеете в виду критические задачи «оперативного исправления», которые необходимо выполнить как можно скорее. В моей группе мы используем сплит-команду. У нас есть одна команда, которая принимает участие в спринте. Основная команда. Это единственный ресурс, на который мы рассчитываем, чтобы определить объем работы, которую мы можем выполнить в спринте. Другая, намного меньшая группа, называемая командой пожарных, отведена для работы с незапланированными, критическими элементами, которые, например, могут понадобиться в следующем выпуске.

Мы отслеживаем это бок о бок. Основная команда НИКОГДА не имеет права работать над элементом исправления. Однако команде пожарных разрешается передавать свои навыки в качестве «слуг» основной команде, если у них нет критических предметов в данный момент. Наш разделенный на один проект, как правило, 4Core / 2Firefighter. Мы вращаем участников Firefighter каждый спринт, стараясь не удалять кого-либо из следующего спринта, который находится в середине большого проекта, охватывающего несколько спринтов. Все идет нормально. Единственная проблема, которую я имею сейчас, - это отслеживание значимых параллельных спринтов. Я займусь этим, когда это станет реальной проблемой.

...