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