Владимир ШершунДиректор по развитию и цифровизации ООО «Северная столица», член правления Санкт-Петербургского клуба ИТ-директоров (SPB CIO Club)
Нет, это не магия. Просто скрипт не пропустит ваш коммит без задачи, а утренний стендап напомнит, зачем вы вообще пишете этот код.
erid: 2W5zFHaAQQQ
ООО Доктор Веб Реклама
Когда команда работает слаженно, кажется, что все происходит само собой: задачи выполняются вовремя, багов мало, релизы выходят регулярно. Но за этим «само собой» — жесткая внутренняя дисциплина, правильные ритуалы и культура, которую нужно не только построить, но и поддерживать.
Я много лет собираю команды, выстраиваю процессы и автоматизирую все, что мешает людям сосредоточиться на главном — на результате. В этой статье расскажу, как мы делаем это в наших проектах: от ежедневных стендапов и живых соглашений до автоматических проверок кода и принципов чистого бэклога.
Содержание:
Рабочая модель для команды разработчиков
Я бывший разработчик и архитектор, и, наверное, поэтому всегда считал важным автоматизировать не только процессы компании, но и внутреннюю инженерную кухню. За годы попробовал многое: DevOps, фреймлоки, собственные скрипты. Но главное, что точно работает в любой команде — это осознанные договоренности. Не регламенты, не стоячие летучки, а живые соглашения, которые команда сама формирует и принимает.
Обычно стартовое соглашение формирую сам. Это такой скелет, с учетом гибридного формата, разницы часовых поясов, опыта участников. Потом мы вместе адаптируем его под реальность. Оно может меняться, и это нормально. Но в любой спорной ситуации мы возвращаемся к нему: как мы договорились? Это всегда работает, снимает напряжение, помогает не лезть в личности, а посмотреть на систему. А если соглашение устарело — обновим.
Такая модель может поначалу вызывать удивление, особенно у тех, кто пришел из команд с микроменеджментом. Но через пару недель люди втягиваются. Они сами предлагают правила и сами следят за их соблюдением. Именно потому, что это их правила.
Чтобы не ловить за руку и не напоминать вручную, мы автоматизируем весь процесс соблюдения этих правил. Например, у нас есть скрипт: когда разработчик отправляет код в хранилище, скрипт проверяет, есть ли связанная задача в системе, действительно ли она в статусе «в работе», и принадлежит ли она этому разработчику. Если что-то не сходится — коммит не проходит. Все просто.
Такая проверка не только дисциплинирует, но и дает нам автоматическое понимание, что происходит. Мы сразу видим, что по такой-то задаче в хранилище появилось изменение. Это видит аналитик, это видит продуктолог, это видит тестировщик. Не нужно устраивать перекличку по чатам — процесс сам сигналит, что пора реагировать. Да, раньше код в хранилище ложился тихо, как камень в воду. Сейчас все иначе.
Еще одно звено — nightly-тестирование через SonarCube. Он сам запускается ночью, проверяет весь код, который попал в хранилище, и на утро разработчик получает письмо: «У тебя тут функция без выхода» или «Нарушена структура модуля». Это, конечно, не всем приятно, особенно когда замечание делает не тимлид, а робот. Но работает. Главное — это дает нам статус задачи, качество и контроль без ручной возни.
DevOps по-умному
Зачем все это? Потому что релизы у нас автоматические. Мы стремились к тому, чтобы цепочка от коммита до продакшена работала как часы — без пинков, без ручного контроля, без перекладывания задач между ролями. И, кажется, у нас это получилось.
Когда разработчик отправляет код в хранилище, он уже прошел первый фильтр — скрипт убедился, что задача существует, активна и принадлежит ему. Затем подключается SonarQube: проверяет код на качество, синтаксис, нарушения структуры. Если все чисто, в ход идет Vanessa Automation.
Денис Окулов: Типовая 1С как 10 нужных книг. Но чтобы их выбрать, надо прочитать 10 тысяч Рост российского рынка микроэлектроники не решает проблему импортных компонентов Рейтинг российских EdTech-платформ для запуска образовательных проектов
Сначала мы запускаем «дымовые тесты». Vanessa Automation – симулирует действия пользователя. Если разработчик доработал что-то в справочнике или документе, Vanessa Automation как пользователь попробует его создать, записать, удалить. Без ошибок. Если в процессе что-то сломается, поступит сигнал тревоги. Если все в порядке, тест считается успешным, и система понимает: этот релиз можно отправлять дальше.
Следом — BDD-тесты. Если функционал сложнее, аналитик может подключиться и дополнить автотест своими кейсами. Мы это поощряем: чем полнее покрытие, тем легче сопровождать систему. Потому что следующий этап — документация. Пошаговый сценарий, собранный Ванессой и аналитиком, можно сразу превращать в инструкцию: текстовую или видео.
Но и это еще не все. Как только задача разработчика закрыта, в системе автоматически создается задача на тестирование, уже для аналитика. У него есть три дня. Это не «рекомендательный срок», а обязательство. Если автотесты прошли, задача закрыта, но ручного теста нет — ответственность лежит на нем. Никто не будет напоминать. Мы считаем, что если техтесты прошли, продукт технически готов. Дальше — дело команды.
Такой стек — это не ради моды. Это способ быть уверенными в результате, не тратя лишнего времени. Не бегать за релизами, не выяснять, кто что залил и зачем. Все видно, все логируется, все контролируется. И команда это ценит.
Начни с дейли — и ты уже изменил культуру
Agile — это не мода. Это практическая инженерная культура. Да, звучит просто: стендапы, планирование, ретро, PBR. Но если все это работает, то и команда работает иначе. Вовлеченнее, осознаннее, продуктивнее. Читайте также
Арктический интеллект. Зачем СМП свои модели ИИ Пока ИИ в проекте «Северный морской путь» остается на втором плане из-за жестких требований к надежности, его роль в логистике и управлении становится все более критичной. IT-World разбирался, какие модели искусственного интеллекта — от узкоспециализированных до гипотетических — могут работать в условиях Арктики и как они интегрируются в цифровую экосистему СМП. Почему BPM и имитационное моделирование становятся ключом к безопасному и эффективному освоению маршрута.
Когда ко мне приходят ИТ-директора с вопросом: «С чего начать?», я всегда отвечаю одинаково — начните с daily. Не надо сразу запускать весь Agile-парад. Просто соберитесь на 15 минут утром и задайте себе три вопроса: что делал вчера, что буду делать сегодня и что мешает. И уже через неделю команда начинает понимать, кто чем занят, где кто буксует, кто может помочь. Даже если люди не работают напрямую друг с другом — появляется ощущение общей среды, общего темпа.
Но дейли не работает в вакууме. За ним должно стоять понятное планирование. А чтобы планировать, нужен backlog. Причем не хаотичный, а очищенный, выверенный, с нормальными описаниями и понятной целью. Тут на помощь приходит Product Backlog Refinement — PBR. Это тоже ритуал: садимся вместе, перепроверяем, что за задачи у нас висят, уточняем формулировки, уточняем результат. Это особенно важно, когда работа идет в распределенной команде — с удаленкой, разными часовыми поясами и даже разными языками.
В планировании спринта у нас всегда две части. Сначала мы приходим к бизнесу: вот, говорим, задачи, которые мы готовы брать. Бизнес приоритизирует. И только после этого команда берет задачи в работу и оценивает, влезут ли они в спринт. Здесь не нужна математика, нужна честность: мы знаем, сколько можем. Не восемь задач из вежливости, а шесть — чтобы сделать хорошо.
Если команда кросс-функциональная — 1С, .NET, PHP, фронт — стендапы проходят отдельно. Иначе за 15 минут не уложиться. Но ретро и PBR должны быть вместе. Потому что цель у всех одна, и понимание общей картины — это топливо мотивации. Когда ты знаешь, что твой кусок — часть большого механизма, появляется желание сделать его не просто вовремя, а классно.
Ретроспектива еще один важный ритуал. Мы обсуждаем, что получилось, что не получилось, и что можно улучшить. Без поиска виноватых. Только рост. Это работает, и в техническом, и в командном плане.
Конечно, все это не запускается за один день. Сначала — дейли. Через месяц — планирование. Потом ретро. И вот так, шаг за шагом, появляется та самая инженерная культура, и со временем становится понятно: чтобы планирование спринта было по-настоящему эффективным, сам бэклог нужно регулярно чистить. Это и есть смысл PBR — Product Backlog Refinement. Мы садимся с бизнесом, просматриваем задачи и откровенно говорим: вот эта история устарела, эта — неприоритетна, а здесь вообще нет внятного результата. Мы ничего не выкидываем в тишине, а возвращаем такие задачи инициатору и просим пересмотреть. Иногда проект жив, но требует переосмысления. Иногда — пора отпустить.
У нас в бэклоге остаются только выверенные, жизнеспособные задачи. И это критически важно. Потому что, если ты как CPO (или продуктолог, неважно как называется роль) приводишь в команду ерунду — ты теряешь доверие. Команда должна быть уверена: если задача попала в спринт, значит, она полезна, реализуема и принесет результат.
Я стараюсь отсеивать галлюцинации на подступах. Когда кто-то в бизнесе рождает идею в духе «а давайте сделаем…», но сам не разобрался, не проверил гипотезу, не подумал о пользователе, то моя задача эту идею остановить. Объяснить, направить, трансформировать. Но не допустить, чтобы команда тратила ресурс на бессмысленное.
Вот это и есть инженерная культура. Она складывается из трех вещей: четких договоренностей, автоматизированных инструментов и живых ритуалов. Соглашения, скрипты, agile-процессы. Все вместе — это рабочий механизм. Он защищает людей, делает результат предсказуемым и поддерживает атмосферу, где хочется делать хорошо.
Журнал IT Manager