Гибкие модели разработки Agile

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

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

Частая доставка дополнительных версий программного обеспечения представителю заказчика с интервалом в несколько недель.

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

Рекомендуется, чтобы размер команды разработчиков был небольшим (от 5 до 9 человек), чтобы помочь членам команды осмысленно участвовать в личном общении и иметь совместную рабочую среду.

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

Развертывание программного обеспечения происходит быстрее и, таким образом, помогает повысить доверие клиентов.

Может лучше адаптироваться к быстро меняющимся требованиям и быстрее реагировать.

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

Люди — не процесс. Люди и взаимодействия имеют более высокий приоритет, чем процессы и инструменты.

Постоянное внимание к техническому совершенству и хорошему дизайну.

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

Гибкая разработка больше ориентирована на код и создает меньше документации.

Гибкая разработка сильно зависит от вклада клиента. Если у заказчика есть неясность в его видении конечного результата, высока вероятность того, что проект собьется с пути.

Общение лицом к лицу сложнее в крупных организациях.

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

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

Общие моменты проекта:
- Срок выполнения задачи 10 месяцев.
- Определены две команды: Команда А и Команда B.
- Команда А работает по модели "Водопад".
- Команда Б работает по модели Гибкой разработки Agile.

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

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

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

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

• Code Review: Проверка кода позволяет эффективно обнаруживать и исправлять ошибки.
• Тестирование. Тестирование кода помогает устранить ошибки и повысить его надежность. Модель предлагает разработку через тестирование (TDD) для непрерывного написания и выполнения тестовых случаев. В подходе TDD тестовые примеры пишутся еще до написания кода.
• Итерационная разработка: разработка итерациями позволяет собирать обратную связь заказчика, и на ее основе планировать разработку в новой итерации.
• Простота: Написания кода простыми структурами. Чем проще - тем понятнее.
• Проектирование: Качественное проектирование при разработки ПО.
• Интеграционное тестирование: помогает выявить ошибки в интерфейсах различных функций. Разработчики должны добиваться непрерывной интеграции, создавая и выполняя интеграционное тестирование несколько раз в день.