Scrum методология решает значительное количество типичных проблем разработки ПО, однако, во многих компаниях отмечают, что ускорение разработки связано не просто с применением какой-то организационной парадигмы, но и с тем, что в Scrum часто пренебрегают какими-либо аспектами софверной инженерии, и, в частности, параметрами долгосрочного качества программного продукта. Однако, такая «экономия» редко может найти себе оправдание в значительной части отраслей экономики, где долгосрочное качество ПО лежит в основе конкурентных возможностей компаний. Технологическое развитие программных продуктов, и, например, учет и списание технического долга положительно влияют на значительное число параметров долгосрочного качества ПО.  Актуальность проблемы технического долга в Scrum и других «гибких» парадигмах (SAF, SofS) в развитии производственных процессов разработки ПО не вызывает сомнений. Решение такой проблемы лежит сразу в нескольких аспектах, подтвержденных как практикой проектов, так и научными исследованиями в России и СНГ. Рассмотрим несколько уровней решения такой проблемы: Учет и ликвидация технического долга – это активность в каждом спринте, специально обсуждаемая в рамках планирования, проведения демо и ретроспективы. Формирование только «технологических спринтов» (в Scrum) или целых поездов (в SAF) – это не лучшая практика, а вынужденная мера; Задачи технологического развития и списания тех. долга формируют самостоятельные эпики в беклогах продуктов и обладают самостоятельными оценками (трудоёмкость, приоритет, риски и связи с другими задачами); Актуальный ре-факторинг проводится по расписанию, его связь с функциональным развитием системы менее важна, чем удобство управления капасити команд;  Лучшей практикой является выделение самостоятельных и долгосрочных показателей качества ПО, связанных с технологическим развитием и списанием тех. долга, чем попытки привязать «технологические таски и стори» к функциональным эпикам и их показателям качества \ успешности; Взаимодействие между бизнес-заказчиками и командой разработки в части тех. долга должно быть исчерпывающе понятным по целям и настолько продолжительным, пока «технологические таски и стори» не обретут в понимании заказчиков нужного места в приоритетах планирования. Предложенный выше список позволяет сформировать следующее представление о работе с техническим долгом (и шире – с технологическим развитием продукта) в Scrum-проектах: технологическое развитие является не менее важным, чем функциональное (для подавляющего числа отраслей экономики), затраты времени и денег на такое технологическое развитие требуют пристального внимания команды и являются обязательной частью проекта разработки ПО.   Итак, учет технического долга – это активность в каждом спринте, которая начинается еще на фазе его планирования. Типичным рекомендуемым подходом является формирование «технологических эпиков», стори из которых попадают в соответствии с выделенным капасити команд в спринты разработки. Общие рекомендации по формированию таких эпиков: Определять четкую цель и привязку к показателям качества продукта в эпиках; Поддерживать детерминированный баланс между составляющими стори в каждом эпике по направлениям: обновления и устранение уязвимостей в системных и прикладных средах, реализация нефункциональных требований, ре-факторинг актуального функционала, стабилизация качества системы (по показателям качества продукта), улучшение производственных процессов и т.д.; Как правило, в отдельные эпики выделяются самостоятельные процессные области, если проект требует существенного развития в этих направлениях (например, CI\CD или архитектурный ре-дизайн). В таких эпиках могут располагаться стори, реализующие только развитие данного направления (без баланса составляющих, указанного в п.2); Рассмотрим некоторые примеры из практики консультантов SSC, иллюстрирующие применение прогрессивных подходов в организации технологического развития софтверных продуктов.  Первый пример, это разработка российско-китайской IT-компанией защищенного мессенджера на основе открытого кода Сигнал М. Марлинспайка в 2018 году. Такой продукт объединял возможности шифрования каналов передачи данных для звонков и сообщений с возможностями проведения платежных транзакций в активно разрабатываемой крипто-валюте. Очевидно, что кроме масштабного функционального развития такой продукт потребовал управления массой технологических рисков, которые были определены и классифицированы консультантом SSC. Далее по таблице трассировки рисков были определены взаимосвязи и составлен набор технологических эпиков. Для каждого эпика был определен баланс по стори в следующем сочетании с капасити команды: Обновление версии Signal внутри разрабатываемого продукта – 20%; Поддержка обновления прочих библиотек и базовых операционных систем (SDK iOS, Android) – 20%; Ре-факторинг блокчейн-взаимодействий – 40%; Прочие истории – 20%. Технологические эпики с таким балансом капасити по стори поддерживали управление рисками и реальное списание тех. долга в течение всей активной фазы разработки продукта – почти 16 месяцев. Другой пример из практики консалтинга SSC – это разработка крупнейшего web-портала для владельцев домашних животных в 2017 году: в данном проекте было найдено экономическое обоснование выгоды создания отдельных технологических эпиков в SCRUM для компании-разработчика. В их наполнении наиболее полезными оказались стори, связанные с развитием производственных процессов в команде разработки. Последовательно в отдельных «технологических эпиках» были внедрены: Процессы и использование инструментов CI\CD; Формализация процессов тестирования и внедрения unit-тестов;  Формализация использования UML в разработке.   Определение трудоемкости, сроков и рисков, связанных с развитием технологических процессов производства ПО, в данном проекте позволили в минимальные сроки и без прекращения работы над продуктом значительно повысить ожидаемые параметры долгосрочного качества web-портала, а также увеличить скорость выпуска новых функционально значимых релизов. Другой пример эффективного списания тех. долга в спринте описывается из практики испанской софтверной компании SlavaSoft. На протяжении трех лет развития мобильного продукта для профессионалов футбола в парадигме разработки Scrum при списании тех. долга использовались формализованные «технологические эпики» и баланс стори внутри них:  Самостоятельные «технологические эпики» позволили: обновить процессы CI\CD, обеспечить следование технологическим гайдам Google, формализовать процессы тестирования на обновляемом парке устройств; Смешанные «технологические эпики» позволили с помощью небольших стори:  обеспечить для продукта постоянную совместимость с обновляемыми библиотеками и версиями мобильных операционных систем;  реализовать ограниченное соответствие UI\UX гайдам от Google; проводить постоянный ре-факторинг в части бизнес-логики продукта. Бизнес-заказчики данного мобильного продукта отмечали высокий уровень технологической зрелости продукта и быстрое совершенствование производственных процессов, что безусловно шло на пользу развитию продукта и бизнеса SlavaSoft.  Таким образом, управление технологическим развитием и, в частности, списание тех. долга в SCRUM-разработке – это формализованный процесс, ценность которого, к сожалению, пока очевидна не в одинаковой степени для каждого владельца продукта, архитектора и бизнес-заказчика.   Безусловно, повышение прозрачности данного процесса, в том числе на основе регулярного мониторинга специально выделенных параметров долгосрочного качества ПО, необходимо и экономически целесообразно.   Консалтинговая компания для IT-отрасли