Как мы работаем над проектами в Jira

June 13 2023

Для команд, которые разрабатывают ПО, Jira — идеальная среда контроля и постановки, особенно для удаленных команд. Расскажем, как мы работаем над проектами в системе.

Преимущества Jira
Постановка задач
Процесс работы над задачами
Структура задачи
Обязательные поля
Необязательные поля
Оценка задач
Показатели здоровья проекта
Главная причина работы в Jira

Преимущества Jira

Jira — гибкий инструмент. Есть много разных таск-трекеров: Basecamp, Trello, Asana, но Jira — не просто программа, она позволяет настраивать и контролировать бизнес-процессы по разработке до мельчайших подробностей. Она может работать как тот же Basecamp или Trello, но на самом деле возможности намного шире.

Не важно, делаете ли вы плакаты или программы, — все равно должен быть стандартизированный производственный процесс. Так вот, если есть регламент, то Jira поможет оцифровать его и контролировать.

Возможности для настройки управления проектами в системе практически безграничные:

  • диаграмма Ганта,
  • диаграмма сгорания задач,
  • управление временем,
  • расстановка задач по приоритетам,
  • фильтры,
  • делегирование задач,
  • отслеживание объема работы в процентном соотношении,
  • настраиваемые scrum и kanban-доски,
  • и многое другое.

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

Однако кроме явных преимуществ у Jira есть один, на мой взгляд, серьезный недостаток — ее сложно настраивать. Система не подходит для работы в команде, у которой еще не построены бизнес-процессы. Да, можно скрыть большинство функций и оставить в Jira функции, аналогичные, например, Trello. Но это нерациональное использование системы с лишними расходами на ее использование.

Если вы только начинаете бизнес по разработке, лучше выберите что-то более простое, а потом, набив шишки и выстроив все процессы, смело переходите на Jira.

Постановка задач

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

В нашей команде мы используем 7 типов задач:

  • Epic — самая большая задача, из частей которой складывается работа над проектом. Для реализации такой задачи нужно выполнить несколько меньших задач. Эпик у нас длится спринт и больше.
  • Story — описание задачи без подробностей. В рамках этой задачи выполняются подзадачи, которые должны привести к результату, описанному в Story. Особенность: после закрытия задачи Story должна быть создана задача с заданием на реализацию выработанного решения.
  • Task — конкретная задача с четким описанием, которая требует выполнения. Длится в течение спринта.
  • Bug задача, связанная с ошибкой в коде.
  • Easy-task — небольшая задача с упрощенным Workflow без статусов Review и Test.
  • Sub-task — конкретная, далее неделимая задача с подробным описанием. Часть Story, Task, Bug или Easy-task.
  • Quick-subtask — маленькая конкретная далее неделимая задача с упрощенным Workflow без статусов Review и Test. Часть Story, Task, Bug или Easy-task.

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

Задачи Story, Task, Bug, Easy-task появляются в бэклоге. Сразу после создания задачи Jira в отдельном окне предлагает переместить ее в текущий спринт.
Для перемещения задачи между спринтами можно использовать поле Sprint в окне просмотра задачи.

Процесс работы над задачами

Мы работаем над задачами по недельным спринтам. Каждую неделю планируем задачи на новый спринт, проводим ретроспективу — мероприятие, на котором выясняем успехи и неуспехи команды за неделю. Те таски, что не были выполнены в текущем спринте, переносятся на следующий спринт.

Наш Воркфлоу.

