Как избежать ловушки технического долга

//ПОДЛЕЖИТ ИСПОЛНЕНИЮ (шутка!). А теперь серьезно: вы непроизвольно издаете стон, когда видите это? Да, мы тоже.

Dan Radigan Dan Radigan
Просмотр тем

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

Технический долг в agile | Atlassian — тренер по agile

В начале каждого релиза есть этап, на котором создаются новые функции и (в идеале) выполняются задачи, которые остались невыполненными при последнем релизе (давайте посмотрим правде в глаза: это случается редко). Цикл переходит в стадию разработки альфа-версии, когда каждая функция создана и готова к тестированию. Разработка бета-версии начинается, когда исправлено достаточно багов, чтобы версию можно было продемонстрировать клиентам для получения отзывов. К сожалению, пока команда занята исправлением багов для получения бета-версии, появляются новые баги. Это как бороться с гидрой: исправь один баг, и сразу появятся два новых. Наконец, вы достигаете контрольной точки, когда у вас на руках окончательная версия без неисправленных багов. Чтобы в ней не было неисправленных багов, обычно некоторые известные проблемы устраняют, а остальные (большинство?) откладывают до следующего релиза.

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

Из этой ловушки должен быть какой-то выход.

Agile помогает погасить технический долг

Качество в итеративной разработке обеспечивается за счет agile, чтобы команда могла выпускать стабильно качественные версии одну за другой. Если функция не на высоте, она не поставляется. Сложно в это поверить? Что ж, здесь есть секрет: главное — правильно определить, или переопределить, критерии готовности.

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

Главная (основная) ветка базы кода должна быть готова к поставке всегда. Это приоритетная задача. Работа над новыми функциями берет начало в ветке задания, содержащей код функции, а также код автоматических тестов для нее. Когда работа над функцией завершена и автоматические тесты успешно пройдены, соответствующую ветку можно объединить с главной веткой. Поскольку к качеству предъявляются одинаковые (одинаково высокие) требования на каждой стадии процесса, технический долг удается держать под контролем.

Во многих организациях это станет революцией в плане подходов к работе. Agile смещает фокус внимания со сроков на высококачественное, проверяемое на практике программное обеспечение. Владелец продукта может направить усилия команды на выполнение в первую очередь наиболее полезной работы, сокращая объем задач на пути к выпуску версии, но не поступаясь качеством.

Потому что нельзя забывать: чем дольше баги остаются без внимания, тем тяжелее их исправить.

Берем долг команды под контроль

Если вы работаете с устаревшим кодом, скорее всего, вы также унаследовали и технический долг. Далее мы расскажем, как взять под контроль существующий долг и позволить команде сосредоточиться на более приятных вещах, например на разработке новых функций.

Дайте определение

Иногда разработчики и менеджеры по продукту по-разному трактуют понятие технического долга. Давайте, наконец, положим конец этим разногласиям.

Под определение технического долга попадают все технические упрощения, на которые пришлось пойти, чтобы выполнить поставку в срок

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

Подсказка

Во время планирования спринта включите погашение технического долга в число задач как обычную работу над функциями. Не прячьте его в отдельный бэклог или трекер задач.

Не отводите целые спринты и задания под тестирование

Не поддавайтесь соблазну поступиться с критериями «готовности» и добавить отдельное задание тестирования к исходной пользовательской истории. Такие задания слишком легко откладываются на потом, а технический долг от этого только растет. Если в рамках работы над исходной историей или исправлением не было проведено тестирование, значит, эта история или исправление не готово. Установите точные критерии готовности в своей программе, не забыв прописать в них необходимость в полном автоматическом тестировании, и строго придерживайтесь их. Ничто так не сводит на нет эффект от agile, как ручное тестирование и база кода, кишащая старыми багами.

Боритесь с багами с помощью автоматизации

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

С чего начать?

Изменить общие подходы команды (и заинтересованных лиц в команде) к управлению техническим долгом нелегко. Для удовлетворения потребностей бизнеса иногда приходится сокращать время разработки, чтобы быстрее вывести продукт на рынок. Принимая это во внимание, давайте кратко перечислим некоторые меры, которые позволят взять технический долг под контроль.

  • Объясните владельцу продукта, какие реальные последствия несет неконтролируемый рост технического долга. Проверьте правильность оценки сложности будущих пользовательских историй, для выполнения которых нужно погасить существующий технический долг.
  • Перейдите на использование модульной архитектуры и четко обозначьте свою позицию по отношению техническому долгу в новых компонентах или библиотеках в приложении. Когда команда и компания увидят в этих новых компонентах эффект от следования принципам agile, они, несомненно, захотят применить эти принципы и к другим участкам кода.
  • Пишите автоматические тесты! Автоматические тесты и непрерывная интеграция являются лучшей профилактикой багов. При обнаружении новой ошибки напишите новый тест, который выявлял бы ее, а затем устраните проблему. Если баг когда-нибудь появится снова, автоматический тест выявит его раньше, чем с ним столкнутся клиенты.

Помните: с техническим долгом приходится иметь дело всем командам разработчиков. Эта проблема хотя бы частично касается каждого, и главное — не дать техническому долгу выйти из-под контроля.

продолжение темы
Testing