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

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

Сначала мы открываем историю /Epic и определяем ее в нетехническом тексте.
Мы можем создавать подзадачи в истории (у меня есть технические подзадачи только сейчас).
после открытия истории. Для разработки создаются новые билеты (ошибка/новая функция/задача и т.д.), которые связаны с записью ISSUE LINKING с историей.

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

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

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

Ответ 1

Как мы это используем:

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

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

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

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

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

Ответ 2

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

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

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

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

Эпики, как правило, планируются во что угодно, кроме отставания от выпуска, поскольку они часто охватывают несколько отстающих отставаний. Оба спринтов и выпусков обрабатываются как версии Fix Versions в JIRA, развёртывание отставаний родительских/дочерних элементов помогает обеспечить визуализацию относительно планируемого.

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

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