Всем привет! Меня зовут Антон Баранов, я тимлид разработки в компании "Синимекс", недавно я завершил работу над двумя микросервисными проектами в сфере финтех, а до этого был техлидом и разработчиком на проектах, связанных с БЭК-офисами и витринами данных. Сейчас я актуализирую свой чек-лист и хочу поделиться с вами размышлениями о том, почему старт проекта — это одновременно и самое захватывающее, и самое рискованное время для тимлида.

Чем старт проекта так интересен и сложен? Первые дни тимлида на новом месте битвы напоминают сборку пазла в полумраке: куча деталей, неясные границы, и каждая ошибка может стоить недель или месяцев переделок. Чтобы заложить основу успешной работы, чтобы ничего не пришлось делать в последний момент с горящими... глазами, лично мне проще всего действовать по заранее выверенным пунктам. Спасительным фонарём, который позволяет осветить и собрать все элементы, скомпоновать в голове и зафиксировать для команды, может послужить чек-лист.

А перед началом содержательной части мне хотелось бы сразу проговорить несколько моментов. Я прекрасно понимаю, что в данной статье я не открываю ничего нового, но практика показывает, что многие люди, несмотря на то что знают о каких-либо инструментах, не спешат применять их на практике, думаю, не будет лишним напомнить. Для ведения своих чек-листов я применяю Obsidian, но вы вольны вести их в чём душа пожелает, план, накиданный на листочке, лучше, чем отсутствие плана. И еще, здесь наверняка есть опытные товарищи, может, подскажете в комментариях какие-нибудь фишечки Обсидиана, которые вы используете (у меня всё просто до предела: пара тегов и ссылки на важные ресурсы по проекту)?

Wiki: библиотека вместо бардака

И начать мне хотелось бы с той вещи, которая на первый взгляд не так важна, но которую проще всего сделать, немного снять своё напряжение и получить приятный выброс дофамина: одной из первых работ, за которую я бы взялся, было бы создание структуры в используемой системе документации. Пусть это пока будут пустые страницы, которые я позже буду наполнять информацией, но в то время, когда мне понадобится это сделать (а иногда это может быть срочно), мне не придётся тратить время на это. Плюс, команда уже не на словах, а на деле будет видеть, чем я собираюсь заниматься, что позволит быстрее получить обратную связь с замечаниями и уточнениями. И кто знает, вдруг среди команды найдётся волшебный человек, спаситель, гигант мысли, которому можно часть работы делегировать?

Почему разработчикам важно писать эти буковки, да еще и на русском языке (фу)? Документацию можно назвать ДНК проекта. Без неё каждый новый человек может тратить дни на «раскачку» или отнимать драгоценное время своих коллег, чтобы ему объяснили, как всё настроить, получить доступы и прочее. Тестировщики и аналитики могут забывать о договорённостях по заведению задач и необходимой информации для описания типичных багов. Разработчики могут долго спорить при ревью кода о суперважных вещах вроде того, каким способом создать маппер. Вы уйдёте в отпуск, а команда сложит лапки и скажет, что не знает как выпустить хотфикс. И прочая, прочая, прочая.

Что бы я фиксировал на проекте со стороны разработки:

• Стенды проекта

• Стенды Заказчика + доступы

• Работа с репозиториями (казалось бы, все разработчики умеют с ними работать, но по факту каждый из нас любит придумывать что-то своё и проект из 100+ микросервисов может превратиться в кашу)

• Работа с кодом

• Процессы

• Интеграции

• Работа с Kubernetes/OpenShift/...

Встреча с РП: А что мы вообще делаем?

Предыдущий пункт можно назвать пунктом под номером ноль, занимает он не так много времени, даёт возможность немного успокоиться и настроиться, после чего можно уже приступить к работе. Итак, заделавшись лидом, что бы я сделал первым делом... первым делом... а что первым делом? А! Созвон! А что это за жизнь без пианины созвона?! И пойдём мы сначала на поклон к руководителю проекта и узнаем в деталях, что за продукт нам нужно сделать, какие у нас общие сроки, сроки на выкатку минимальной работоспособной версии и что в неё должно входить, определяемся, кто является стейкхолдерами проекта, берем их контакты, чтобы в случае чего знать, к кому обратиться. Неплохо было бы обсудить размер и состав будущей команды, если она еще не сформирована, особенности отношений с заказчиком (вдруг, по ту сторону от нас требуется на каждый чих письмо с копией руководителям трёх отделов и техническому директору?) А как мы будем поставлять код к заказчику и формировать поставки, кто ответственный, с какой частотой, что пишем в Release notes (может быть, достаточно просто сделать выгрузку из Jira)?
Также неплохо узнать, какую методологию на проекте мы используем: будет ли это кондовый waterfall, где всё-превсё заранее проанализировано, задокументировано, согласовано и составлены методики приёмо-сдаточных испытаний, или, наоборот, мы модные-молодёжные и у нас всё очень гибко, а в случае чего просто перепишем половину (как будто при водопадной технологии не переписывали)?

