png png
к ленте

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

Январь'24

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

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

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

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

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

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

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

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

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

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

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

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

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

Areal Gitlab

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

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

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

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

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

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

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

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

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

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

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

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

  1. Потоковые — направления работы относительно специализации задачи:
    • Manager — задачи, связанные с клиентами, документами, встречам, формализацией задачи и т.д..
    • UX/UI — задачи, связанные с интерфейсами (спроектировать, отрисовать).
    • DEV — задачи разработчиков, иногда разделяются на frontend и backend.
    • DevOps — задачи по развертыванию среды разработки, CI/CD, доставке приложения.
    • Server — задачи по инфраструктуре.
    • Ideas — идеи развития проекта, на размышление. Отдельный лейбл помогает разграничить идеи от обязательных задач.
  2. anastasiya-amosova
    Анастасия Амосова
    менеджер проектов
    Относительно разделения меток Server и DevOps все зависит от проекта. Если управление задачами по серверам на Ареале, то нужна отдельная метка Server. Если на партнере, то для задач по инфраструктуре и среде разработки можно использовать единую метку.
  3. Тип задачи:
    • Task — любая открытая задача.
    • Bug — правки неработающего кода.
    • Block — исполнитель не может выполнять задачу по не зависящей от него причине, требует вмешательства менеджера для продолжения.
    • Critical — инцидент, задача, которую нужно сделать срочно.
    • Pause — задача на паузе, например специалист в отпуске.
  4. Менеджерские — дополнительные метки для более удобной ориентации в задачах:
    • org — организационные моменты (документы, счета, акты и т.п.).
    • alw — регулярные задачи.
    • client — задачи, по которым требуется активность клиента.
    • docs — задачи по документации (разработчика, пользователя, администратора).

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

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

Areal Gitlab

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Ссылки. На задачу в Jira для списания времени, на макеты в Figma, на use case, другие значимые артефакты.
  • Декомпозиция задачи. Тимлид для каждого компонента задачи прописывает чек-листы с критериями приемки и оценку в часах, плюс total оценку по всей задаче. По ходу решения задачи исполнитель отмечает сделанные пункты.
Areal Gitlab
  • Таска с чек-листом тестирования. Это стандартизированный, минимально необходимой перечень пунктов самопроверки перед сдачей в тестирование. Включает общие рекомендации по загрузке контента, работе интерфейсов, баз данных, справочников.
Areal Gitlab
  • Связанные задачи. Указываем, если нужно посмотреть как фичи работают в зависимости друг от друга.
  • Дополнительные работы. Те задачи, что не вошли в первоначальную оценку.
  • Заметки, итоги встреч, которые влияют на реализацию задачи.
  • Баг-репорт по фиче.
Areal Gitlab
ekaterina-mochalova
Екатерина Мочалова
менеджер проекта
У меня багрепорт по уже выполненной задаче чаще уходит в отдельную карточку. Во-первых, это удобнее, нет множества текста в задаче. Мы привязываем баги к Milestone, по нему можно поднять историю реализации задачи. Во-вторых, карточка фичи может «вечно» быть в работе и это плохо. Иногда багрепорт отрабатывается долго, откладывается из-за низкой приоритетности, а ведь сама фича собрана и работает, а значит должна быть закрыта.

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

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

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

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

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

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

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

  • Разработчик делает задачу и он указан как Assignee.
  • Руководитель проектов перемещает задачу на тестирование и меняет исполнителя на QA.
  • Тимлид находит ошибки, возвращает задачу в in process и меняет исполнителя на разработчика.
anastasiya-lebedeva
Анастасия Лебедева
менеджер проекта
Для наших проектов смена исполнителя на этапах перехода к тестированию оказалась нерабочим механизмом. На практике, будь то разработка, проектирование, дизайн, DevOps, исполнитель не меняется. Во-первых, задачи разных типов на этапе test уже подразумевают проверку определенными специалистами (тестировщик — верстка, тимлид — код, арт-директор — дизайн). Во-вторых, не нужно искать исполнителя в истории, чтобы отдать правки.
  • Разработчик все поправил и менеджер снова отдает задачу тимлиду с соответствующей сменой исполнителя.
  • Тимлид принимает задачу и отдает на финальное тестирование, сменяя исполнителя на менеджера.
  • Если менеджер находит ошибки, то цикл начинается сначала, если все ок, то задача перемещается до For release и дальше по цепочке.

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

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

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

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

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

Areal Gitlab
mikhail-shatilov
Михаил Шатилов
тимлид
Для меня как тимлида с переносом менеджмента в git особо ничего не поменялось. Только при фильтрации карточек убираю задачи менеджера и ui/ux, потому что они мне не нужны.
  • Менеджер. Внутри этапа in process, часто совместно с тимлидом, приоритезирует задачи исполнителей.
    Менеджер фильтрует задачи по потоку, типу, критичности, исполнителю. По определенному Milestone строит канбан задач одного эпика.
Areal Gitlab

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

Areal Gitlab

Итого

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

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

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

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