​​Engineering Improvements Track

Мы перешли от конфликта бизнеса и разработки к взаимовыгодному сотрудничеству. Один-два часа в неделю каждый разработчик может посвятить развитию инженерных практик и процессов. Бизнес довольно легко соглашается на один-два часа в неделю. А мы построили такой процесс, который приносит профит даже при минимальных затратах времени.

Наш третий трек базируется на Scrum:

📌 Продукт — Инженерные практики и процессы;
📌 Бэклог продукта — Задачи, направленные на устранение техдолга и улучшение инженерных практик;
📌 Владелец продукта — Сообщество разработчиков, которые приоритезируют бэклог и решают, какие задачи самые важные;
📌 Проработка задач из бэклога (PBR) — Рабочая группа описывает задачу: в чем проблема, как часто возникает, какие риски несёт, если не решать, и какая ценность для бизнеса. Очень важно объяснить бизнесу ценность от этой работы. Чаще всего ценность в более быстром выпуске фич (T2M) и более стабильных системах (внутреннее качество);
📌 Планирование итерации — Один час на первой неделе;
📌 Три Команды разработки — каждую итерацию для трёх задач набираются рабочие группы из разных продуктовых команд;
📌 Фиксированная длина итераций — 8 недель, что эквивалентно 4 бизнесовых спринта из Delivery Track.

Итерации долгие, но мы тратим всего один-два часа в неделю.
При этом раз в 4 бизнесовых спринта прогнозируемо появляется три значимых улучшения инженерных практик и процессов. Обычно мы договариваемся о стандартах типа Best Practice, чтобы не плодить велосипеды. Реже — разрабатываем конкретные улучшения инфраструктуры и инструментов для разработчиков.

Примеры результатов работы по этому треку:
— Тесты в CI Pipeline;
— Повышение стабильности при использовании Kafka;
— Best Practice документирования архитектуры;
— Best Practice по Unit тестам;
— Best Practice по Интеграционным тестам;
— Best Practice по разработке и деплою миграций БД микросервисов;
— стандартизация code style;
— SQL-Linter для Oracle PL/SQL;
— автоматизация разворачивания новой БД для микросервиса;
— Проработали требования и план разработки системы бизнес-мониторинга;
и еще с десяток улучшений, которые сложно описать без погружения в контекст.

Мы собирали этот процесс несколько лет и продолжаем менять. Этот процесс не идеален, но видно что он приносит свои плоды. Сообщество разработчиков из разных команд вместе договариваются о стандартах и лучших практиках, разрабатывают и внедряют инструменты для разработки, ci/cd, мониторинга.
В этот процесс не очень хорошо вписываются конкретные прикладные задачи "накодить". Чтобы их тоже делать в рамках этого процесса, мы думаем, как этот процесс изменить. Возможно, нужна именно dev2dev команда, которая занималась бы конкретно инструментами для разработчиков. Но пока довольны тем что имеем.

А у вас есть непрерывный процесс улучшения инженерки? Пишите в комментах.