Как управляться с техническим долгом

Перевод статьи Алексея Пастухова «How to manage Technical Debt».

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

Я хочу поделиться тем, как я предпочитаю работать с техническим долгом и что мне это дает в результате.

Определение технического долга и связанные с ним проблемы

Википедия нам говорит, что:

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

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

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

Если вы не будете управлять вашим долгом, то получите целый список проблем:

демотивированная команда
отсутствие возможности контролировать риски проекта
рост энтропии ПО
каждый будет испытывать желание переписать весь проект с нуля.

Причины

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

В ходе разработки продолжают добавляться и изменяться требования.
Разработка началась раньше проектирования.
Давление бизнеса.
Недостаток знаний или отработанных процедур.
Изменение спецификаций в последнюю минуту.
Плохое техническое руководство.
Отсутствие сотрудничества.
Устаревшие технологии.
Плохие подходы к разработке.

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

Сделай это, потому что нам это действительно нужно.

И после этой фразы вы идете на какие-то компромиссы, увеличивая технический долг.

Технический долг и PoC

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

Более аккуратное решение

Я предлагаю использовать следующую структуру в качестве таблицы. Можете добавить и другие колонки, но убирать их не стоит.

Номер
Проблема
Причина
Решение
Как предотвратить?
Начато
Решено
Статус
Исполнитель

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

Проблема – Причина – Решение – Предотвращение

Название, которое вы поместите в столбец «Проблема», позволит вам находить и идентифицировать отдельные задачи. А поскольку у каждой проблемы есть причина, важно ее установить.

Заполняя столбец «Причина», ответьте на вопросы: «Почему/Как/Когда эта проблема проявилась?». Они помогут вам определить корень проблемы, понять, кто допустил ошибку и почему.

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

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

Начато – Решено

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

Также не забудьте записать, когда вы решили эту проблему. Тогда можно будет создавать такие графики:

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

Статус и исполнитель

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

Пример

Вот пример записей по одной из проблем.

Колонка	Значение
Номер	13
Проблема	Устаревший файл README
Причина	После создания лэндинга были изменения в структуре папки.
Решение	Обновление файла
Как предотвратить?	Обновлять файл README вместе с изменениями в структуре, в одном пул-реквесте.
Начато	21
Решено	25
Статус	Закончено
Исполнитель	Алексей Пастухов

Здесь хотелось бы отметить, что если вы можете исправить проблему вовремя, то это просто расстановка приоритетов.

Итоги

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

Я поделился тем, как сам справляюсь с техническим долгом. Если это делать правильно, можно достигнуть положительных результатов:

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

P.S.: Не забывайте о приоритетах! Можно добавить соответствующую колонку в таблицу.

[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]