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

3.8. АДАПТИВНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ

Адаптивные технологические подходы были задуманы как подходы, поддерживающие изменения. Они только выигрывают от изменений, даже когда изменения происходят в них самих. Данные подходы ориентированы на человека, а не на процесс. Во время работы в них необходимо учитывать природные качества человеческой натуры, а не действовать им наперекор (http://www.martinfowler.com).

Экстремальное программирование. Наиболее концентрированно идеи быстрой разработки программ оказались выражены в подходе экстремального программирования (extreme programming) (XP) (http://www.extremeprogramming.org). Две основные черты, присущие быстрым разработкам, являются базовыми и в этом подходе. Методы, объединенные в данном подходе, не являются принципиально новыми. Однако именно их рациональное объединение и совокупное использование дают существенные результаты и успешно выполненные проекты. Наибольшую пользу подход экстремального программирования может принести в разработке небольших систем, требования к которым четко не определены и позднее могут измениться.

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

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

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

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

— итерационный этап: заказчики пишут тесты и отвечают на вопросы разработчиков, пока последние программируют;

— этап выпуска версии: разработчики устанавливают систему, заказчики принимают работу.

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

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

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

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