Блог

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

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

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

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

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

Мы использовали его следующим образом:

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

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

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

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

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

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

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

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

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

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

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

Твое здоровье, Николас Малдун