Шаблон фреймворка для приоритизации технического долга

Кратко: критерии приоритизации

• Знание кода. Насколько вы знакомы с кодом?

• Серьёзность. Как это влияет на функциональность или производительность приложения?

• Зависимости и масштаб. Сколько компонентов зависят от этой части кода? Масштаб затронутой архитектуры приложения.

• Стоимость исправления. Сколько сторипоинтов потребуется для устранения проблемы технического долга?

Итоговая оценка = (Знание + Серьёзность + Зависимости) – 3 * Стоимость

Попробуйте шаблон с бесплатным аккаунтом Prioplan: [SignUp]

Читайте также 5 советов по приоритизации технического долга.

• Кратко: критерии приоритизации
• Что такое технический долг?
• Примеры технического долга
• Проблема технического долга
• Критерии приоритизации технического долга
  • Знание кода
  • Серьёзность
  • Зависимости и масштаб системы
  • Стоимость исправления
• Настройте описания критериев
• Неподходящие критерии для оценки технического долга
  • Не используйте: бизнес-ценность или пользовательский опыт
  • Не используйте: частота возникновения
  • Не используйте: возраст задачи
• Расчёт приоритета для задач технического долга
• Собирайте задачи в бэклог технического долга
  • Совет 1. Создайте отдельный раздел в таск-трекере
  • Совет 2. Используйте единый формат
  • Совет 3. Давайте чёткое описание
  • Совет 4: используйте частоту изменений кода для сбора случайно обнаруженного технического долга
  • Совет 5: автоматически сканируйте код на медлительность и уязвимости
• Заключение

Что такое технический долг?

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

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

Примеры технического долга

Типичные задачи технического долга:

1. Использование устаревших или неактуальных технологий: использование старых или неподдерживаемых технологий может привести к проблемам совместимости и уязвимостям безопасности.

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

3. Отсутствие документации: отсутствие документации кода, процессов и требований может затруднить понимание приложения будущими разработчиками, что приведёт к увеличению времени разработки и более высоким затратам.

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

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

Примеры того, что НЕ считается техническим долгом:

1. Преднамеренная отсрочка работы, которая не критична для проекта или может быть завершена позже.

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

3. Намеренный выбор реализации не самого оптимального решения, которое всё ещё приемлемо для целей проекта.

4. Решение использовать определённую технологию или инструмент, несмотря на его потенциальные ограничения, на основе компромиссов с другими факторами, такими как время, стоимость и бизнес-требования.

5. Выполнение рутинных задач по обслуживанию, которые существенно не улучшают приложение.

Проблема технического долга

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

• Функции требуют больше времени для разработки

• Больше багов

Это всегда компромисс между улучшением кода и добавлением новых функций.

Критерии приоритизации технического долга

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

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

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

Доска prioplan.app с критериями приоритизации технического долга

Знание кода

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

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

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

• 1: Автор. Я написал этот кусок кода — могу поддерживать и объяснить его.

• 2: Сопровождающий. Я работал с этим кодом — нет вопросов о том, как он работает.

• 3: Доступный. Я могу спросить коллегу и прочитать документацию об этом.

• 5: Задокументированный. Я не работал с ним. У нас есть некоторая документация об этом.

• 8: Понятный. Я не работал с ним, но разобрался, как он работает, без значительных усилий.

• 13: Сложный. Нужно значительное время, чтобы разобраться, как он работает. Я не работал с этим кодом, но могу найти того, кто работал, или найти документацию.

• 21: Никогда не слышал об этом. Никто в вашей команде не знает этот код, или они скоро уйдут.

Серьёзность

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

• 1: Нет воздействия вообще.

• 2: Косметическая: незначительное воздействие на некоторые локальные компоненты. Можно решить в будущем, когда появятся ресурсы и время.

• 3: Минорная: всё работает хорошо, но мы можем улучшить. Можно решить в будущем, когда появятся ресурсы и время.

• 5: Замедляющая: замедляет продуктивность, делает код менее поддерживаемым или препятствует добавлению новых функций. Можно решить позже, когда позволят ресурсы.

• 8: Блокер. Блокирует дальнейшие улучшения или обновления одного компонента приложения. Следует решить в ближайшее время, чтобы предотвратить возникновение серьёзных проблем.

• 13: Мажорная. Блокирует и почти ломает несколько компонентов приложения. Создаёт дополнительные риски или задержки для проекта.

• 21: Критическая. Делает приложение непригодным для использования или создаёт высокий риск, если оставить нерешённым.

Зависимости и масштаб системы

Сколько компонентов зависят от этой части кода? Масштаб затронутой архитектуры приложения:

• 1: Тривиальный. Можно игнорировать, так как может быть исправлен в любой момент.

• 2: Минорный локальный. Ограничен одним методом, классом или функцией. Может нарушать принципы SOLID — нет значительного влияния на общее качество приложения.

