Руководство по Scrum · Артефакты и практики
Технический долг в Scrum: как его выявлять и управлять им
Технический долг — это будущая цена сегодняшних компромиссов: написанного в спешке кода, отсутствующих тестов, устаревших инструментов. Как и финансовый долг, в небольшом объёме он может быть полезен, но без управления замедляет каждый спринт.
Главное
- Технический долг — это будущая цена сегодняшних компромиссов.
- Сделайте его видимым в бэклоге продукта.
- Предотвращайте новый долг с помощью строгих критериев готовности.
Откуда он берётся
- Давление сроков, ведущее к срезанию углов.
- Слабые критерии готовности.
- Отсутствие автоматизированных тестов.
- Устаревшие библиотеки и инфраструктура.
- Знания, сосредоточенные у одного человека.
- Требования, изменившиеся после того, как решение было спроектировано.
Признаки растущего долга
- Снижающаяся или нестабильная скорости.
- Больше дефектов доходит до пользователей.
- Простые изменения занимают больше времени.
- Разработчики неохотно берутся за определённые участки.
Управление долгом в Scrum
- Сделайте его видимым: добавляйте элементы долга в бэклог продукта с понятным описанием их цены.
- Усильте критерии готовности , чтобы не создавать новый долг.
- Резервируйте мощность в каждом спринте, например долю работы команды, на сокращение долга.
- Проводите рефакторинг постоянно в рамках обычной работы.
- Обсуждайте его на обзоре спринта , чтобы заинтересованные стороны понимали компромисс.
Как объяснить долг заинтересованным сторонам
Формулируйте долг на языке бизнеса: «Изменения в этой области занимают в три раза больше времени и вызывают большинство наших инцидентов в продуктивной среде. Вложив два спринта, мы ускорим всю будущую работу здесь».
Бесплатные шаблоны по этой теме
Частые вопросы
Кто решает, когда гасить технический долг?
Владелец продукта упорядочивает бэклог с учётом информации от разработчиков, которые объясняют цену долга.
Любой ли технический долг плох?
Нет. Осознанный краткосрочный долг ради быстрого обучения может быть разумным, если его отслеживают и погашают.
Что такое технический долг?
Будущая цена выбора быстрого или простого решения сейчас вместо лучшего. Проявляется в замедлении изменений, росте числа дефектов и более рискованных релизах.
Кто ввёл термин «технический долг»?
Уорд Каннингем ввёл метафору долга в 1992 году, чтобы объяснить бизнес-стейкхолдерам, зачем нужен рефакторинг.
Как измерить технический долг?
Единой меры нет. Команды ориентируются на такие признаки, как время на внесение простых изменений, частота дефектов, инструменты анализа кода и размер элементов долга в бэклоге продукта.
Нужно ли вносить технический долг в бэклог продукта?
Да. Если сделать долг видимым в виде элементов бэклога продукта, владелец продукта сможет соотнести его с новыми функциями.
Сколько времени Scrum-команде следует тратить на технический долг?
Жёсткого правила нет. Многие команды резервируют на него часть мощности каждого спринта и корректируют её в зависимости от того, насколько долг их замедляет.
Как критерии готовности предотвращают технический долг?
Строгие критерии готовности, включающие тесты, ревью кода и документацию, не позволяют компромиссным решениям становиться частью инкремента.
Как рефакторинг сокращает технический долг?
Рефакторинг улучшает внутреннюю структуру кода, не меняя его поведения. Регулярный рефакторинг не даёт техническому долгу накапливаться.
Технический долг — это проблема только разработки ПО?
Термин пришёл из разработки ПО, но похожий долг есть и в других областях: устаревшие процессы, недокументированные знания или временные решения в контенте и данных.
Как убедить заинтересованные стороны погасить технический долг?
Объясняйте его на языке бизнеса, например насколько медленнее вносятся изменения или сколько инцидентов он вызывает, и покажите ожидаемый выигрыш от его устранения на Обзор спринта.