О спикере: Артём Кротов — разработчик с 15-летним опытом, из которых 10 лет он применяет гибкие подходы и инженерные практики. Сейчас он Scrum-мастер в команде Mir Platform и ярый приверженец системной инженерии как основы для устойчивых изменений в разработке.
Почему инженерные практики — важны для агентов изменений
Артём пришёл к инженерным практикам через личный вызов: при трудоустройстве ему не хватало базовых знаний по проектированию. Именно тогда он впервые прочитал «Чистый код» Роберта Мартина и осознал, насколько сильно влияет качество инженерной работы на финальный результат. С тех пор его путь включал изучение XP (экстремального программирования), скрама и других подходов, подчёркивающих важность практик в ежедневной работе.
Он подчёркивает: если команда не владеет инженерной базой, никакие процессы не спасут. Команда, ковыряющая что-то «на коленке», без тестов и контроля версий, далеко не уедет. Именно поэтому инженерные практики должны быть в фокусе всех изменений, особенно в разработке ПО.
Индивидуальные инженерные практики: с чего начать
Даже без команды можно внедрять:
- Clean Code — этика написания кода
- TDD (Test Driven Development) — сначала пишем тест, потом код
- Рефакторинг — системная переработка кода
- Модульное тестирование — изолированные проверки компонентов
Артём называет TDD краеугольной практикой, из которой вырастают все остальные. Пусть она и контринтуитивна (как потоковая работа: чем меньше задач — тем быстрее результат), но именно она помогает избегать багов и ускоряет итоговую поставку.
Как не сломаться под давлением менеджеров
Важно отделить внедрение новых подходов от стресса. Для этого Артём предлагает тренироваться на «кошечках» — простых упражнениях, например, кодинг-катах. Они создают мышечную память, снижают тревожность и повышают уверенность. Со временем это наращивает доверие со стороны менеджеров, которые видят результат — стабильные оценки, покрытие тестами, предсказуемость.
Парное и моб-программирование: практики командного взаимодействия
- Парное программирование: два разработчика работают над одной задачей, меняясь ролями (драйвер и навигатор).
- Моб-программирование: расширение практики до 3+ человек. Один пишет код, остальные подсказывают. Через 10–15 минут — смена ролей.
Это позволяет:
- Сохранять общий контекст
- Уменьшать затраты на синхронизацию
- Сокращать число багов и спорных моментов на PBR и тестировании
Проблема формального подхода
Если разработчики «делают вид», что используют практику (сидят в мобе, но листают телефоны) — её стоит остановить. Без ценностей, таких как уважение, сотрудничество, открытость — ничего не выйдет. Лучший путь — создавать безопасную среду, например, в формате митапов, где можно потренироваться без давления. А затем решать: идём ли в продакшн с этой практикой или нет.
Создание культуры через социальные механизмы
Техпрактики лучше всего приживаются там, где:
- Есть социальная инновационность — готовность пробовать новое
- Сильная социальная сплочённость — доверие и поддержка в команде
- Накоплен социальный капитал — уважение и результативность
Важна роль лидера, который показывает пример и поддерживает нужное поведение. В противном случае — любая практика утонет в старой культуре.
Непрерывная интеграция (CI): не сервер, а практика
Многие путают CI с инструментом (Jenkins, GitHub и т.д.). Но суть не в нём. CI — это практика:
- Интеграция изменений в общий код минимум раз в день
- Все тесты должны проходить, продукт остаётся в работоспособном состоянии (buildable state)
- Незавершённые фичи скрываются за feature toggle’ами
Исторический пример — $1 CI с резиновой уточкой и старым ПК: команда могла в любой момент показать рабочий инкремент продукта.
Когда лучше стабилизировать код? — Как можно чаще. Идеально — каждые 10–20 минут. Чем реже, тем выше риск конфликта изменений. Если что-то ломается, команда должна немедленно остановить поток и исправить проблему (stop the line).
Кто чинит сломанный билд? Ответ — вся команда. Не важно, кто последний коммитил. Экстремальное программирование предполагает коллективную ответственность (shared code ownership). Главное — исправить быстро, а обсудить, как этого избежать в будущем, можно на ретроспективе.
Как руководителю сделать так, чтобы разработчики действительно владели базой?
Часто бывает, что в командах менеджер раздает задачи разработчикам, исходя из того, кто быстрее и лучше справится с конкретным куском. Это нормально с точки зрения эффективности, но если цель другая, если важен общий прогресс продукта, а не просто «утилизация» каждого сотрудника, тогда подход нужно менять.
С чего начать, если хочется, чтобы любой разработчик понимал всю базу и мог работать с любым кодом?
1. Парное программирование и код-ревью — самые естественные шаги. Даже если команду не готовы к экстремальному mob-программированию, начать можно с простого: сделать обязательным ревью кода коллегой через pull-requests. Пусть хотя бы двое разработчиков вместе смотрят изменения и обсуждают их. Это уже создаст точки соприкосновения и обмена знаниями.
2. Совместные pull-requests и работа в парах — если команда готова, лучше перейти к более тесному взаимодействию: парное программирование или mob-программирование, когда команда вместе решает задачу. Да, это дискомфортно, вызывает вопросы, но именно так строится культура общего владения кодом.
3. Вовлекать разработчиков в декомпозицию требований. Часто бизнес-аналитики готовят спецификации без активного участия разработчиков, что приводит к потере смысла требований и неправильной их расстановке. Если разработчик с самого начала понимает, зачем нужна фича, он лучше её реализует.
Что такое инженерные практики и зачем они нужны?
Инженерка — это, в первую очередь, набор практик и инструментов из экстремального программирования (XP) и DevOps, таких как TDD (разработка через тестирование), парное программирование, code ownership, автоматизация сборки и тестирования, непрерывная интеграция и деплой.
Если у команды настроен CI, автоматические тесты, все пишут код в парах и регулярно релизят, то, казалось бы, зачем им ещё Agile, Scrum, SAFe? Ответ простой: никакие процессы и фреймворки не работают сами по себе без крепкой инженерки.
Команды с хорошей инженеркой работают быстрее, качественнее, с меньшими задержками. Особенно это заметно, когда несколько команд одновременно разрабатывают один продукт. Без инженерки быстро начинается хаос и конфликты в коде.
Агенты изменений — кто они на самом деле?
Многие считают, что агент изменений — это agile coach или scrum-мастер. Это правда, но я бы добавил: настоящий агент изменений — это человек, который не просто управляет процессами, а разбирается в инженерных практиках, может сесть с командой в паре, помочь написать код, внедрить тесты.
Такие XP-коучи очень редки, но именно они способны максимально эффективно прокачивать команду и улучшать продукт.
Почему для старших разработчиков (сеньоров) тоже полезен коучинг?
Даже у лучших спортсменов есть тренеры. Сеньор-разработчик, который достиг высокого уровня, может получить от коуча объективную обратную связь, узнать, что можно делать лучше, как повысить качество и скорость работы.
Не стоит думать, что коучинг — это только для новичков. Мастерство — это путь без конца, и для тех, кто хочет стать ремесленником высочайшего уровня, коучинг просто необходим.
Почему у нас до сих пор многие сеньоры не знают инженерки?
Рынок труда диктует условия: работодатели зачастую просто закрывают вакансии, принимая тех, кто умеет хотя бы писать код, а не тех, кто хорошо владеет инженерными практиками.
Из-за дефицита специалистов приходится брать «что есть». Поэтому многие сеньоры не прокачиваются дальше по инженерным навыкам — им и так платят. Пока вакансий больше, чем желающих, менять ситуацию не будет.
Что могло бы изменить ситуацию?
Если рынок сменит фазу — вакансий станет меньше, а соискателей больше, тогда будет настоящий конкурс на качество, и разработчикам придется развивать инженерные практики, показывать реальные навыки владения инструментами.
Уже сейчас некоторые компании практикуют живые тестовые задания на интервью — это лучший способ увидеть уровень инженера в деле.
Заключение
Путь к тому, чтобы вся команда владела кодом и практиковала инженерные подходы — долгий и не всегда комфортный. Но без него сложно рассчитывать на стабильное качество, скорость и развитие продукта.
Если вы руководитель, начните с простого: организуйте парное программирование и ревью, вовлекайте разработчиков в бизнес-требования, не забывайте про обучение и коучинг.
И помните: настоящий профессионал всегда учится — будь он джуниор или сеньор. Инженерка — это не только про инструменты, но и про культуру, привычки и мотивацию.