Понятные стратегии Agile для ведения разработки без технического долга

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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