Тот, кто ответственен за задачу, перемещает её по всему Воркфлоу. Вот такой путь проходят задачи в наших проектах в Jira:

  1. Новая задача автоматически получает статус Backlog.
  2. После переноса задачи в спринт, она готова к работе и получает статус Ready4Dev.
  3. Разработчик взял задачу в работу и прямо сейчас трудится над ней — статус Development.
  4. Разработчик пошел спать, переключился на другую задачу, выключил компьютер или как-то иначе отвлекся от выполнения текущей задачи — он ставит статус On Hold.
  5. Задача готова, и результат работы требует одобрения руководителем? Способ об этом сообщить — поставить статус Review.
  6. Если ревьювер решил, что задачу нужно дорабатывать, то он ставит её в статус On Hold, а разработчик уже потом в Development. То есть возвращаемся на пункт 3.
  7. Если задача требует доработки — Development.
  8. Задача одобрена, и нужно тестирование — статус Ready4Test.
  9. Тестировщик взял задачу на тестирование и прямо сейчас тестит — статус Testing.
  10. Задача прошла тестирование и готова к мержу с продакшном — статус Ready4Merge.
  11. Статус Canceled используется только в том случае, если задача перестала быть актуальной и больше не нужна, либо её выполнение по какой-то причине нужно прервать.
  12. Выполненные задачи переносятся в статус Merged.

Все задачи перемещаются по четкому Воркфлоу без пропуска этапов, за исключением специальных задач Quick-subtask и Easy-task. Для них используется упрощенный Воркфлоу.

Упрощенный Воркфлоу.

Структура задачи

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

Пример задачи проекта в Jira.

Обязательные поля

  • Summary (Название задачи) — кратко, что нужно сделать; желательно, использовать глагол в инфинитиве: сделать, создать, исправить и так далее.
  • Description (Описание) — собственно, само описание. Дать столько информации, чтобы этого хватило для самостоятельной работы над задачей без дополнительных вопросов.
  • Labels (Метки или теги) — ярлык для задачи по теме: Backend, Frontend, Design, Data, OPS.
  • Reporter — ответственный за постановку задачи — тот, кто ее создавал.
  • Priority — приоритет задачи: Highest, High, Medium, Low. Обычный приоритет для задачи — Medium.

Необязательные поля

  • Linked Issues — ссылки на связанные задачи, которые как-то относятся к создаваемой. Нужно выбрать подходящую связь: relates to, blocks, is blocked by и т.д.
  • Epic Link — ссылка на Epic, для которого создаваемая задача будет его частью. Не работает для подзадач.
  • Component/s — подраздел проекта, к которому относится задача. Компоненты используются для объединения задач в рамках проекта в небольшие группы по выбранной логике. Для каждого компонента определен свой ответственный, он назначается на задачу автоматически при выборе компонента для задачи.

Оценка задач

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

  • Time Spent (Work Log)время, фактически затраченное на работу с задачей
  • Time Estimateвремя, которое планируется затратить на задачу
  • Remaining Timeоставшееся время на выполнение задачи

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

Поработал над задачей — запиши затраченное время.
Поработал над задачей — запиши в комментариях, что было сделано.

Показатели здоровья проекта

Ещё одна причина, по которой мы ведём проекты в Jira — прозрачность процессов. Руководитель проекта и участники всегда видят, что и на каком этапе находится.

Мы определяем несколько критериев здорового рабочего процесса, когда можно говорить, что проект будет выполнен успешно:

  1. Наличие бэклога с актуальными задачами.
  2. Наличие текущего или активного спринта с приоритетными задачами.
  3. Наличие планируемого спринта.
  4. Полное описание каждой задачи в активном спринте.
  5. Своевременная оценка времени по задачам и заполнение нужных на данном этапе полей в карточке задачи.
  6. Ежедневная смена статуса задач, которые были взяты в работу.
  7. Логирование затраченного на работу времени.
  8. Отсутствие задач, застоявшихся в спринте больше, чем на 2 недели.
  9. Использование разных типов задач.

Главная причина работы в Jira

  • Достаточно перемещать задачу по статусам, и Jira сама обо всем напомнит или сделает за вас.
  • Автоматизация рабочего процесса – половина успеха и эффективности работы над проектом.

Если у вас есть вопросы по Jira, напишите нам.

Автор статьи
Кирилл Гришанин
Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Подписаться на новости блога

      Подписаться на обновления блога

      Коворкинг Starthub

      Б. Новодмитровская ул., 36, стр. 12, вход 6,
      Москва, Россия, 127015

      Коворкинг Wework

      Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

      © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.