Желательно определиться, в каком составе и формате будут происходить командные встречи по проекту, насколько частыми предполагаются общие ретро-встречи. А еще важно понять, что от тебя как лида команды ожидается, может быть, требуется в обязательном порядке собирать какие-либо метрики по разработке, может быть ты обязан присутствовать на всех встречах с заказчиком или каких-то конкретных?

Архитектура: а как это должно выглядеть?

Когда мы определились с тем, чем вообще мы планируем заниматься, можно уже понять, как конкретно мы будем разрабатывать систему. Для этого важно собрать максимально большое количество архитектурной информации. Перво‑наперво знакомимся с архитектором, если таковой на проекте окажется, если нет, то выбиваем информацию из РП и аналитики. Предположим для простоты, что мы делаем технически сложный проект и архитектор всё таки присутствует. Нам необходимо узнать технологический стек, на котором мы собираемся разрабатывать. Каким образом к нам в систему будут поступать данные: через очереди сообщений, через REST‑запросы, SOAP, а может быть, лихие операторы собираются грузить CSV‑файлы? Что у нас на выходе системы: очередной брокер, личный кабинет пользователя или какие‑нибудь красивые графики для оператора? Как будут общаться сервисы друг с другом: Kafka, а может быть асинхронный WebFlux или мы вообще настолько в себе уверены, что хотим GRPC+Protobuf? На этом этапе можно обнаружить много интересных вещей, например, почему не хотим использовать Redis? Ах, нам требуется обязательное георезервирование с разнесением ЦОДов, а у заказчика есть список типовых решений и кластерный Redis там отсутствует?! А какие у заказчика дополнительные требования к нашей системе, может, мы должны с чем‑то обязательно интегрироваться, например, каждый сервис должен предоставлять метрики для Prometheus или нам обязательно внедрять к себе библиотеки трассировки запросов, чтобы вся информация о вызовах уходила в отдельные служебные сервисы, разработанные со стороны заказчика? Тут, кстати, я сразу заполняю для себя табличку в формате

Далее нам необходимо узнать, какая архитектурная документация есть на проекте и изучить её хотя бы вполглаза. Сюда может входить, например, компонентная модель C4, схема развёртывания и проч. Также нужно выяснить нефункциональные требования, чтобы не оказалось, что мы должны держать RPS в 1000 сообщений в секунду, а держим одно сообщение в час, или время REST-отклика у нас должно быть на уровне одной секунды, а мы на другом проекте для решения подобной задачи использовали такие сложные алгоритмы, что менее двух секунд на отклик никак не получается. Сюда же относятся требования безопасности, надёжности, масштабируемости и прочие умные слова.

Команда: оркестр без какофонии

Теперь, когда мы уже знаем, что и как мы планируем делать, можно приступить и к самой главной части нашей деятельности — работе с командой (можно, конечно, было приступить к этому и раньше, но очень не хочется на дейлике начинать речь словами «Здравствуйте, я Антон и я алко ничего не знаю»). Хорошую команду можно сравнить с оркестром, где каждый знает свою партию, более того, как правило, эта партия лежит у оркестрантов перед глазами на пюпитре. Даже лучшие разработчики без настройки процессов превращаются в просто «группу музыкантов», где каждый играет свою мелодию.

Сначала, конечно, необходимо познакомиться. У меня это обычно отдельная от большой проектной команды встреча, где я сначала представляюсь, рассказываю о себе, уточняю, работали ли до этого вместе члены команды (если, конечно, ранее я с ними не взаимодействовал), в каком формате велась работа на предыдущем проекте, пытаюсь понять ожидания от лида в команде, интересуюсь фишечками предыдущих тимлидов. Далее взаимодействие можно разделить на лирическое и физическое.

