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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.12. Работа над проектом на основе экстремального программирования

Одним из существенных методов данного подхода является функциональное тестирование. Существуют две особенности процесса тестирования:

• программисты сами пишут тесты для тестирования программы;

• эти тесты пишутся до начала кодирования.

Для любого автономного модуля (класса, процедуры, Unit-модуля) программисты пишут отдельный модульный тест, который должен тестировать все основные варианты использования этого модуля и храниться вместе с ним. Результаты прогонов тестов должны быть лаконичными, например "ОК! (10 tests)". Главное — тест должен писаться до написания самого модуля! Такое тестирование называют опережающим. Внесение изменений на каждой итерации проекта (рефакторинг) всегда сопровождается прогоном всех тестов, чтобы гарантировать стабильную работу системы. Уверенность в нормальной работе как каждого отдельного теста, так и всех тестов комплексного теста придает разработчикам уверенность в нормальной работе очередной версии системы на каждой итерации проекта.

Цель каждой итерации (рис. 3.13) — включить в версию несколько новых историй. На собрании по планированию итерации определяется, какие именно истории и каким образом будут они реализованы командой разработчиков.

Коллективное владение кодом в процессе разработки (рис. 3.14) означает возможность для каждого программиста в любое время усовершенствовать любую часть кода в системе, если он сочтет это необходимым. Программист берет на себя ответственность за реализацию определенных задач. В случае возникновения вопросов по разрабатываемой задаче может быть проведено короткое (15-минутное) собрание в присутствии заказчика.

Рис. 3.13. Работа на итерации экстремального программирования

Рис. 3.14. Коллективное владение кодом при экстремальном программировании

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

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

Адаптивная разработка. В основу подхода адаптивной разработки (Adaptive Software Development — ASD) положены три нелинейных перекрывающих друг друга этапа — обдумывание, сотрудничество и обучение. Автор данного подхода Джим Хайсмит (Jim Highsmith) обращает особое внимание на использование идей из области сложных адаптивных систем.

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

Рис. 3.15. Работа над кодом парой программистов при экстремальном программировании

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

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