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

Для команд, которые разрабатывают ПО, 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.

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

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

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

Тот, кто ответственен за задачу, перемещает её по всему Воркфлоу. Вот такой путь проходят задачи в наших проектах в 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. Для них используется упрощенный Воркфлоу.

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

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

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

• 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, напишите нам.