Лирика

Под ней я подразумеваю процессы. Нам необходимо согласовать дейлики (будут ли вообще, в какое время, в каком формате), проговорить временные ограничения на них, чтобы снизить частоту случаев, когда увлекаемся обсуждением какой-то проблемы, а остальным членам команды приходится молча сидеть по 15-20 минут. Также в прошлом году я открыл для себя нытинги — мини-встречи по запросу, на которых можно выпустить пар, пожаловаться на что-то, обсудить проблему и попытаться найти конструктивный выход из неё. Еще можно обсудить мини-ретро, отдельные от ретро целой проектной команды, вполне возможно, что они будут полезны, на них можно более безопасно что-то обсудить, погрузиться в разработнические детали, не вынося их на общее обозрение. Еще немаловажны встречи один на один с членами команды, на которых мы можем создать безопасное пространство, дать друг другу обратную связь, вовремя узнать о назревающих конфликтах, помочь с составлением и прохождением индивидуального плана развития, да и просто немного поболтать, снять напряжение и переключиться от основной работы.

Физика

И тут мы как разработчики вступаем в свою любимую область — работу с кодом. Повторюсь, очень важно фиксировать договорённости на бумаге, чтобы каждый из членов команды мог освежить забытое и в случае чего — апеллировать к документу. Сначала я бы зафиксировал договорённости по технологическому стеку, которые уже не зафиксированы в архитектуре: язык с версией и используемые фреймворки, какую систему сборки мы используем, как работаем со скриптами БД (Flyway? Liquibase? etc?), как в целом пишем код с примерами и прочее. Можно, кстати, задублировать к себе раздел по коду из первого чек-листа, когда мы только лишь создали заготовку страниц, и понемногу делегировать написание разделов разработчикам. Обязательно проговариваем и фиксируем политику бранчевания, версионирования и выпуска релизов, с контактами заинтересованных лиц и примерами релизных писем, чтобы вся команда в случае отсутствия вас на проекте могла справиться с поставкой кода к заказчику. Также стоит проговорить и зафиксировать политику код-ревью, на днях, кстати, попалась хорошая статья, которая очень похожа на то, как представляю себе процесс код-ревью я: Коротко о том, как внедрить код-ревью, которое работает (а не бюрократию) / Хабр В дополнение к ней хотелось бы отметить, что на предыдущем проекте мы внедрили у себя периодический код-ревью сервисов целиком, с целью того, чтобы разработчик пробежал по сервису, открытому у себя в студии, и проглядел весь код вкупе, так как зачастую в Merge Request, открытом в GitLab, всё выглядит логично, а на деле оказывается, что сделано немного не так, как в остальных сервисах.

Развёртывание: еще немного физики

Итак, мы уже освоились на проекте, познакомились с командой, понемногу начали писать код, и теперь стоит подумать собственно о том, где же мы будем его запускать. Очень хорошо, если лиду команды разработки не приходится об этом думать: даёшь специально обученному человеку — девопсу — ссылку на репозиторий с кодом, и этот код волшебным образом начинает запускаться и работать. Но даже в этом случае от нас требуется ряд действий, чтобы процесс запустился как можно быстрее и с минимальным количеством ошибок. Зачастую девопсы на проектах не бывают привязаны цепями и ведут их несколько в одно и то же время. Неплохо было бы упростить им жизнь и дать четкие инструкции о том, что, как и в каком виде должно быть развёрнуто по инфраструктуре. Что от нас требуется? В первую очередь, нужно дать человеку ссылку на архитектурную схему, которую мы пару этапов назад выбили из архитектора (ну, или попинать архитектора, чтобы он её отрисовал). Далее нужно определиться с общими принципами развёртывания, если этого без нас это не продумали, например, используем ли мы Helm или нам достаточно единичных Deployment, как храним конфигурацию OpenShift/Kubernetes и проч. Также важно определиться, что от нас требуется девопсу для настройки: как описываем параметры сервисов, достаточно ли комментариев в application.yml или нужна полноценная документация с названием каждой переменной окружения?

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

Jira: железнодорожные пути вместо тропинок

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

