5 шагов к Agile с инструментами JIRA

06 января 2017
Дата публикации
5 шагов к Agile с инструментами JIRA
  • Тренды в тестировании
Менеджер в компании «Точка качества», сертифицированный Scrum-мастер и SAFe Agilist, рассказывает об инструментах JIRA, которые позволяют планировать Agile-проекты, управлять ими и отслеживать эффективность работы команды.

Как инструменты jira помогают выполнить работу по гибким методологиям?

Под «работой» подразумевается любая рабочая задача: написание тестовой документации, составление плана по тестированию, проведение регрессионного теста или подготовка обучающего мероприятия в центре компетенции.

В первую очередь эта статья будет полезна тем, кто:
  • Постоянно «жонглирует» большим количеством задач на одном или нескольких проектах.
  • Хочет предложить заказчику или команде реализовать на базе JIRA Kanban или Scrum, но ещё не имеет полного представления о том, как это сделать.
  • Уже работает с JIRA Agile Plugin или имеет о нём общее представление, но хочет расширить свои знания.
Начнём. У каждого менеджера проекта есть to-do list из рабочих задач и, возможно, даже не один. У кого-то список состоит из множества мелких задач одного проекта, у кого-то включает несколько проектов.

Нередко выполнение задач зависает, при этом к ним постоянно добавляются новые. Мы периодически перебираем этот список и верим, что вот завтра, хотя нет, лучше в понедельник начнём разбирать его. Знакомо?

Продуктивно решать все возникающие задачи – это один из постулатов работы по гибким методологиям. Однако не стоит ждать, когда к вам придёт проект, который должен быть выполнен по Agile. Возьмите свой текущий проект и сами реализуйте его с соблюдением Agile-принципов.

Для этого достаточно выполнить 5 шагов.

Шаг 1 — создание и настройка agile board


Создайте борд (Jira-Agile-Getting Started), на котором вы будете отслеживать ход выполнения задач и управлять ими в бэклоге. Борд можно сделать как для задач конкретного проекта, так и для выборки, в которую будут входить несколько проектов.

Вот так выглядит Agile Board по умолчанию:

jira1_standart_board.webp
Теперь настроим его под себя.

jira2_agile_board_custom_example.webp

Настраиваем колонки (Columns). Они будут отражать жизненный цикл задач. При этом можно настроить произвольное количество колонок и дать им свои названия.

На борд можно добавить дорожки (Swimlanes), которые помогут структурировать задачи. Среди доступных вариантов можно выбрать дорожки по группе задач (Epics), по исполнителю (Assignee) или по задачам (Stories). Последний вариант особенно удобен, если активно используются подзадачи. Также дорожки можно настроить по собственным фильтрам (или вовсе обойтись без них).

jira3_lines_agile.webp

Для того чтобы скрыть или, наоборот, показать специфические задачи, можно добавить быстрые фильтры (Quick Filters) и, например, отфильтровать только задачи на обновление тестовой документации или задачи конкретного QA-инженера. В JIRA фильтры задаются через JQL-запросы.

jira4_filters.webp

В конце нужно определиться, в каких единицах будут оцениваться задачи. Самые распространённые варианты – это стори-поинты (Story Points) и часы, но могут быть и другие единицы, предлагаемые JIRA.

Шаг 2 — упорядочение списка задач в бэклоге


jira5_board_backlog.webp

jira6_agileboard_order.webp

После того как Agile Board создан в режиме «Планирование» или в бэклоге (в JIRA это зависит от версии), нам становится доступен удобный интерфейс для превращения хаотичного списка задач в упорядоченный бэклог.
  • В каждом из проектов создаём группы задач (Epics), которые будут отражать основные направления деятельности. Например, усовершенствование процессов, обновление тестовой документации, регрессионные тесты.
  • Можно также обозначить и релизы, т. е. сроки, к которым надо что-то завершить.
  • Сами задачи из to-do list станут пользовательскими историями (user stories), связанными с направлением работы и при необходимости привязанными к релизу.

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

Итак, мы создали и настроили Agile Board в JIRA и составили бэклог задач. Что же дальше?

