Для команд, которые разрабатывают ПО, 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:
- Новая задача автоматически получает статус Backlog.
- После переноса задачи в спринт, она готова к работе и получает статус Ready4Dev.
- Разработчик взял задачу в работу и прямо сейчас трудится над ней — статус Development.
- Разработчик пошел спать, переключился на другую задачу, выключил компьютер или как-то иначе отвлекся от выполнения текущей задачи — он ставит статус On Hold.
- Задача готова, и результат работы требует одобрения руководителем? Способ об этом сообщить — поставить статус Review.
- Если ревьювер решил, что задачу нужно дорабатывать, то он ставит её в статус On Hold, а разработчик уже потом в Development. То есть возвращаемся на пункт 3.
- Если задача требует доработки — Development.
- Задача одобрена, и нужно тестирование — статус Ready4Test.
- Тестировщик взял задачу на тестирование и прямо сейчас тестит — статус Testing.
- Задача прошла тестирование и готова к мержу с продакшном — статус Ready4Merge.
- Статус Canceled используется только в том случае, если задача перестала быть актуальной и больше не нужна, либо её выполнение по какой-то причине нужно прервать.
- Выполненные задачи переносятся в статус 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 — прозрачность процессов. Руководитель проекта и участники всегда видят, что и на каком этапе находится.
Мы определяем несколько критериев здорового рабочего процесса, когда можно говорить, что проект будет выполнен успешно:
- Наличие бэклога с актуальными задачами.
- Наличие текущего или активного спринта с приоритетными задачами.
- Наличие планируемого спринта.
- Полное описание каждой задачи в активном спринте.
- Своевременная оценка времени по задачам и заполнение нужных на данном этапе полей в карточке задачи.
- Ежедневная смена статуса задач, которые были взяты в работу.
- Логирование затраченного на работу времени.
- Отсутствие задач, застоявшихся в спринте больше, чем на 2 недели.
- Использование разных типов задач.
Главная причина работы в Jira
- Достаточно перемещать задачу по статусам, и Jira сама обо всем напомнит или сделает за вас.
- Автоматизация рабочего процесса – половина успеха и эффективности работы над проектом.
Если у вас есть вопросы по Jira, напишите нам.