• 3: Умеренный локальный: влияет на несколько методов, классов или функций. Также может быть сложнее изменить без непредвиденных последствий.

• 5: Глобальный. Ограничен одним приложением или сервисом, но включает нарушения SOLID в подсистемах в более обширной системе, которые распространяются на, казалось бы, не связанные области. Также может включать несоответствие между уровнями абстракции, проблемы точек интеграции и жёсткую связанность. Этот долг не влияет на потребителей приложения или сервиса, но ощущается при изменении самого сервиса.

• 8: Мажорный глобальный. Более значительное и широкое воздействие на качество приложения. Может включать несколько подсистем и влиять на всё приложение или сервис. Также может быть сложнее изменить без непредвиденных последствий.

• 13: Системный. Распространяется на несколько приложений, инфраструктур или команд. Включает многочисленные сервисы, использующие общее хранилище данных, высокую связанность в разных ограниченных контекстах и резкое несоответствие между технической реализацией и бизнес-логикой. Системный долг неприемлем в долгосрочной перспективе и требует немедленного внимания.

• 21: Критический. Представляет значительный риск для общего качества приложения и может повлиять на стабильность и надёжность системы.

Стоимость исправления

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

• 1: Без усилий

• 2: Низкая стоимость: 10% длительности спринта.

• 3: Умеренная: 20% длительности спринта.

• 5: Значительная: половина спринта

• 8: Высокая: один спринт

• 13: Очень высокая: больше одного спринта, но меньше двух спринтов. Рекомендуется разделить на несколько задач.

• 21: Запретительно дорогая. Сейчас нет идей, как с этим справиться. Два спринта и больше.

Настройте описания критериев

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

Настройте описания критериев

Неподходящие критерии для оценки технического долга

Бизнес-ценность, частота возникновения, возраст и влияние на пользовательский опыт — ненадёжные критерии для оценки технического долга.

Не используйте: бизнес-ценность или пользовательский опыт

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

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

Не используйте: частота возникновения

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

Не используйте: возраст задачи

Это может показаться очевидной и прямолинейной идеей — рефакторить старые библиотеки раньше. Но зачем тратить на это время, если код работает хорошо и не замедляет работу и не создаёт уязвимости? Возраст не должен быть вашим критерием приоритизации.

Расчёт приоритета для задач технического долга

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

Настройка веса для критерия «Стоимость»

Финальная формула довольно проста:

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

В книге «Essential Scrum: A Practical Guide to the Most Popular Agile Process» автор Кен Рубен использует три категории для определения технического долга: случайно обнаруженный, известный и целевой технический долг.

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

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

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

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

Совет 1. Создайте отдельный раздел в таск-трекере

Важно иметь свойство для отделения задач технического долга от других задач, таких как баги или функции. Используйте специальный тег/лейбл, тип задачи или компонент. У вас всегда должна быть возможность просмотреть полный бэклог со всеми задачами и отфильтровать его по типу.

Совет 2. Используйте единый формат

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

Совет 3. Давайте чёткое описание

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

Совет 4: используйте частоту изменений кода для сбора случайно обнаруженного технического долга

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

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

• Высокая частота может указывать на частые обновления, улучшения, нестабильность или ошибки.

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

Настоятельно рекомендуем посмотреть доклад Адама Торнхилла об этой идее, «

».

Совет 5: автоматически сканируйте код на медлительность и уязвимости

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

1. Code Scene — один инструмент для визуализации, понимания и улучшения вашего ПО в отношении кода, знаний и людей, стоящих за ним. Вносите улучшения на основе автоматизированных, приоритизированных и действенных рекомендаций.

2. SonarQube: популярный инструмент, который может обнаруживать уязвимости безопасности, code smells и другие проблемы в вашем коде. Он поддерживает различные языки программирования и интегрируется с различными инструментами CI/CD.

3. OWASP ZAP: сканер безопасности веб-приложений с открытым исходным кодом, который может обнаруживать уязвимости, такие как SQL-инъекции, межсайтовый скриптинг и другие проблемы безопасности.

4. CodeClimate: облачная платформа, которая анализирует ваш код и предоставляет информацию о его качестве, поддерживаемости и безопасности. Она поддерживает различные языки программирования и интегрируется с GitHub, Bitbucket и другими инструментами.

5. Snyk: облачный инструмент, который сканирует ваш код и зависимости на уязвимости безопасности и предоставляет рекомендации по их устранению. Он поддерживает различные языки программирования и интегрируется с различными инструментами CI/CD.

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

7. Qodana. Оцените целостность кода, которым вы владеете, заказываете или покупаете. Обогатите ваши CI/CD пайплайны всеми умными функциями, которые вам нравятся в IDE от JetBrains.

Заключение

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

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

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

Читайте далее: 5 советов по приоритизации технического долга