Agile Software Development 101

Содержание

Краткое описание жизненного цикла разработки программного обеспечения
Почему Agile разработки отличаются
Agile Practices
Зачем идти Agile?
Нет ошибок, нет стресса - ваше пошаговое руководство по созданию изменяющего жизнь программного обеспечения без разрушения вашей жизни

вынос:

Этот метод разработки программного обеспечения поощряет сотрудничество и гибкость, помогая создавать высококачественный продукт.

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

Краткое описание жизненного цикла разработки программного обеспечения

Жизненный цикл разработки программного обеспечения (SDLC) - это процесс создания программных решений или изменения существующих структур, предназначенных для решения конкретной проблемы. Он включает в себя различные этапы, которые выполняются в логическом порядке. В традиционных моделях SDLC это шаги, которые выполняются один за другим и обычно выполняются изолированно:

Сбор требований от клиентов
Системный и технико-экономический анализ
Дизайн и моделирование
Кодирование или реализация
тестирование
Развертывание и доставка
Обслуживание и запросы на изменение

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

Почему Agile разработки отличаются

Наиболее распространенные традиционные модели SDLC - модель водопада, модель быстрого применения, итерационная модель, спиральная модель и т. Д. - имеют свои плюсы и минусы. Потребовались годы, прежде чем люди смогли реально проанализировать, насколько реалистичны эти модели. Они идеально вписываются в идеальные сценарии, но не всегда практичны, когда речь идет о реальных приложениях. В результате команды разработчиков программного обеспечения столкнулись с множеством проблем. Некоторые из ограничений традиционных моделей SDLC включают в себя:

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

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

Agile Practices

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

Хотя нет исчерпывающего списка Agile-принципов, есть определенные практики, которые Agile распространяет. Они включают:

Разработка через тестирование (TDD)
В идеале разработчики должны сначала написать контрольные примеры для той функциональности, для которой они собираются писать код. Это обеспечит качественный код, который с меньшей вероятностью сломается в исключительных условиях. Этот процесс также помогает гарантировать, что пользовательские спецификации были учтены.
Парное программирование
В гибкой разработке программисты обычно работают над одной и той же проблемой в парах, когда один человек пишет код (драйвер), а другой - просматривает код и предоставляет идеи и предложения (навигатор). Это повышает производительность и сокращает время, необходимое для просмотра кода.
Рефакторинг кода
Рефакторинг кода включает разбиение кода на более мелкие и простые модули, которые могут (и должны) существовать независимо в идеальном сценарии. Это в значительной степени улучшает читабельность, тестируемость и удобство сопровождения кода.
Активное участие от фактических заинтересованных сторон
После регулярных интервалов определенного периода времени (называемого «ss») клиенты должны получить значительный работающий прототип программного обеспечения. Это позволяет разработчикам получать отзывы о том, что они строят по ходу работы.
Рассматривать требования как приоритетный стек
В Agile важно классифицировать требования в зависимости от их важности. Это может включать как явные, так и явные ожидания клиентов в отношении разрабатываемого программного продукта. Команда разработчиков программного обеспечения должна совместно оценить время и ресурсы, которые они собираются инвестировать в реализацию этой функции, и отобразить ее на основе требований пользователя и относительного порядка, в котором они будут заниматься каждой частью проекта.
Регрессионное тестирование
Регрессионное тестирование включает тестирование функциональности всего приложения после добавления новой функции или изменения существующей функциональности в коде. Это помогает гарантировать, что изменения не сломали существующий код.

Зачем идти Agile?

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