Обычно Workflow Jira (или любой другой системы управления жизненным циклом, будь то Devprom ALM, Kaiten, EvaTeam и проч.) находятся в зоне ответственности руководителя проекта. Но так как работать с ней, в основном, предстоит команде, стоит обратить пристальное внимание на структуру задач и процесс работы с ними, чтобы не оказалось внезапно, что у таска пятнадцать статусов и схема Workflow напоминает карту московского метро, только потому что кому-то раньше это показалось необходимым. Неплохо, когда в компании есть несколько стандартизированных Workflow, соответствующих разным типам проекта и методологиям управления, но на практике в разных компаниях и на разных проектах я видел многое...

И вот, чтобы упростить себе жизнь, на как можно более раннем этапе собираем лидов и РП в кучу и сидим, обсуждаем. При этом неплохо визуализировать процесс и поиграть в передачу задач друг другу и заказчику. Что обсуждаем?

Типы и связи задач
В Jira можно использовать стандартную связку Epic / User story / Subtask + Bug, при этом хорошо строится статистика, задачи на досках отображаются вложенными друг в друга. Если такое не устраивает, можно использовать связь Epic / Requirement / Feature / Tasks с разбивкой задач по типам (архитектура, аналитика, разработка, тестирование, развёртывание). Можно использовать простые связи между задачами (connected with), можно именованные (is part of, prevent implements, etc) или вообще не использовать их. Можно дополнительно кастомизировать задачи, важно лишь как на можно более раннем этапе смоделировать, понять плюсы и минусы, реализовать и зафиксировать в Wiki структуру, чтобы дальше можно было спокойно работать.

Wokflow
Чтобы собственно с задачами можно было работать, необходимо продумать статусную модель. Тут опять же можно руководствоваться принципами минимализма и делать статусы типа Open \ In progress \ Done \ Released, а можно усложнять и делать промежуточные статусы вроде Open \ Analyzing \ Ready for develop \ Development \ Development review \Ready for Testing Testing \Testing Done \ Released и проч. Тут все сильно зависит от выбранной структуры задач и пожеланий команды. Самое главное — чтобы процесс был прозрачен для всех и глядя на схему Workflow ни у кого не возникало лишних вопросов (а еще важно не поубивать друг друга в процессе обсуждения). Немаловажным фактором являются переходы между задачами. Хотим ли мы, чтобы с каждого этапа можно было вернуть задачу на предыдущий или на "контрольные точки", а может нам достаточно добавить в конечном статусе переход на начальный или вообще сделать модель с линейными переходами по типу "ошибся - умер"? На мой взгляд, истина где-то посередине. Важно проиграть с командой варианты прохождения задач, попробовать подвигать карточки визуально.

Процесс релиза
Точно также можно моделировать и процессы поставки кода на продуктовые стенды. Продумать необходимо, как мы выпускаем релиз, на каких стендах он будет разворачиваться, как выпускаем фиксы, как ведем учёт всего этого в Jira.

Компоненты
Так как в последнее время я работаю с микросервисными проектами, важным фактором является отслеживание связей задач с микросервисами. Для каждого микросервиса и библиотеки мы заводим компоненты Jira, чтобы, не открывая код и не смотря в историю коммитов, можно было увидеть, по каким задачам были внесены изменения. Также я указываю в описании компонентов репозиторий микросервиса, что позволяет разработчику при получении задачи найти новый для него репозиторий, не обращаясь к Wiki и коллегам (ну, и мне при заведении задачи не прописывать репозитории отдельной строкой).

Взаимодействие: дипломатия вместо сражения

Сколько раз у вас на проектах было такое, что в прилетевшей задаче, а еще лучше — письме от поддержки, было описание проблемы а-ля "Не создалось заявление" (и всё, точка)? А заявление может создаваться в автоматическом режиме, по кнопке из формы с просмотром персональных данных, по кнопке из общего реестра физических лиц — и открывай колоду Таро, производи расклад, пытайся понять, что случилось, трать время на уточняющую переписку. Или наоборот, разработчик завершил задачу, передал в тест, тестировщик начинает смотреть, а поведение системы не изменилось. Оказывается, после вливания Merge Request упал пайплайн на стадии развёртывания, никто это не проконтролировал, и снова несколько человек тратят время на разбор ситуации. В этом случае неплохо продумать Definition of Done и Definition of Ready и опять же, всё зафиксировать, чтобы пореже просить умную колонку Алису включать музыку для драки разработчика и аналитика/тестировщика.

