Записи с метками инженерные практики

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

В большом и сложном проекте с распределенной архитектурой, несмотря на постоянно выделенных архитекторов, очень много проблем с внесением изменений и последующим багфиксом. При этом, активно применяется предварительное проектирование, прототипирование, модульное тестирование (80% актуальное покрытие), ревью кода, рефакторинг кода, автоматизация функционального тестирования (60% актуальное покрытие) и другие полезные инженерные практики. Процессы – гибкие (SCRUM, Kanban), представители закачика в командах есть. Зарелизенных экземпляров продукта в разных версиях – много, требуется обратная совместимость. Текучесть команды – как у всех. Авторитарно принятые руководством обязательства – случаются, но редко. Людей в разработке и сопровождении работает много и ещё больше увеличивать штат руководство не хочет. Как ускорить релизы и уменьшить затраты на их сопровождение? Потому что динамика не радует, на горизонте виднеется ж.

Можно было бы влёт ответить: у вас неправильный agile неправильное использования инженерных практик неправильный процесс. Но, давайте разберемся. Если увидите очевидности для себя – не обессудьте.

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

Добавляет свою долю и политический подход по сохранению пресловутой обратной совместимости, который приводит к жесткости API, что автоматически при естественной текучке кадров порождает множество грязи вокруг самого API и в средствах его тестирования.

Самообманом касательно самоуправляемости команд вроде уже все переболели на волне SCRUM, но рецедивы доверия к команде также приводят к «самизнаетечему» [c]. Ответственность на product owner-а при этом фиг переложишь, тем более, что общая тенденция к взращиванию PO внутри команды имеет место быть.

Ну и главная причина – итеративность и инкрементальность разработки, которая наше все понятно почему (бабло побеждает добро . Очень хорошо про это рассказано тут: Technical Debt, Process and Culture (автор – тот самый Michael Feathers, который написал вместе с Дядей Бобом Working Effectively with Legacy Code) Именно она ускоряет энтропию. Инкрементальность и итеративность приводит к тому, что появляется больше компромиссов с уклоном в уже существующий код. Часть результатов итеративной разработки устраняется рефакторингом, который с точки зрения руководства и заказчика суть есть не производительная фаза, а некое кошерное только для разработчиков действо с невнятным денежным эквивалентом в непонятной переспективе. Поэтому – полностью компромиссы вам вычистить никто не даст.

Итак, причина деградации кода – совсем не в неправильности архитектурирования и применения инженерных практик. Деградацию кода невозможно предотвратить, её можно только снизить и отсрочить проблемы. Применяемый авторами вопроса набор практик правильный и нужный, я не берусь по абстрактному описанию что-то советовать добавить или убрать. Как обычно – помогает перестановка приоритетов, ибо всего и сразу добиться не получится. Что я бы посоветовал:

Перетряхнуть приоритеты практик. Многие инженерные практики внедряются «потому что нужно». Попробуйте озадачиться программой вывода проекта из текущего «планирования со снижением» без увеличения штата команды и без существенной подвижки обязательств. Например:

• Переоценить приоритет автоматизированных функциональных тестов – без полного покрытия модульными тестами вы проживете, без функциональных – нет. Перетряхните команду тестировщиков, оставьте на ручном тестировании самых талантливых в свободном поиске, остальных – смещайте в сторону автоматизированного тестирования, вплоть до того, что цепляйте тестировщика к разработчику и пусть они «взаимопроникают» в сознание друг-другу
• Переоценить приоритет ревью и рефакторинга дизайна над кодом. Дизайн тоже очень сильно подвержен деградации, но он – перивичен. Лучше пусть код местами будет останется грязным, но дизайн будет чистым.
• Переоценить подходы к ревью – в долгосрочной перспективе только командное ревью позволит снизить эррозию. Никаких гуру-лидов, завязывайте с погонами. Это всяко дешевле процесса стандартизации подходов в проектировании и разработке между командами и не требует капитальных затрат.
• Повысить приоритет рефакторинга как такового относительно новых фич. Планы работ без взвешенных результатов анализа необходимости рефатокринга – не принимать принципиально. Периодически – устраивать субботники по чистке дизайна и кода, даже если они идут вместо новых фич, а не вместе с ними. Гигиена по отношению к рефакторингу – это наше все.
• Ввести практику оценки технического долга при проектировании. Это даст обратное влияние на культуру работы с требованиями и согласования user story с заказчиком. Но, придется научиться продавать это заказчику и постоянно учитывать в своих активностях.
• Синхронизируйте понятие «готово» у маркетинга и у разработчиков – те самые компромиссы часто возникают из-за некорректно взятых на себя обязательств. Привлекайте разработчиков к проектированию обязательств. Сразу о возможном флуде и флейме – разделение по структурно-функциональному признаку и правило 3-х чтений здорово облегчают жизнь.
• Как бонус из всего вышеперечисленного -  бОльшая степень вовлечения команды и восстановление часто теряемой связи между требованиями и командой.

Все это не потребует капитальных затрат – просто перераспределение текущих усилий. Ну а дальше надо посмотреть. Остается вопрос – как это все увязать с политикой компании и «продать» заказчику, но в постановке вопроса недостаточно данных о заказчиках и модели отношений с ними. Потому и перечислял только те вещи, которые могут быть оформлены как «внутренняя кухня» и не требуют согласования.

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

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

Результат работы команды архитекторов/разработчиков/тестировщиков/… всяко лучше результатов Чака Норриса гуру-одиночки. Роль личности никто не отменял, но одна из причин деградации – утеря ценностей по дизайну и кодописанию в результате текучки и компромиссов (см. выше). Если у вас за какой-то этап работ отвечает один человек – это должно вас сильно напрячь. Банальную ошибку, выгорание, эффект автобуса ещё никто не отменял. Сразу отвечаю на вопрос о единоначалии и единой точке ответственности – попробуйте концепцию лидерства группы, а не начальничества над группой.

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

Иными словами – все те же доверяй, но проверяй, только сбоку. Такие дела.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!