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

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

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

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

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

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

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

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

1. Epic — самая большая задача, из частей которой складывается работа над проектом. Для реализации такой задачи нужно выполнить несколько меньших задач. Эпик у нас длится спринт и больше.
2. Story — описание задачи без подробностей. В рамках этой задачи выполняются подзадачи, которые должны привести к результату, описанному в Story. Особенность: после закрытия задачи Story должна быть создана задача с заданием на реализацию выработанного решения.
3. Task — конкретная задача с четким описанием, которая требует выполнения. Длится в течение спринта.
4. Bug — задача, связанная с ошибкой в коде.
5. Easy-task — небольшая задача с упрощенным Workflow без статусов Review и Test.
6. Sub-task — конкретная далее неделимая задача с подробным описанием. Часть Story, Task, Bug или Easy-task.
7. 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 можно чётко отследить время на выполнение задачи, даже если она была в руках разных ответственных. Кроме этого, в задаче есть несколько показателей времени, которые исполнитель заполняет сам.

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

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

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

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

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

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

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

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