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

Вот как мы его использовали:

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

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

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

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

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

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

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

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

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

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

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

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