Шаг 3 — планирование спринтов

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

  • Определяем продолжительность Agile спринта. Решите, будет ли это неделя, две недели, месяц или другой период времени.
  • Считаем емкость (Capacity) команды на спринт.

Capacity – объем работы, который команда может сделать в течение спринта. Эта цифра учитывает доступность людей, а также тот факт, что люди будут работать над задачами спринта не всё своё время. Часть времени будет уходить на коммуникацию внутри команды и другие активности.

Например:
Размер команды – 2 специалиста, занятых полный рабочий день.
Продолжительность спринта – 2 недели.
Общее количество рабочих часов – 160. При этом мы знаем, что одному из инженеров нужно пройти тренинг по веб-сервисам (16 часов) и на коммуникацию по задачам у команды уходит 20% рабочего времени.
Итого, capacity на спринтовые задачи получится (160-16)*0,8=115,2 ч.

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

Шаг 4 — выполнение спринта

Настало время выполнить набранные задачи, т. е. завершить спринт.

На шаге 1 мы создавали и настраивали Agile Board. Теперь он поможет нам проследить, на каком этапе находится каждая из задач, кто и какую задачу выполняет.

Можно сразу назначить каждой задаче исполнителя. Если ваша команда достаточно самоорганизованная, то ребята могут сами брать себе задачу из списка свободных. Как только пользователь передвигает задачу в In Progress, он автоматически становится ее исполнителем.

Если вы регулярно логируете время и обновляете Remaining Time, то сможете использовать график сгорания, или график хода выполнения работ (Burndown Chart). Он покажет ваш прогресс по отношению к цели спринта и поможет оценить шансы на его успешное завершение.

Серая линия на графике показывает идеальный ход выполнения проекта.

Красная линия – объём незакрытых задач, зелёная – потраченное время. Если красная линия справа снизу встречается с серой в одной и той же точке – это лучший вариант развития событий.

jira7_burndown_chart_example.webp
На примере выше у команды явно есть проблемы: объем выполненной работы заметно меньше запланированного. Если они не ускорятся в последние дни спринта, то не успеют завершить все запланированные задачи в срок.

jira8_burndown_chart_example2.webp

Эта же команда идет с опережением, и ей стоит подыскать себе дополнительные задачи, если положительный тренд сохранится.


Шаг 5 — завершение спринта, ретроспектива

Этот шаг хоть и последний, но не менее важный. Agile — это не только борды, стори и спринты. Это также поиск узких мест и усовершенствование процесса.

Поэтому после нажатия на кнопку End Sprint стоит потратить немного времени, чтобы посмотреть, как всё прошло, т. е. провести ретроспективу.
И не расстраивайтесь, если первый спринт у вас будет «комом».

Ретроспектива: на что обратить внимание?

  • Отчет по спринту покажет: какие задачи вы смогли завершить, а какие нет; добавили ли вы дополнительные задачи в спринт или, наоборот, что-то из него исключили, потому что поняли, что не справитесь.
  • Анализируем график хода выполнения работ. Если в рамках спринта не удалось закрыть все запланированные задачи, разбираемся, что и в какой момент времени пошло не так.
  • Если в качестве группы задач (Epics) вы использовали крупные задачи, например «Провести регрессию всего приложения на уровне МАТ», то отчёт покажет, сколько работы вам ещё осталось. Похожую картинку можно получить и в контексте релиза, если все ваши задачи привязаны к какой-то версии.
  • И наконец, можно оценить велосити (Velocity) и посмотреть, сколько работы вы планировали, а сколько в итоге получилось выполнить. Эта информация будет более полезна в случае, если вы оцениваете пользовательские истории в стори поинтах.

Velocity – это скорость работы команды, тот объём, который команда может завершить за спринт. Завершить – это значит закрыть задачу и переместить ее в колонку Done.

Вот мы и выполнили последний шаг нашего Agile-проекта.

Как видите, 5 шагов к Agile действительно просты. Давайте ещё раз их перечислим:

  1. Создать и сконфигурировать Agile Board.
  2. Упорядочить задачи в бэклоге.
  3. Запланировать спринт.
  4. Выполнить спринт.
  5. Провести ретроспективу.

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