Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал.

Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи.

В статье я поэтапно расскажу как мы упаковали в стандартную версию gitlab управление задачами менеджмента, проектирования, дизайна и разработки. Отдельное спасибо за помощь в подготовке материала маркетологу Ареал— Анне Бушуевой, и коммерческому директору — Максиму Щенникову.

Создание пространства в GitLab

Первое — создать пространство, где будут храниться задачи и канбан.

Организацией репозитория и веток для хранения кода занимается тимлид. Менеджер внутри репозитория может организовать пространство для управления проектом двумя способами:

Разделить проект по направлениям и вести доску внутри каждого. Для задач дизайна, frontend и backend-разработки, менеджмента создаются отдельные подпроекты, внутри которых настраиваются канбаны. Общую доску можно найти в корне проекта. Такой подход оправдан, если у каждого направления есть отдельный руководитель.
Организовать общую доску. В репозитории создается специальный менеджерский подпроект, на его доске ПМ управляет задачами всех направлений. В Ареал все процессы внутри проекта находится в руках одного менеджера, поэтому второй способ нам удобнее. А сортировать по направлениям можно через фильтр, но про него позже.

Создание структуры проекта

Второе — перенести в пространство состав проекта. Для нас это эпики — верхнеуровневые большие группы функций, которые выделяются на этапе пресейла.

Для каждого эпика создается Milestone. Известно, что вехи в gitlab предназначены не для эпиков, но нашу задачу — разделить задачи по эпикам, следить за ходом эпика — решают именно вехи.

Milestone создается с описанием:

Краткий бизнес-процесс. Если эпик большой и в целом задач много, то описание помогает ввести в курс дела нового участника команды.
Ссылки на прототип, дизайн, документацию. Пополняются с выполнением задач.
Чек-лист цикла разработки. Отражены все стадии от декомпозиции и оценки задачи, до выставления на прод и написания документации.

Эпик пополняется задачами по ходу проекта — каждой карточке при создании привязывается Milestone.

Организация этапов канбана

Третье — организовать в канбане этапы под проект. Есть стандартный набор этапов, но РП может кастомизировать их под свою терминологию, сложившуюся работу с командой.

Дефолтные этапы канбана:

open — пул открытых задач, куда складываются и идеи, и согласованные задачи на будущее.
To Do — очередь задач, планы на ближайшее время. Если исполнитель закончил одну задачу, то следующую он берет из To Do.
In Process — задачи в работе, чем сейчас заняты специалисты.
test — задачи в тестировании. На этом этапе находятся задачи не только тестирования после сдачи разработчиком, но и review дизайна арт-директором, code review тимлидом, тестирование менеджером. Можно выделить отдельные метки для каждого типа тестирования, но мы решили их не плодить.
check — завершенные задачи. Этот этап сделан для РП. Менеджер принимает решение: запустить задачу дальше по процессу или вернуть на один из предыдущих этапов.
for relise — задачи, которые ждут выкатки на prod.
stage — задачи, которые перенесены на соответствующую площадку.
prod — задачи, которые ушли на клиентскую боевую площадку.
closed — завершенные задачи.

Этапы test, stage, prod в больших проектах, где много фич в реализации, выносятся на отдельную доску. Менеджеру удобнее мониторить доставку обновлений до клиента. Представьте три релиза, 50 фичей. С первого релиза из десяти на прод ушло девять, а одна болтается, потому что клиент не успел дописать пользовательское соглашение. Теоретически задача сделана, но на прод отдать её ��ельзя.

Создание новой доски логичнее и с точки зрения исполнителей. Для разработчика задача закрыта как только она попала в For release. Провести фичи по площадкам до прода — задача devops, тестировщика, менеджера, клиента.

Организация меток для управления проектом

Четвертое — организовать систему разграничения задач по направлениям, типам, видам.

Если проект уже управляется в старом варианте gitlab или в другой системе, то на основе действующих задач составляются:

таблица статусов, которые отражают состояния задач;
список дополнительных меток.

Руководитель проектов оценивает востребованность статусов и меток — сколько задач есть по каждому параметру. Избавляется от ненужных, а рабочие переносит в gitlab.

Новый проект, который сразу управляется в gitlab, организовать проще. Менеджер по шаблону переносит стандартные метки с описаниями:

Потоковые — направления работы относительно специализации задачи:
- Manager — задачи, связанные с клиентами, документами, встречам, формализацией задачи и т.д..
- UX/UI — задачи, связанные с интерфейсами (спроектировать, отрисовать).
- DEV — задачи разработчиков, иногда разделяются на frontend и backend.
- DevOps — задачи по развертыванию среды разработки, CI/CD, доставке приложения.
- Server — задачи по инфраструктуре.
- Ideas — идеи развития проекта, на размышление. Отдельный лейбл помогает разграничить идеи от обязательных задач.

