В Камаев - Технологии программирования

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

Заказчик выбирает истории для очередной итерации, основываясь на их значимости для проекта и ценности. Для первой версии системы заказчик определяет небольшое количество логически связанных наиболее важных историй. Для каждой следующей версии выбираются наиболее важные истории из числа оставшихся историй (рис. 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. Работа над кодом парой программистов при экстремальном программировании

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