Технический долг в Scrum: взгляд разработчика
Технический долг замедляет разработку и снижает гибкость. Узнайте, как Scrum-команды могут выявлять, управлять и предотвращать его, чтобы поддерживать качество продукта.
Технический долг, распространенная проблема в разработке программного обеспечения. Это похоже на ипотеку. Вы берете долг, чтобы получить что-то сейчас, но платите проценты позже. В программном обеспечении эти проценты, это дополнительная работа, необходимая для добавления новых функций или исправления ошибок из-за неоптимального дизайна или реализации. Scrum-команды, как и все команды разработки, сталкиваются с техническим долгом. То, как они с ним справляются, влияет на их способность поставлять ценность и поддерживать качество продукта.
Что такое технический долг
Технический долг не всегда плох. Иногда это осознанное решение. Например, создание быстрого прототипа для проверки рыночной идеи может повлечь за собой накопление долга. В других случаях он накапливается непреднамеренно. Это может произойти из-за сжатых сроков, недостатка навыков или просто развивающегося понимания предметной области. Scrum Guide 2020 года подчеркивает прозрачность и адаптацию. Технический долг, оставленный без внимания, подрывает и то, и другое.
Выявление технического долга
Scrum-команды выявляют технический долг в ходе повседневной работы и инспекции. Разработчики обычно первыми замечают его. Они видят код, который трудно изменить, тесты, которые неожиданно ломаются, или системы, которые отказывают под нагрузкой. Это симптомы лежащего в основе долга. Ежедневный Скрам (Daily Scrum), это место для поднятия этих вопросов, пусть даже кратко. Обзор Спринта (Sprint Review) также может выявить долг, когда заинтересованные стороны наблюдают медленную производительность или частые дефекты.
Признаки технического долга включают:
- Частые ошибки в определенных областях кода.
- Реализация новых функций занимает гораздо больше времени, чем ожидалось.
- Изменения в одной части системы вызывают сбои в несвязанных частях.
- Разработчики выражают недовольство определенными участками кода.
- Высокая сложность без явной бизнес-ценности.
Управление техническим долгом в Scrum
Управление техническим долгом требует целенаправленных действий. Это не то, что исчезает само по себе. Scrum-команда, особенно Разработчики, должна сделать его видимым и приоритизировать его устранение. Бэклог Продукта (Product Backlog), это единственный источник истины для всей работы. Элементы технического долга, когда они представляют собой работу, необходимую для улучшения продукта, принадлежат туда. Владелец Продукта (Product Owner) несет ответственность за максимизацию ценности продукта, получаемой в результате работы Scrum-команды, и это включает в себя учет стоимости технического долга.
Разработчики несут ответственность за создание «Готового» Инкремента (Increment) в каждом Спринте. Это включает соблюдение Определения Готовности (Definition of Done). Надежное Определение Готовности часто включает стандарты качества, которые помогают предотвратить новый технический долг. Для существующего долга Разработчики могут предлагать Элементы Бэклога Продукта. Эти элементы описывают рефакторинг, изменение архитектуры или другую работу, необходимую для устранения долга. Затем Владелец Продукта работает с Разработчиками, чтобы решить, когда и как решать эти вопросы, балансируя их с разработкой новых функций.
Приоритизация и устранение долга
Владелец Продукта определяет порядок Элементов Бэклога Продукта. Это означает, что технический долг конкурирует с новыми функциями за внимание. При приоритизации Владелец Продукта учитывает влияние долга. Если часть долга замедляет, делает рискованной или невозможной будущую разработку, ее устранение может быть более ценным, чем добавление небольшой новой функции. Например, если схема базы данных настолько устарела, что препятствует критически важному новому направлению продукта, ее исправление становится высоким приоритетом. И наоборот, небольшой долг, вызывающий незначительные неудобства, может подождать.
Выделенные Спринты или части Спринтов могут быть отведены для работы с долгом. Некоторые команды резервируют процент каждого Спринта для непрерывного рефакторинга. Такое «погашение» долга становится частью текущей работы, а не отдельным проектом. Цель состоит в том, чтобы поддерживать систему здоровой и адаптируемой. Здоровая система позволяет команде реагировать на изменения и постоянно поставлять ценность.
Предотвращение нового технического долга
Профилактика лучше лечения. Сильное Определение Готовности, это основной инструмент предотвращения. Оно устанавливает четкие ожидания к качеству. Проверки кода, автоматизированное тестирование и непрерывная интеграция также помогают. Разработчики совместно обеспечивают соответствие нового кода стандартам качества. Они также принимают обоснованные решения во время Планирования Спринта (Sprint Planning), учитывая долгосрочные последствия своих проектных решений. Скрам-Мастер (Scrum Master) может помочь, обучая команду практикам качества и обеспечивая прозрачность и понимание Определения Готовности.
Регулярное Уточнение Бэклога Продукта (Product Backlog Refinement) также играет роль. Обсуждая предстоящие элементы, Разработчики могут выявить потенциальные области, где может возникнуть долг, и заблаговременно предложить лучшие подходы. Команда, которая постоянно инвестирует в качество и устраняет долг по мере его возникновения, станет более гибкой, продуктивной и способной поставлять ценный продукт.