Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
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-разработке – это формализованный процесс, ценность которого, к сожалению, пока очевидна не в одинаковой степени для каждого владельца продукта, архитектора и бизнес-заказчика. Безусловно, повышение прозрачности данного процесса, в том числе на основе регулярного мониторинга специально выделенных параметров долгосрочного качества ПО, необходимо и экономически целесообразно.