Что нам для начала работы нужно от аналитики? В первую очередь, определиться с Definition of Ready для постановок. Далее, если у нас планируется много сервисов, то согласовать правила их наименования, вдруг, у заказчика есть какие-то определённые форматы названий, которые мы не знаем. Также договариваемся и фиксируем в аналитике названия служебных компонентов, например, топиков Kafka или очередей Artemis (и вообще, я бы запретил их автосоздание, иначе проект плавно превращается в зоопарк, а нам потом еще нужно будет при поставке расписать их параметры). Отдельно я бы обговорил наименования настроек сервисов, возможно, в аналитике стоит завести отдельную страницу с группировкой по сервисам или страницу с их типовыми названиями, чтобы сразу было видно одинаковые настройки и не приходилось бы изобретать велосипед, иначе можем столкнуться, что параметры повторных обработок ошибок в одном сервисе будут выглядеть как:

application:
	external-source:
		retryes:
			count: 3
			repeat-period: 10s

а в другом:

application:
	retryes:
		external-source:
			quantity: 3
			backoff: 10s

А девопсы потом придут к нам с вопросом, почему один и тот же параметр в двух сервисах называется по-разному, и будут требовать переименовать для того, чтобы сделать общую ConfigMap.Также я бы заранее проговорил формат синхронизации разработки и аналитики, возможно нам на проекте стоит использовать груминги задач перед тем, как отдавать их в работу, как показывает практика, в этом случае разработке и тестированию становится яснее цель доработки, а в аналитике на раннем этапе можно отловить и исправить проблемы. Еще можно попробовать согласовать с аналитикой ведение протоколов встреч с разработкой при обсуждении технических деталей, чтобы минимизировать случаи, когда та или иная сторона не помнит договорённостей. Ну, и зафиксировать еще что-либо важное, что мы извлекли из обсуждения с архитектором, но есть варианты реализации, например, описание формата API.

С тестированием похожая ситуация. На мой взгляд стоит так же обговорить Definition of Ready багов, прилетающих как со стороны нашей команды, так и команды заказчика, а также Definition of Done, в которых прописать, что в задаче обязательно должно быть сделано и проконтролировано, чтобы можно было передать её в тестирование. Уточняем, планируется ли на проекте использование автоматизированного тестирования и какая помощь требуется с нашей стороны, плюс можно обсудить наборы данных для автотестов, возможно, что-то может пригодиться нам в разработке для написания интеграционных тестов. Отдельно стоит обговорить нагрузочное тестирование: проводится ли оно вообще, чьими силами: нашими или заказчика, на какие метрики мы обращаем внимание, что для нас является критичным, а что нет. Тут же уточняем, что нам нужно для разбора багов по результатам нагрузки, потому что на передний план уже выходят не входные данные сервисов, которые мы обговаривали ранее, но становятся критичными настройки RAM/CPU подов и их утилизация, количество партиций в топиках Kafka, да даже уровень логирования (не стоит включать DEBUG на Kafka при проведении НТ). Ну, и на всякий случай, я бы уточнил, нужна ли какая-нибудь помощь для автоматизации тестирования или настройки стенда, ведь чем раньше мы начнём НТ, тем быстрее сможем найти и порешать типовые проблемы, пока похожий код не разъехался по многим сервисам.

Заключение

Может быть, многие вещи из написанного выше покажутся кому-то излишней бюрократией, да и вообще тимлид разработки частью из этого заниматься не обязан. Но тут уже каждый волен решать сам за себя. Кому-то вообще не нужны чек-листы, и они замечательно держат в голове полный план работы. Ну, а для меня лично чек-листы в целом являются необходимостью, можно даже сказать, инструкцией по выживанию (может, просто старею). В целом, за пару недель можно неспеша, планомерно и с удовольствием выполнить все пункты, что-то раньше, что-то позже, а часть вообще может закрыться автоматически, так как это не наши прямые обязанности. И ждёт нас впереди светлое будущее, где счастье станет нашей повседневностью, и корабли, бороздящие безбрежные просторы Вселенной, устремятся к звёздам на крыльях человеческого гения.

PS: а скомпонованный файл можно скачать отсюда: https://disk.yandex.ru/d/PR39DLa0-sd6Lg