Что такое разработка по методике Agile?

Гибкая разработка — это термин, используемый для описания итеративной разработки программного обеспечения. Итеративная разработка программного обеспечения сокращает жизненный цикл DevOps путем завершения работы в коротких интервалах, обычно называемых спринтами. Спринты обычно длиной до четырех недель. Гибкая разработка часто противопоставляется традиционной или каскадной разработке, которая планирует более крупные проекты заранее и завершает их в соответствии с планом.

Доставка кода производственного качества в каждом спринте требует, чтобы команда Agile-разработки принимала во внимание ускоренный темп. Все кодирование, тестирование и проверка качества должны выполняться каждый спринт. Если команда не настроена должным образом, результаты могут не оправдать ожидания. Хотя эти разочарования предлагают отличные возможности обучения, полезно узнать некоторые ключевые уроки, прежде чем приступить к работе.

В этой статье описаны некоторые ключевые факторы успеха для команд разработки Agile:

• Тщательное уточнение невыполненной работы
• Интеграция на ранних стадиях и часто
• Минимизация технического долга

Тщательное уточнение невыполненной работы

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

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

Задание владельца продукта заключается в том, чтобы гарантировать, что в каждом спринте инженерам предоставлены четко определенные пользовательские истории для работы. Истории пользователей в верхней части бэклога должны всегда быть готовы к началу работы команды. Это понятие называется уточнением невыполненной работы. Сохранение невыполненной работы для команды разработки Agile требует усилий и дисциплины. К счастью, это стоит того, чтобы инвестировать.

При уточнении невыполненной работы помните следующие ключевые аспекты.

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

2. История пользователя не уточнена, если команда не подтвердит это. Команда должна просмотреть историю пользователя и согласиться, что она готова к работе. Если команда не увидит историю пользователя до первого дня спринта, это может привести к возникновению проблем.

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

Интегрируйте рано и часто

Непрерывная интеграция и непрерывнаядоставка (CI/CD) настраивают свою команду для быстрого темпа разработки Agile. Как можно скорее автоматизировать конвейеры сборки, тестирования и развертывания. Настройте эту автоматизацию в качестве одной из первых задач, которые ваша команда решает при запуске нового проекта.

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

CI/CD также влияет на архитектуру программного обеспечения. Это гарантирует доставку программного обеспечения, которое можно создавать и развертывать. Когда команды реализуют сложную функцию развертывания, они сразу же знают, если сборка и развертывание завершаются сбоем. CI/CD заставляет команду устранять проблемы с развертыванием по мере их возникновения. Затем продукт всегда готов к отправке.

Есть несколько ключевых действий CI/CD, которые критически важны для эффективной Agile-разработки.

1. Модульное тестирование. Модульные тесты являются первой защитой от человеческой ошибки. Рассматривайте модульные тесты как часть кода. Проверьте, что тесты добавлены в код. Сделайте модульное тестирование частью каждой сборки. Неудачные модульные тесты означают неудачную сборку.

2. Автоматизация сборки. Система сборки должна автоматически извлекать код и тестировать непосредственно из системы управления версиями при выполнении сборки.

3. Политики ветви и сборки. Настройте политики ветвления и сборки для автоматической сборки после того, как команда вносит код в заданную ветку.

4. Развертывание в среде. Настройте конвейер выпуска, который автоматически развертывает созданные проекты в среде, которая имитирует рабочую среду.

Свести к минимуму технический долг

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

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

Всегда быть гибким

Быть Agile означает учиться на опыте и постоянно совершенствоваться. Гибкая разработка обеспечивает больше циклов обучения, чем традиционное планирование проектов из-за более жестких циклов процессов. Каждый спринт предоставляет что-то новое для команды, чтобы чему-то научиться.

Рассмотрим пример.

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

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

Дальнейшие шаги

Существует множество способов урегулирования процесса разработки Agile, который подходит для команды. Azure DevOps предоставляет различные шаблоны процессов. Команды, которые ищут различные базовые структуры для планирования, могут использовать эти шаблоны в качестве отправных точек. Сведения о выборе шаблона процесса, который лучше всего соответствует языку и целям команды, см. в разделе "Выбор потока процесса" или шаблона процесса для работы в Azure Boards.

По мере роста организаций это может быть проблемой для поддержания дисциплины. Узнайте больше о масштабировании Agile для больших команд.