JIra + Greenhopper - как правильно сделать Agile

Question

Я новичок в Agile-потоке в JIRA + Greenhopper. Я пытаюсь понять, как правильно / лучше работать Agile в JIRA + GH. Я читал в сети некоторую информацию - до сих пор я понимаю, что у нас есть Истории и Эпосы (которые являются БОЛЬШИМИ историями). Я хотел знать, каков порядок создания задач:

1. Сначала мы открываем историю / эпос и определяем ее в нетехническом тексте.
2. Мы можем создать подзадачи для истории (у меня есть технические подзадачи только сейчас).
3. после открытия истории - Для разработки создаются новые заявки (ошибка / новая функция / задача и т. Д.), Которые связываются с помощью ПРОБЛЕМЫ, СВЯЗАННОЙ с историей.

Это правильный поток? Мои вопросы:

1. Я не понимаю, почему в (2) мы должны открывать подзадачи для технических проблем, если я отдельно открываю тикеты разработки и связываю их вместе - так какова цель подзадач в истории?
2. Есть ли лучший / простой способ создания билетов для разработчиков прямо из GH? или я должен открыть их по отдельности и связать с проблемой родительского сюжета?

Большое спасибо за быстрый ответ.

Answer 1

Как мы его используем, выглядит следующим образом:

1. Мы создаем историю, чтобы определить запрос функции (нетехническое задание на вашем языке)

Когда мы планируем итерацию, мы расставим приоритеты в истории, которую мы хотим достичь.Для каждой истории команда создаст задачи (подзадачи) о том, как построить историю.Эти задачи - конкретные вещи, которые необходимо выполнить: создать таблицу базы данных, изменить код контроллера, проверить функцию, обновить общедоступную документацию и т. Д .;наряду с человеком, который будет выполнять задачу, и их оценкой в ​​срок.

По мере выполнения итерации каждый член команды регистрирует свою работу по каждой задаче, а также уточняет свои оценки по задаче, поскольку у них есть большеИнформация.Когда задача завершена, она закрыта.Когда все задачи завершены, история готова к развертыванию.

Кроме того, если вы создаете подзадачи, если вы выбираете добавить подзадачи из вида карты под колесом, это принесетвверх карту, чтобы ввести элементы в задаче (аналогично созданию карты), где вы можете продолжать создавать карты подзадач до завершения.По нашему мнению, очень быстрый и простой способ ввода задач.

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

Answer 2

Я думаю, что важно отметить, что поток отличается от команды к команде.

Например, у некоторых команд есть владелец продукта, который начинает с Epic, а затем разбивает его на истории, добавляя критерии приемлемости / условия успеха по мере продвижения. Часто в этом сценарии команда собирается вместе на сессии планирования и разбивает эти истории на подзадачи.

Некоторые команды дают оценку сюжетных баллов (как правило, фибоначчи) историям, другие выделяют часовую оценку для подзадач. При распределении часовых оценок команды часто обновляют оставшуюся оценку по мере их выполнения. Это дает хорошее указание на часовом графике выгорания, каков прогресс спринта.

Я также видел команды, в которых владелец продукта создает множество историй и объединяет их вручную в Epics позднее. Если бы у меня был предпочтительный метод, это был бы первый подход для простоты, но всегда будут Истории, которые пропущены / забыты и добавляются во время сеанса планирования.

Эпики, как правило, планировались во что-либо, кроме невыполненного релиза, поскольку они часто охватывают несколько заданий спринта. И спринты, и выпуски обрабатываются как Версии исправлений в JIRA, вложение родительских / дочерних резервов помогает обеспечить визуализацию того, что планируется.

Это для разборок. Если вас интересует канбан, тогда я могу поделиться тем, что, как я видел, команды делают в этом сценарии, просто скажите слово.

Cheers, Николас Малдун