Регламент движения задач
У нас на повестке сотни задач, а мы еще даже не начали разработку, у нас еще нет багов, нет фич-реквестов, а значит задач будет больше. Как всем этим управлять?
А еще хорошо бы иметь прозрачный процесс движения задачи, чтобы в любой момент времени можно было понять где и что происходит и как-то на это влиять. Мне нравится аналогия с конвейером, где задача это заготовка, которая двигается по ленте и в конце превращается в готовый продукт. Или аналогия с режимом Бога, когда весь процесс можно увидеть на одном экране, настраивать его и управлять им.
Но все это половина проблемы. Вторая и наиболее важная, требует особого контроля с вашей стороны, это настоящий бич дизайн-систем — рассинхрон между дизайнерской документацией и фактической реализацией. Чаще всего эта проблема возникает вследствие того, что изменения в репозитории с документацией и кодом попадают в разное время, не одновременно.
Чтобы разом решить все проблемы, построим правильный регламент движения задач.
Окружение
Все наши проблемы осложняются инженерной инфраструктурой, например, у нас может быть 5 репозиториев: документация, бэкенд, фронтенд, ios, android. Это значит, что нужно как минимум 5 веток для внесения изменений. А еще сложность с документацией, ведь есть гайдлайн для десктопного представления, а есть для мобильного. Вот и еще две ветки. Как прокинуть изменения и не запутаться?
Чтобы разом решить все наши проблемы, надо договориться с разработкой, что репозиториев у нас сколько угодно, но бэклог всегда один. Хочешь прокинуть изменения в репозиторий? Заводи Issue в своем репозитории и добавляй задачу в общий бэклог.
А общий бэклог мы построим на базе проекта в Github.
Давайте создадим проект и попробуем разобраться со всем на примере задачи. Чтобы работа с проектами стала доступна в репозитории, включить настройку функцию Projects в настройках репозитория на вкладке General.
У вас появится новая вкладка Projects:
Нажмите на кнопку New project и выберите проект Product launch:
Перейдите в настройки проекта. Придумайте название и настройте команды:
Теперь включите в проект все наши задачи из раздела Issues. Для этого перейдите в раздел Issues, выделите все задачи и выберите ваш проект:
Теперь перейдите в проект. Здесь несколько вкладок, у каждой из которых свое предназначение и функции. Например, вклада Prioritized backlog дает вам широкие возможности по управлению бэклогом, здесь можно отслеживать приоритеты, исполнителей, команды, статусы и оценки:
Перейдем на вкладку Status board. Здесь мы настроим регламент движения задач, за которым можно будет следить в разрезе команд:
Чтобы лучше со всем разобраться, давайте посмотрим на типичную задачу:
Что тут есть:
- есть какое-то описание в рамках DoR
- установлены метки, по количеству репозиториев, участвующих в изменении
- команда-инициатор задачи
- приоритет наивысший
- оценка 0, потому что это родительская задача, ее не оценивают
Самое интересное в разделе sub-issues:
- [Docs. Web] Страны #39: в рамках этой задачи дизайнер прокинет изменения в репозиторий с дизайнерской документацией. Изменения будут касаться только веб-представления справочника.
- [Docs. Mob] Страны #43: тоже самое, но изменения касаются только мобильного представления.
- [Web] Страны #40: задача для веб-разработчика, для внесения изменений в репозиторий с веб-приложением.
- [iOS] Страны #41: для ios-разработчика.
- [Android] Страны #42: для android-разработчика.
- [Backend] Страны #44: для доработок на бэкенде.
Именно саб-таски получат ответственного, свой приоритет, оценку и поедут по статусной модели. Когда все задачи будут влиты в main-ветки, родительскую задачу можно будет закрыть.
Регламент движения задач
Представим движение задачи крупными мазками, как будет выглядеть и что будет происходить на каждом этапе:Бэклог дизайн-системы VK
Инициация
- В бэклоге создается задача на внесение изменений: добавление нового компонента, доработка, рефакторинг, подключение новой библиотеки т. д.
- Команда грумит бэклог и задача берется в работу.
- Дизайнер создает 2 dev-ветки: для внесение изменений в Фигму и в документацию.
- Разработчик создает ветку для внесения в соответствующий репозиторий.
Проектирование
- Ответственный по задаче дизайнер или разработчик готовит задачу к разработке, проводит анализ, пишет тех. задание, рисует.
- Дизайнер вносит все необходимые изменения в dev-ветку и готовит Pull Request.
- Если по задаче требуется разработка, то дизайнер готовит ее к разработке.
Разработка
- Разработчик разрабатывает задачу.
- Проходит код-ревью и дизайн-ревью.
- Документирует изменения в Storybook или другой витрине.
Релиз
- Разработчик получает от дизайнеры ожидаемую ссылку на гайдлайн и добавляет ее в Storybook.
- Дизайнер получает от разработчика ожидаемую ссылку на документацию в Storybook и добавляет ее в Фигму и документацию.
- Оба релизят задачу.
Теперь придумаем статусную модель. Помните, мы создаем единый бэклог для задач на дизайн и разработку, поэтому наш воркфлоу должен учитывать две роли: дизайнера и разработчика. Их процесс работы над задачами может немного отличаться.
Очередь
Список задач, которые прошли через груминг и рано или поздно уйдут на реализацию.
В этом статусе у задачи уже может быть установлен ответственный, он определится на планировании, поэтому, когда ответственный готов взять задачу в работу, он перетаскивает ее в статус Проектирование.
Некоторые задачи на разработку могут проскакивать этот статус и оказываться в статусе Готово к разработке, если задача понятна и не требует анализа.
Проектирование
Задача ответственного разобраться в задаче и подготовить ее к разработке:
- дизайнер: действует в соответствии с DoR.
- разработчик: если задача сложная и требует предварительного анализа, то разработчики выступают в роли проектировщиков, пишут понимание задачи, исследуют текущее решение, составляют техническое задание, согласовывают его со стейкхолдерами.
По готовности ответственный двигает задачу в статус Ревью.
Ревью
В этом статусе задача проходит ревью у других членов команды.
Можно прибегнуть к практике, которая называется 3 амиго. В нашем случае 3 амиго выступят: лид дизайна, лид разработки и арт-директор. Опционально можно менять участников, например, если задача не требует изменений в коде, то разработчика можно заменить на дизайнера или исследователя.
Они должны проверить задачу, убедиться в ее полноте, необходимости и готовности к дальнейшему движению. Каждый ревьюер проставляет свою визу в комментах к задаче.
Когда ревью пройдено, ответственный двигает задачу в статус Готово к разработке, если нужны изменения в коде, если не нужны, то — в статус Ожидает релиза.
Если инспекция не пройдена, то задача возвращается на доработку. Причины возврата описываются в комментариях к макету или задаче.
Готово к разработке
Колонка-накопитель, здесь задачи ждут, когда разработчики смогут взять их в работу. На ближайшем планировании задача на разработку получает исполнителя, оценку и переводится в статус Готово к разработке. По готовности, ответственный разработчик берет задачу в работу и двигает в статус Разработка.
Разработка
Здесь у задачи меняется ответственный, теперь разработчик ведет задачу вперед, а дизайнер снимает возникающие вопросы, вносит изменения в документацию и всячески помогает случиться релизу.
Разработчик решает задачу, проверяет на соответствие критериям DoD и по готовности переводит ее в статус Код-ревью. Дизайнер, зная о смене статуса по задаче, берет свою задачу на дизайн и тоже переводит ее в статус Код-ревью. Его задача пройти финальное ревью для пулл-реквестов в main-ветки документации и Фигмы.
Код-ревью
Это важный статус, говорящий и высокой степени готовности задачи. Такие задачи имеют высокий приоритет, поэтому ответственные за ревью коллеги оперативно подключаются к проверке:
- дизайнер-ревьюер: проверяет пулл-реквесты в документацию и Фигму. Апрувит их, но не мерджит. Переводит задачу в статус Ожидает релиза.
- разработчик-ревьюер: проверяет условия задачи, решение и соответствие критериям DoD. Если все хорошо, то вливает PR в релизную ветку и переводит задачу в статус Ожидает релиза. При наличии замечаний, комментирует PR и возвращает задачу на доработку.
Ожидает релиза
Задача ждёт, когда состоится релиз и CODEOWNERS вольют изменения в main-ветку. По договоренности команды происходит влитие релизных и dev-веток в main:
- ответственный за релиз разработчик вливает в main-ветку с кодом.
- ответственный за релиз дизайнер вливает в документацию и в Фигму.
Готово
Когда Pull Request вмердживаются в main-ветку, то Github автоматически закрывает задачи. Остается подготовить и написать Release Notes.
Теперь занесите статусы в статусную модель проекта:
Теперь откройте воркфлоу проекта и убедитесь, что правило Pull request merged включено и задача переходит в статус Готово:
Здорово! Теперь у вас есть настоящий ЦУП для управления задачами.