Управление техническим долгом в Scrum-разработке

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

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

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

 Актуальность проблемы технического долга в Scrum и других «гибких» парадигмах (SAF, SofS) в развитии производственных процессов разработки ПО не вызывает сомнений. Решение такой проблемы лежит сразу в нескольких аспектах, подтвержденных как практикой проектов, так и научными исследованиями в России и СНГ. Рассмотрим несколько уровней решения такой проблемы:

  • Учет и ликвидация технического долга – это активность в каждом спринте, специально обсуждаемая в рамках планирования, проведения демо и ретроспективы. Формирование только «технологических спринтов» (в Scrum) или целых поездов (в SAF) – это не лучшая практика, а вынужденная мера;

  • Задачи технологического развития и списания тех. долга формируют самостоятельные эпики в беклогах продуктов и обладают самостоятельными оценками (трудоёмкость, приоритет, риски и связи с другими задачами);

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

  • Лучшей практикой является выделение самостоятельных и долгосрочных показателей качества ПО, связанных с технологическим развитием и списанием тех. долга, чем попытки привязать «технологические таски и стори» к функциональным эпикам и их показателям качества \ успешности;

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

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

Итак, учет технического долга – это активность в каждом спринте, которая начинается еще на фазе его планирования. Типичным рекомендуемым подходом является формирование «технологических эпиков», стори из которых попадают в соответствии с выделенным капасити команд в спринты разработки. Общие рекомендации по формированию таких эпиков:

  1. Определять четкую цель и привязку к показателям качества продукта в эпиках;

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

  3. Как правило, в отдельные эпики выделяются самостоятельные процессные области, если проект требует существенного развития в этих направлениях (например, CI\CD или архитектурный ре-дизайн). В таких эпиках могут располагаться стори, реализующие только развитие данного направления (без баланса составляющих, указанного в п.2);

Рассмотрим некоторые примеры из практики консультантов SSC, иллюстрирующие применение прогрессивных подходов в организации технологического развития софтверных продуктов.  Первый пример, это разработка российско-китайской IT-компанией защищенного мессенджера на основе открытого кода Сигнал М. Марлинспайка в 2018 году. Такой продукт объединял возможности шифрования каналов передачи данных для звонков и сообщений с возможностями проведения платежных транзакций в активно разрабатываемой крипто-валюте. Очевидно, что кроме масштабного функционального развития такой продукт потребовал управления массой технологических рисков, которые были определены и классифицированы консультантом SSC. Далее по таблице трассировки рисков были определены взаимосвязи и составлен набор технологических эпиков. Для каждого эпика был определен баланс по стори в следующем сочетании с капасити команды:

  • Обновление версии Signal внутри разрабатываемого продукта – 20%;

  • Поддержка обновления прочих библиотек и базовых операционных систем (SDK iOS, Android) – 20%;

  • Ре-факторинг блокчейн-взаимодействий – 40%;

  • Прочие истории – 20%.

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

Другой пример из практики консалтинга SSC – это разработка крупнейшего web-портала для владельцев домашних животных в 2017 году: в данном проекте было найдено экономическое обоснование выгоды создания отдельных технологических эпиков в SCRUM для компании-разработчика. В их наполнении наиболее полезными оказались стори, связанные с развитием производственных процессов в команде разработки. Последовательно в отдельных «технологических эпиках» были внедрены:

  1. Процессы и использование инструментов CI\CD;

  2. Формализация процессов тестирования и внедрения unit-тестов;

  3. Формализация использования UML в разработке. 

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

Другой пример эффективного списания тех. долга в спринте описывается из практики испанской софтверной компании SlavaSoft. На протяжении трех лет развития мобильного продукта для профессионалов футбола в парадигме разработки Scrum при списании тех. долга использовались формализованные «технологические эпики» и баланс стори внутри них:

  1. Самостоятельные «технологические эпики» позволили: обновить процессы CI\CD, обеспечить следование технологическим гайдам Google, формализовать процессы тестирования на обновляемом парке устройств;

  2. Смешанные «технологические эпики» позволили с помощью небольших стори:

  • обеспечить для продукта постоянную совместимость с обновляемыми библиотеками и версиями мобильных операционных систем;

  • реализовать ограниченное соответствие UI\UX гайдам от Google;

  • проводить постоянный ре-факторинг в части бизнес-логики продукта.

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

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Регулярно ли задачи по техдолгу попадают в Ваш спринт разработки?
100% От случая к случаю 1
0% Регулярно 0
0% Вообще об этом не думаем 0
Проголосовал 1 пользователь. Воздержавшихся нет.
Источник: https://habr.com/ru/post/688036/


Интересные статьи

Интересные статьи

Как у организации, создающей вручную несколько качественных сайтов в год, у нас быстро возникла необходимость извлечения максимальной выгоды из определенного набора базовых средств. Несмотря на то, чт...
Кто ответственен за качество?Ответственность за качество лежит на всей команде. Эти слова я говорю из раза в раз, когда хочу донести суть, что не только тестировщики несут ответственность за качество....
Доброго времени суток, друзья! В подавляющем большинстве случаев нам, как JavaScript-разработчикам, не нужно беспокоиться о работе с памятью. Движок это делает за нас. Тем не ме...
Ранее в одном из наших КП добавление задач обрабатывалось бизнес-процессами, сейчас задач стало столько, что бизнес-процессы стали неуместны, и понадобился инструмент для массовой заливки задач на КП.
Мы публикуем видео с прошедшего мероприятия. Приятного просмотра.