Как научиться не накапливать технический долг — отвечают эксперты

Чудесных рецептов и секретов здесь нет – нужно на регулярной основе выделять (выгрызать, если вы работаете в корпоративной среде) время и избавляться от технического долга.

Выглядеть это может как угодно, например, включаете задачи по устранению долга в бэклог наравне с бизнес-задачами, форма не принципиальна — главное, чтобы работало.

Помогут здесь в первую очередь:

• Авто-тесты, их обязательно нужно писать, иначе всё превратится в «переписали код как положено, но теперь продукт вдруг перестал работать как надо»;
• Логическое (и физическое) разбиение приложения на сервисы с чётко обозначенными границами ответственности. Таким образом, технический долг можно будет устранять в каждом сервисе (не затрагивая остальные).

Добавлю лишь, что иногда в качестве инструмента «принуждения» к выделению времени на устранение долга используется подход, при котором разработчики не заморачиваются с техническим долгом до тех пор, пока продукт становится полностью неподдерживаемым. После чего с большим количеством конфликтов принимается решение «переписать всё» и все заинтересованные стороны (заказчик, руководство и команда) убеждаются в необходимости выделения времени на устранение технического долга.

Способ достаточно конфликтный и жёсткий, если не сказать жестокий, поэтому я не рекомендую его использовать на практике.

На тему технического долга вскоре можно будет писать книги. По сути, это тема управления продуктом. Из названия ясно, что это что-то, оставленное на потом. В нашем случае это работа, программирование. Избежать этого достаточно сложно. Вот пример: сайт для заказчика. Обычно никто не жертвует front-end, так как это имидж компании. Экономят на back-end, безопасности. Оставляют на потом, когда будут деньги. Здесь важно грамотно выстроить процесс разработки, а это задача руководителя проекта или команды. Вот грубый цикл разработки: идея – макет – архитектура – прототип – alpha – beta – тестирование – релиз. Чем действительно можно пожертвовать, а чем нет?

С моей точки зрения, 3 решения:
1) Если долг не мешает процессу, то просто его опустить.
2) Перестать балансировать между качеством и скоростью, а выбрать один параметр.
3) Нанять человека: архитектора, планировщика. Чтобы он правильно оценил пункты, которые можно вынести на будущие версии. То есть он должен с ходу хотя бы приблизительно представлять, какая функциональность в какие даты и в какой версии должна (!) быть реализована.

Однако технический долг – это не те вещи, которые стоит обходить (у всех разное финансирование). Это работает и как дополнительный стимул.

td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;}Говоря о техническом долге, необходимо различать личное желание разработчика улучшить некоторые места в коде и реальную необходимость оптимизации или рефакторинга, чтобы избежать дальнейших проблем при расширении и изменении функциональности. Эта необходимость обычно возникает, если разработчик не успевает в срок сделать фичу и «лепит» что получится, лишь бы сейчас заработало и прошло тестирование.

Технический долг обычно возникает по одной из двух причин:
1. Недостаток опыта у разработчика. Решение простое – набирать этот опыт, заполнять пробелы в знаниях, пользоваться помощью более квалифицированных коллег.
2. Неверно выбранный способ реализации. Это опасная ошибка, которая говорит о неправильно построенном процессе. Если за написание кода всегда хвататься с горящими глазами, не обдумав всё от и до, не рассмотрев все кейсы и не задав все вопросы, то в скором времени блокнот с техническим долгом разрастётся так, что можно будет половину программы писать с нуля.

Поэтому, чтобы сократить накопление технического долга, нужно выработать в себе привычку вначале погрузиться в задачу, уточнить всё, что можно, изучить все тест-кейсы, определить для себя план на листочке, а только потом садиться за написание кода. Тогда процесс займёт меньше времени, количество багов сократится, и заранее будет выбран самый оптимальный способ реализации фичи. К тому же в процессе уточнений требования могут измениться, и вам не придётся тратить время на изменение кода и «впиливать» в него новые условия.

Ни одна лучшая практика не будет работать эффективно, пока не будет соблюден ряд условий:

Перестать называть плохой код техническим долгом

Часто техническим долгом называют разработку спустя рукава. Первый шаг — политика абсолютной нетерпимости к незапланированной порче кодовой базы.

Создавать технический долг осознанно

Технический долг — мощный инструмент, в умелых руках. Тщательно запланируйте его возврат: “просто порефакторим в следующем спринте” — не план, а оправдание.

Объяснить термин коллегам из нетехнических областей

Самый важный и, вероятно, самый сложный шаг — коммуникация. Без поддержки людей, принимающих решения, вас просто заставят набрать долгов и оставят разгребать последствия в одиночку.

Не бойтесь погрузить менее технически подкованных коллег в проблематику: ваши менеджеры оценят подробно рассчитанный ROI и анализ рисков, дайте коллегам почитать The Software Project Survival Guide Макконнелла и познакомьте с релевантными исследованиями, пригласите на несколько ретроспектив и планерок, покажите результаты работы ваших статических анализаторов, в конце концов.

Научитесь защищать свой код не только перед командой разработки, но и перед бизнесом — начните воевать в одну сторону, и контроль технического долга перестанет вызывать панику в обоих лагерях.

Последние десятилетия мы живём в парадигме, где time to market имеет первостепенное значение. Очень может статься, что к тому времени, когда ваша команда закончит работу над вашим шедевром, на рынке уже не останется устройств, где его можно будет запустить. А это означает, что технический долг – это норма наших дней. Нам, программистам, есть чему поучиться у финансистов. Давайте не будем называть это «долгом». Давайте назовём это… техническим кредитом. И будем управлять им подобно тому, как финансисты используют свои финансовые инструменты.

