Команда идеально сжигает стори-поинты, но добавление новой кнопки ломает половину приложения. Менеджеры нанимают коучей, надеясь ускорить релизы, а разработчики тонут в конфликтах слияния кода. Фреймворк управления не умеет писать чистый код и проектировать базы данных.
Рентген для вашего легаси
Scrum Guide 2020 описывает эмпирическое управление процессом. Фреймворк дает жесткий таймбокс (Спринт), четкие роли и артефакты. Правила требуют поставлять готовый Инкремент каждый цикл. Scrum намеренно неполный. Он не содержит инструкций по микросервисам, рефакторингу или паттернам проектирования.
Жестко связанная архитектура (Architectural Coupling) блокирует автономию. Разработчики (Developers) физически не могут выполнить Definition of Done за пару недель, если малейшая правка требует пересборки всего монолита и затрагивает соседние команды. Scrum делает эту дисфункцию кристально прозрачной. Вы видите падающую скорость (Velocity), заваленные Цели Спринта (Sprint Goal) и растущий технический долг. Лечить архитектуру придется суровыми инженерными практиками, а не перестановкой стикеров на доске.
Пытаться внедрить Scrum на гнилой архитектуре — это как нанять команду механиков “Формулы-1” для обслуживания разбитой телеги. Вы можете менять колеса за 2 секунды и проводить идеальные планерки, но телега всё равно развалится на первом повороте, потому что она не спроектирована для таких скоростей
Таблица
| Симптом болезни | Реакция Scrum | Инженерное решение |
|---|---|---|
| Жесткая связанность кода | Инкремент не доезжает до релиза из-за блокеров | Разделение системы на Bounded Contexts |
| Ручное тестирование | Баги всплывают прямо на Sprint Review | Внедрение TDD и автотестов |
| Интеграционный ад | Код не сливается в конце спринта | Непрерывная интеграция (CI) |
| Накопление техдолга | Растут оценки в Story Points | Постоянный рефакторинг (правило бойскаута) |
Как починить систему
Свяжите архитектуру и Бэклог Продукта. Владелец Продукта (Product Owner) обязан оплачивать техническое здоровье системы. Оценивайте технический долг через стоимость задержки (Cost of Delay). Показывайте бизнесу, сколько денег сгорает из-за медленного релиза и падений на продакшене.
Защищайте качество через Definition of Done. Впишите туда обязательное покрытие автотестами и прохождение статического анализатора. Код, не прошедший фильтры, не становится Инкрементом и летит обратно в бэклог.
Применяйте закон Конвея. Монолит мешает работать быстро — меняйте структуру команд. Создавайте кросс-функциональные ячейки вокруг бизнес-доменов. Разрубайте зависимости на уровне общения людей, и архитектура кода последует за ними.
Внедряйте практики экстремального программирования (XP). Парное программирование и CI/CD решают проблемы качества на уровне строк кода. Запускайте автотесты при каждом коммите. Деплой обязан происходить по нажатию одной кнопки. Ручные проверки и многодневные слияния веток убивают любую гибкость.
Главная мысль
Scrum — это рентгеновский аппарат. Он подсвечивает сломанную архитектуру, но не накладывает гипс. Глупо ругать рентген за то, что кость не срослась. Инвестируйте в инженерную культуру и практики XP, иначе ваш идеальный процесс просто ускорит доставку багов пользователям.
Часто задаваемые вопросы (FAQ)
Разработчики. Scrum Guide не выделяет роль «Архитектора». Вся команда коллективно владеет кодом и несет ответственность за технические решения, обеспечивающие создание Инкремента.
Откройте метрики потока. Если Lead Time (время от идеи до релиза) растет, а Throughput (пропускная способность) падает при том же размере команды — архитектура стала токсичной. Система тратит больше времени на обслуживание самой себя, чем на создание ценности.
Да. Разработчики добавляют их в Бэклог Продукта, а Владелец Продукта приоритизирует их наравне с бизнес-фичами. Лучшая практика — совмещать рефакторинг с разработкой новой фичи в том же модуле.
Дробить монолит и настраивать пайплайны. Запускайте Spikes (исследовательские задачи) для поиска решений. Перестаньте брать огромные куски работы. Начните выносить микросервисы по одному.
Скрам-мастер не пишет код, он делает проблему видимой. Он фасилитирует диалог между Разработчиками и Владельцем Продукта, помогая бизнесу осознать финансовые риски плохой архитектуры и выделить время на рефакторинг.