Относительно разделения меток Server и DevOps все зависит от проекта. Если управление задачами по серверам на Ареале, то нужна отдельная метка Server. Если на партнере, то для задач по инфраструктуре и среде разработки можно использовать единую метку.
Анастасия Амосова, руководитель проектов

Тип задачи:
- Task — любая открытая задача.
- Bug — правки неработающего кода.
- Block — исполнитель не может выполнять задачу по не зависящей от него причине, требует вмешательства менеджера для продолжения.
- Critical — инцидент, задача, которую нужно сделать срочно.
- Pause — задача на паузе, например специалист в отпуске.
Менеджерские — дополнительные метки для более удобной ориентации в задачах:
- org — организационные моменты (документы, счета, акты и т.п.).
- alw — регулярные задачи.
- client — зад��чи, по которым требуется активность клиента.
- docs — задачи по документации (разработчика, пользователя, администратора).

Метки спокойно живут вместе внутри любой задачи, на любом этапе.

Также как этапы метки могут меняться от проекта к проекту, от менеджера к менеджеру. Набор стандартных помогает быстрее запустить проект.

Наполнение задачами

Пятое — наполнить канбан задачами.

В зависимости от цикла жизни, мы выделяем три вида задач-карточек:

Карточка действия. Цикл жизни — от возникновения до завершения действия.
Карточка фичи UX/UI. Цикл жизни — от идеи до написания ТЗ, документации.
Карточка фичи в реализации. Цикл жизни — от оценки разработчиков до деплоя.

Карточка действия

Такие карточки отражают менеджерские задачи, не связанные с командой реализации. Например, запросить у клиента политику конфиденциальности. Эти задачи проходят небольшой жизненный цикл: open, to do, closed.

Относительно задач действия у нас возникла дискуссия. Нужно ли в Git фиксировать регулярные задачи? С одной стороны, такие задачи должны быть в голове и не жить вечно открытыми в gitlab, с другой не зафиксированная задача — не задача. Для меня на практике оказалось, что задачи типа «Выставить акты» нет смысла вносить, они болтаются в одном и том же месте, хотя менеджер прекрасно помнит о задачах.

Карточка фичи UX/UI

Карточка для задач на потоке проектирования и дизайна. Может появиться как непосредственно из задачи клиента, идей, так и прийти из бэклога.

Структура карточки UX/UI:

Ссылка на User story, Workflow, Use case, задачу в Jira. Могут быть и дополнительные артефакты. Мы оставляем ссылки на все документы, которые помогут выполнить задачу.
Чек-листы с последовательными заданиями по каждому компоненту задачи. Причем они включают не только перечень интерфейсов, которые нужно спроектировать или отрисовать, но и операционные задачи: закрыть комментарии в figma, обсудить с дизайнером UI, написать, скорректировать Use case, функциональные требования, сформировать бэклог для разработчика, пройти ревью и т.д. Детализация позволяет не пропустить небольшие организационные задачи, которые могут потеряться.
Баг-репорт. Ведется в комментариях, мы не уходим в сторонние файлы и не с��здаем новые карточки. Я в своих проектах веду баг-репорт немного по-другому: все выполненные части чек-листа переношу в комментарии, так формируется история, а баг-репорт пишу в теле задачи, обновляя чек-лист, так исполнитель может отмечать выполненные пункты.
Заметки, протоколы и итоги встреч, которые влияют на задачу.

Задача UX/UI проходит более долгий путь по канбану, потому что интерфейсы проверяют менеджер и арт-директор — добавляются этапы test, check.

Мы ввели в практику оставлять завершенные UX/UI задачи в колонке check до конца отчетного периода, чтобы наглядно виден объем проделанной работы. Плюс, если эпик большой, то разработка может идти параллельно с дизайном, интерфейс меняется на лету, а не закрытая задача, следуя через новый цикл, сохраняет историчность.

Карточка фичи реализации

Когда ТЗ или исполнительная документация написаны, менеджер создает новую карточку для нового цикла жизни задачи — от dev до деплоя. В зависимости от специфики проекта это может быть две карточки: отдельно frontend, отдельно backend. Разные разработчики, разная история тестирования, интеграции.

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

Структура карточки реализации:

Ссылки. На задачу в Jira для списания времени, на макеты в Figma, на use case, другие значимые артефакты.
Декомпозиция задачи. Тимлид для каждого компонента задачи прописывает чек-листы с критериями приемки и оценку в часах, плюс total оценку по всей задаче. По ходу решения задачи исполнитель отмечает сделанные пункты.

Таска с чек-листом тестирования. Это стандартизированный, минимально необходимой перечень пунктов самопроверки перед сдачей в тестирование. Включает общие рекомендации по загрузке контента, работе интерфейсов, баз данных, справочников.