В продуктовой разработке скорость доставки изменений — одна из основных метрик. При этом описать будущую архитектуру проекта в начале работы зачастую невозможно. Поэтому накопление технического долга — процесс естественный и неизбежный, но при соблюдении некоторых правил вполне решаемый.

Во-первых, накопление долга нужно брать под контроль: заведите в вашем таск-трекере специальный раздел (доску, тег, тип задачи), чтобы задачи по техническому долгу можно было оценивать, планировать и приоритизировать точно так же, как любые другие. За ведение такого бэклога по техническому долгу обычно отвечает тимлид или техлид команды.

Во-вторых, о необходимости таких работ лучше заранее договариваться со всеми, в первую очередь с продакт-менеджерами и заказчиками. Часто это самый сложный момент, так как нужно их убедить потратить драгоценное время разработчиков не на новые продуктовые фичи, которые помогут обогнать конкурентов, а на непонятную на первый взгляд деятельность без очевидного результата. В моей практике лучшим аргументом был постоянно увеличивающийся срок реализации простых с виду задач — разработчики знали, сколько сложных мест в коде им придётся обойти, сколько новых костылей расставить, и закладывали эти параметры в общую оценку задачи. После нескольких таких планирований продакт-менеджеры сами предлагали команде взять задачи на рефакторинг.

В-третьих, работы по техническому долгу — это как уборка. Для обеспечения чистоты нужна регулярность. В зависимости от того, как устроен ваш процесс, вы можете брать по одной такой задаче в спринт или делать субботники раз в месяц, но затягивать с уборкой не стоит — ведь гораздо проще раз в неделю протереть пыль, чем раз в год целую неделю драить всю квартиру.

В-четвёртых, не забывайте про метрики в ваших приложениях, которые помогут выявить технические проблемы там, где их не видно при простом взгляде на код: измеряйте производительность запросов и рендеринга; профилируйте запутанные места, чтобы понять, действительно ли там есть проблемы; не пренебрегайте статическими анализаторами для выявления ошибок и избыточной сложности.

А главное, любите и уважайте ваш технический долг. Ведь если он не накапливается, значит ваш проект перестал развиваться.

Технический долг — это не баг или криво написанный код, а умышленное пренебрежение качеством кода, и иногда просто не избежать момента, когда нужно написать «быстро и чтоб это заработало прямо сейчас».

Первое, что можно посоветовать в этом вопросе, — никогда не замалчивайте технический долг. Если вам приходится умышленно писать «плохо», этого не надо стесняться и это обязательно нужно открыто обговаривать с другими участниками проекта.

Я для себя такие «плохие» участки программы разделяю на два типа: то, что будет запущено только один раз, и что-то вроде прототипа, что нужно быстро запустить и посмотреть, как это «полетит». Для первого всё просто: сразу после использования этот участок нужно почистить, притом незамедлительно. Если не решить эту проблему сразу, потом уже точно времени на это не будет и некачественный участок придётся поддерживать постоянно. Со вторым случаем чуть сложнее, ведь можно подумать: «Всё работает, зачем делать что-то ещё?» Тут уже вопрос вашей собственной дисциплины.

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

Технический долг – это бич любой программной разработки. Часто «хорошо бы сделать, но отложим на потом» со временем превращается в неразрешимый ком проблем.

Мы работает по Scrum. Состав бэклогов команды и спринта контролируют руководитель проектов и тимлид команды, длительность спринта составляет две недели. Все задачи разработки делятся на три типа:

• Продуктовые — это разработка решений бизнес-задач, как правило, эти задачи выполняются в рамках проектов;
• Поддержка — задачи-сопровождения существующих продуктов, внесение незначительных исправлений в логику работы;
• Архитектурные — это как раз и есть задачи технического долга. В их состав входят и задачи технического долга разработки функциональности бизнес-продуктов, и общий техдолг;

В каждом спринте для каждого из типов задач выделяется своя квота времени, которая учитывается при планировании:

• Продуктовые задачи — 70% времени длительности спринта.
• Поддержка — 20%.
• Архитектурные — 10%.

После завершения крупных проектов команда разработки совместно с руководителем проектов своего направления планирует и организует технический спринт, цель — устранить наиболее критичные задачи технического долга, которые появились в ходе выполнения проекта.

Но бывает необходимость решения сложных задач, которые по трудоёмкости далеко превышают рамки квот архитектурных задач в спринтах и длительность технических спринтов. В этом случае инициируется архитектурный проект. Лидером проекта становится один из технических лидеров разработки. Проект оценивается с точки зрения затрат и выгод для бизнеса и приоритизируется наряду с проектами по разработке бизнес-решений.

Последнее и немаловажное мероприятие — актуализация бэклога задач технического долга.

В нашей компании задачи технического долга ведутся в отдельном проекте JIRA и отображаются и в бэклогах команд разработки, и в бэклоге отдела разработки. Таким образом, за актуальностью задач техдолга следят и руководители проекта с тимлидами команд, и линейные руководители разработки. Это позволяет отслеживать и закрывать задачи, которые либо перестали быть актуальными, либо решены в рамках других задач.

Резюмируя всё вышесказанное, для успешной борьбы с техническим долгом используются следующие приёмы:

•  10% времени спринта тратится на задачи технического долга;
• по завершении крупного проекта следует технический спринт;
• в случае необходимости внедрения крупных технических изменений инициируется архитектурный проект;
• бэклог технического долга всегда находится в актуальном состоянии, за этим следят и команды разработки, и линейные руководители разработки.