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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграция ранних и часто

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

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

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

Существуют некоторые ключевые действия CI/CD, которые критически важны для эффективной разработки Гибкой разработки.

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

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

3. Политики ветви и сборки. Настройте политики ветви и сборки для автоматической сборки в качестве кода команды проверка в определенной ветви.

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

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

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

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

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

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

Например:

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

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

Следующие шаги

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

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