Связанные задачи. Указываем, если нужно посмотреть как фичи работают в зависимости друг от друга.
Дополнительные работы. Те задачи, что не вошли в первоначальную оценку.
Заметки, итоги встреч, которые влияют на реализацию задачи.
Баг-репорт по фиче.

У меня багрепорт по уже выполненной задаче чаще уходит в отдельную карточку. Во-первых, это удобнее, нет множества текста в задаче. Мы привязываем баги к Milestone, по нему можно поднять историю реализации задачи. Во-вторых, карточка фичи может “вечно” быть в работе и это плохо. Иногда багрепорт отрабатывается долго, откладывается из-за низкой приоритетности, а ведь сама фича собрана и работает, а значит должна быть закрыта.
Екатерина Мочалова, руководитель проектов

Задача разработки проходит все этапы канбана. В редких случаях, когда тимлид выполнил техническую задачу и ей не нужны code review или review менеджера, задача пропускает test. Но в check остается, чтобы видеть объем проделанной работы и внести задачу в отчет.

После накопления определенного количества задач в For release, релиз последовательно проходит по площадкам stage, prod и уходит в closed.

Работа с канбаном

В работе с канбаном gitlab можно выделить два направления:

движение задач по этапам;
ежедневная рутина.

Движение за��ач по этапам

Управляют перемещением задач и сменой исполнителей тимлид, менеджер на дейли-митингах и совместных встречах. Изменение этапа и ответственного — сигнал участнику команды, что задача теперь на нем. Посмотрим на движение dev-задачи:

Разработчик делает задачу и он указан как Assignee.
Руководитель проектов перемещает задачу на тестирование и меняет исполнителя на QA.
Тимлид находит ошибки, возвращает задачу в in process и меняет исполнителя на разработчика.

Для наших проектов смена исполнителя на этапах перехода к тестированию оказалась нерабочим механизмом. На практике, будь то разработка, проектирование, дизайн, DevOps, исполнитель не меняется. Во-первых, задачи разных типов на этапе test уже подразумевают проверку определенными специалистами (тестировщик — верстка, тимлид — код, арт-директор — дизайн). Во-вторых, не нужно искать исполнителя в истории, чтобы отдать правки.
Анастасия Лебедева, руководитель проектов

Разработчик все поправил и менеджер снова отдает задачу тимлиду с соответствующей сменой исполнителя.
Тимлид принимает задачу и отдает на финальное тестирование, сменяя исполнителя на менеджера.
Если менеджер находит ошибки, то цикл начинается сначала, если все ок, то задача перемещается до For release и дальше по цепочке.

С циклом дизайна также: в моменты перехода от проектировщика к дизайнеру, потом к менеджеру, арт-директору сменяется исполнитель, но карточка остается прежней, что позволяет сохранить историю этапа в целом.

Ежедневная рутина

GitLab в стандартной версии дает отличные возможности выстроить ежедневную работу всех участников:

Исполнитель. В канбане проекта может отфильтровать задачи по себе, оценить загруженность, критичность, планы и сфокусироваться на работе. С другой стороны, он всегда видит целый проект и ощущает причастность к командной работе над большим сервисом.
Одномоментно у исполнителя в работе находится не больше двух-трех задач. Последовательность проговаривается на дейли встречах.

Если сотрудник занят на нескольких проектах и хочет видеть все свои задачи в одном пространстве — есть раздел Issues.

Для меня как тимлида с переносом менеджмента в git особо ничего не поменялось. Только при фильтрации карточек убираю задачи менеджера и ui/ux, потому что они мне не нужны.
Михаил Шатилов, тимлид

Менеджер. Внутри этапа in process, часто совместно с тимлидом, приоритезирует задачи исполнителей.
Менеджер фильтрует задачи по потоку, типу, критичности, исполнителю. По определенному Milestone строит канбан задач одного эпика.

На отдельной странице Milestones отслеживает прогресс по каждому эпику: сколько задач не стартовало, сколько назначены и делаются, сколько закрыты.

Итого

Перенос процесса управления проектом в gitlab позволил нам отказаться от разношерстных инструментов и соединить всех исполнителей в одной среде. На одной доске менеджеры видят все задачи, разбитые по этапам, и отмеченные мегапроцессными метками.

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

Резюмируя, как перейти на управление проектом в стандартной версии GitLab:

Проанализируйте, какие этапы проходит задача от идеи до попадания на прод, какие потоки возможны и какие статусы она сменяет.
Этапы распределите по колонкам канбана. Потоки, типы задач и дополнительные метки занесите в лейблы и дополните описанием.
Занесите эпики в Milestone.
Заведите культуру наполнения задачи критериями приемки, артефактами, чек-листами, оценками, лейблами.
При желании — впустите в проект представителей клиента, как членов рабочей группы со своими задачами.

Как мы упаковали управление аджайл проектов в стандартную версию GitLab