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

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

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

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

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

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

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

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

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

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

• Тип задачи:
  — 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.
• Заведите культуру наполнения задачи критериями приемки, артефактами, чек-листами, оценками, лейблами.
• При желании — впустите в проект представителей клиента, как членов рабочей группы со своими задачами.