2021-12-15 10:31:46
#процессы_в_команде #виталий_черков
Как мы провели Epic merge встречуВ постах с хештегом #процессы_в_команде мы будем делиться практиками, которые вводим в проекте.
Проект. «Личный кабинет сотрудника Пятёрочки».
Контекст. ЛК быстро растёт: увеличивается кодовая база, появляются новые подсистемы, усложняются задачи. Соответственно, растёт команда. Одних только фронтендеров у нас 6 человек. Всё это значит, что нам нужно серьёзно задуматься об уменьшении bus-фактора.
Специфика проекта такова, что на нём почти всё время идёт разработка каких-то крупных новых фич или разделов. Объёмы новых изменений физически не позволяют каждому члену команды тщательно проводить код-ревью всех задач. Это значит, что для каждого разработчика должен быть сформирован контекст адекватного размера, за которым он сможет следить и понимать, что в нём происходит.
Для этого мы продумываем варианты распределения процессов ревью. Об этом я напишу позже, но основная мысль в том, что каждый разработчик не проводит код-ревью всех мёрж-реквестов на проекте. Поэтому одни члены команды могут вообще не представлять, чем занимаются некоторые его коллеги. Для решения этой проблемы мы придумали несколько активностей, одну из которых назвали «Epic merge встречей».
Все крупные фичи разрабатываются в отдельных ветках-эпиках. Фичи декомпозируются на небольшие задачи, и каждая задача по мере выполнения подливается в эпик. Когда все основные работы завершены, эпик готовится к релизу и вливается в главную ветку. Мы предположили, что когда фича уже готова, но ещё не влита — это идеальное время, чтобы познакомить всю команду с проделанной работой. Отсюда и название встречи.
Встречу проводит лид фичи — человек, который внёс в Epic основные изменения.
Примерный сценарий встречиВводные данные: кратко рассказать о проблеме, которая решалась, объяснить, почему решили делать этот эпик
Демонстрация того, что сделано— показать, что поменялось для пользователя
— погрузить в бизнес-процессы эпика
— продемонстрировать ключевые нововведения
Код и проектирование— показать основные нововведения, ключевые изменения в коде
— рассказать, какие проблемы (любого характера) возникали во время работы, и как их решали
— если есть какие-то вопросы, обсудить
Обсуждение доработок— если реализовали не весь бизнес-процесс, показать, какие работы предстоит выполнить
— обсудить технический долг
— завести задачи на доработки и оценить их
В течение встречи мы записываем возникающие вопросы и проблемы, обсуждаем их, придумываем общие решения.
РезультатыПока мы провели только одну встречу по этому сценарию, но она сразу показала очень крутой результат.
— Текущей эпик — это целый новый раздел. Теперь мы понимаем, как он устроен и для чего нужен
— Во время встречи мы заметили ряд проблем на проекте, которые могли влиять на пользовательский опыт, но о них даже никто не подозревал. Наконец-то мы обратили на них внимание и запланировали доработки
— Поскольку встреча была проведена до вливания эпика, мы успели запланировать, оценить и выполнить ряд доработок, которые улучшили качество результата
— Почти вся команда собралась очно, что особенно здорово для новых участников команды!
Что будем делать дальшеУ нас уже есть планы на подобные встречи в ближайшее время, но мы решили пойти дальше. Первая встреча была в тестовом формате, поэтому мы провели её только в рамках команды нашего проекта. На следующие встречи мы будем приглашать всех сотрудников нашей компании. Это позволит всем познакомиться с тем, чем мы вообще занимаемся. Возможно, наши решения могут кому-то помочь. С другой стороны, остальные сотрудники компании смогут предложить свои решения или обратить внимание на возможные проблемы, которые мы не замечали. В общем, прокалываем информационный пузырь.
Что думаете вы?Проводятся ли в ваших проектах подобные встречи? Как считаете, какими преимуществами и недостатками они обладают? Какие проблемы эти встречи не решают, и как их решаете вы?
174 views07:31
П
