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

Мои коллеги сталкиваются с таким же «зоопарком» площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — 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, организовать проще. Менеджер по шаблону переносит стандартные метки с описаниями:

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

Анастасия Амосова
менеджер проектов
Относительно разделения меток Server и DevOps все зависит от проекта. Если управление задачами по серверам на Ареале, то нужна отдельная метка Server. Если на партнере, то для задач по инфраструктуре и среде разработки можно использовать единую метку.
2. Тип задачи:
   • Task — любая открытая задача.
   • Bug — правки неработающего кода.
   • Block — исполнитель не может выполнять задачу по не зависящей от него причине, требует вмешательства менеджера для продолжения.
   • Critical — инцидент, задача, которую нужно сделать срочно.
   • Pause — задача на паузе, например специалист в отпуске.
3. Менеджерские — дополнительные метки для более удобной ориентации в задачах:
   • 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.
• Заведите культуру наполнения задачи критериями приемки, артефактами, чек-листами, оценками, лейблами.
• При желании — впустите в проект представителей клиента, как членов рабочей группы со своими задачами.