ХР - процесс

Экстремальное программирование (eXtreme Programing, ХР) — облегченный (подвижный) процесс (или методология), главный автор которого — Кент Бек

(1999) [II]. ХР-процесс ориентирован на группы малого и среднего размера, стро­ящие программное обеспечение в условиях неопределенных или быстро изменяю­щихся требований, ХР- группу образуют до 10 сотрудников, которые размещаются в одном помещении.

Основная идея ХР — устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов (Паттерн является решением типичной проблемы в определенном контексте.) и реляционных баз данных. Поэтому ХР -процесс должен быть высокодинамичным процессом, ХР -группа име­ет дело с изменениями требований на всем протяжении итерационного цикла раз­работки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в ХР-

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

Большинство принципов, поддерживаемых в ХР (минимальность, простота, эво­люционный цикл разработки, малая длительность итерации, участие пользовате­ля, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы, как показано в табл. 1.2, достигают «экстремальных значений».

Таблица 1.2. Экстремумы в экстремальном программировании

Практика здравого смысла	ХР- экстремум	ХР-реализация
Проверки кода	Код проверяется все время	Парное программирование
Тестирование	Тестирование выполняется все время, даже с помощью заказчиков	Тестирование модуля, функциональное тестирование
Проектирование	Проектирование является частью ежедневной деятельности каждого разработчика	Реорганизация (refactoring)
Простота	Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность	Самая простая вещь, которая могла бы работать
Архитектура	Каждый постоянно работает над уточнением архитектуры	Метафора
Тестирование интеграции	Интегрируется и тестируется несколько раз в день	Непрерывная интеграция
Короткие итерации	Итерации являютсяпредельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы	Игра планирования

Тот, кто принимает принцип «минимального решения» за хакерство, ошибается, в действительности ХР — строго упорядоченный процесс. Простые решения, име­ющие высший приоритет, в настоящее время рассматриваются как наиболее цен­ные части системы, в отличие от проектных решений, которые пока не нужны, а могут (в условиях изменения требований и операционной среды) и вообще не понадобиться.

Базис ХР образуют перечисленные ниже двенадцать методов.

1. Игра планирования (Planning game) — быстрое определение области действия следующей реализации путем объединения деловых приоритетов и техниче­ских оценок. Заказчик формирует область действия, приоритетность и сроки с точки зрения бизнеса, а разработчики оценивают и прослеживают продви­жение (прогресс).

2. Частая смена версий (Small releases) — быстрый запуск в производство про­стой системы. Новые версии реализуются в очень коротком (двухнедельном) цикле.

3. Метафора (Metaphor) — вся разработка проводится на основе простой, обще­доступной истории о том, как работает вся система.

4. Простое проектирование (Simple design) — проектирование выполняется на­столько просто, насколько это возможно в данный момент.

5. Тестирование (Testing) — непрерывное написание тестов для модулей, кото­рые должны выполняться безупречно; заказчики пишут тесты для демонстра­ции законченности функций. «Тестируй, а затем кодируй» означает, что вход­ным критерием для написания кода является «отказавший» тестовый вариант.

6. Реорганизация (Refactoring) — система реструктурируется, по ее поведение не изменяется; цель — устранить дублирование, улучшить взаимодействие, упростить систему или добавить в нее гибкость.

7. Парное программирование (Pair programming) — весь код пишется двумя про­граммистами, работающими на одном компьютере.

8. Коллективное владение кодом (Collective ownership) — любой разработчик может улучшать любой код системы в любое время.

9. Непрерывная интеграция (Continuous integration) — система интегрируется и строится много раз в день, по мере завершения каждой задач и. Непрерывное регрессионное тестирование, то есть повторение предыдущих тестов, гаранти­рует, что изменения требований не приведут к регрессу функциональности.

10. 40-часовая неделя (40-hour week) — как правили, работают не более 40 часов в неделю. Нельзя удваивать рабочую неделю за счет сверхурочных работ.

11. Локальный заказчик (On-site customer) — в группе вес время должен нахо­диться представитель заказчика, действительно готовый отвечать па вопросы разработчиков.

12. Стандарты кодирования (Coding standards)— должны выдерживаться прави­ла, обеспечивающие одинаковое представление программного кода во всех частях программной системы.

Игра планирования и частая смена версий зависят от заказчика, обеспечивающего набор «историй» (коротких описании), характеризующих работу, которая будет выполняться для каждой версии системы. Версии генерируются каждые две неде­ли, поэтому разработчики и заказчик должны прийти к соглашению о том, какие истории будут осуществлены в пределах двух недель. Полную функциональность, требуемую заказчику, характеризует пул историй; но для следующей двухнедель­ной итерации из пула выбирается подмножество историй, наиболее важное для заказчика. В любое время в пул могут быть добавлены новые истории, таким обра­зом, требования могут быстро изменяться. Однако процессы двухнедельной гене­рации основаны на наиболее важных функциях, входящих в текущий пул, следо­вательно, изменчивость управляется. Локальный заказчик обеспечивает поддержку этого стиля итерационной разработки.

«Метафора» обеспечивает глобальное «видение» проекта, Она могла бы рас­сматриваться как высокоуровневая архитектура, но ХР подчеркивает желатель­ность проектирования при минимизации проектной документации. Точнее гово­ря, ХР предлагает непрерывное перепроектирование (с помощью реорганизации), при котором нет нужды в детализированной проектной документации, а для ин­женеров сопровождения единственным надежным источником информации является программный код. Обычно после написания кода проектная доку­ментация выбрасывается. Проектная документация сохраняется только в том случае, когда заказчик временно теряет способность придумывать новые исто­рии. Тогда систему помещают в «нафталин» и пишут руководство страниц на пять-десять по «нафталиновому» варианту системы. Использование реоргани­зации приводит к реализации простейшего решения, удовлетворяющего теку­щую потребность. Изменения в требованиях заставляют отказываться от всех «общих решений».

Парное программирование — один из наиболее спорных методов в ХР, оно влияет на ресурсы, что важно для менеджеров, решающих, будет ли проект использовать ХР. Может показаться, что парное программирование удваивает ресурсы, но ис­следования доказали: парное программирование приводит к повышению качества и уменьшению времени цикла. Для согласованной группы затраты увеличивают­ся на 15%, а время цикла сокращается на 40-50%. Для Интернет-среды увеличение скорости продаж покрывает повышение затрат. Сотрудничество улучшает процесс решения проблем, улучшение качества существенно снижает затраты сопровож­дения, которые превышают стоимость дополнительных ресурсов но всему циклу разработки.

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

«Тестируй, а затем кодируй» — эта фраза выражает акцент ХР на тестировании. Она отражает принцип, по которому сначала планируется тестирование, а тесто­вые варианты разрабатываются параллельно анализу требований, хотя традици­онный подход состоит в тестировании «черного ящика». Размышление о тестировании в начале цикла жизни — хорошо известная практика конструирования ПО (правда, редко осуществляемая практически).

Основным средством управления ХР является метрика, а среда метрик — «большая визуальная диаграмма». Обычно используют 3-4 метрики, причем такие, ко­торые видимы всей группе. Рекомендуемой в ХР метрикой является «скорость проекта» — количество историй заданного размера, которые могут быть реализо­ваны в итерации,

При принятии ХР рекомендуется осваивать его методы по одному, каждый раз выбирая метод, ориентированный на самую трудную проблему группы. Конечно, все эти методы являются «не более чем правилами» — группа может в любой мо­мент поменять их (если ее сотрудники достигли принципиального соглашения по поводу внесенных изменений). Защитники ХР признают, что ХР оказывает силь­ное социальное воздействие, и не каждый может принять его. Вместе с тем, ХР — это методология, обеспечивающая преимущества только при использовании за­конченного набора базовых методов.

Рассмотрим структуру «идеального» ХР- процесса. Основным структурным эле­ментом процесса является ХР- реализация, в которую многократно вкладыва­ется базовый элемент — ХР -итерация. В состав ХР -реализации и ХР -итерации входят три фазы— исследование, блокировка, регулирование. Исследование (exploration) — это поиск новых требований (историй, задач), которые должна выполнять система. Блокировка (commitment) — выбор для реализации конкрет­ного подмножества из всех возможных требований (иными словами, планиро­вание). Регулирование (steering) — проведение разработки, воплощение плана в жизнь.

ХР рекомендует: первая реализация должна иметь длительность 2-6 месяцев, про­должительность остальных реализаций — около двух месяцев, каждая итерация длится приблизительно две недели, а численность группы разработчиков пе пре­вышает 10 человек. ХР- процесс для проекта с семью реализациями, осуществляе­мый за 15 месяцев, показан на рис. 1.8.

Процесс инициируется начальной исследовательской фазой.

Фаза исследования, с которой начинается любая реализация и итерация, имеет клапан «пропуска», на этой фазе принимается решение о целесообразное'! и даль­нейшего продолжения работы.

Предполагается, что длительность первой реализации составляет 3 месяца, дли­тельность второй — седьмой реализаций — 2 месяца, Вторая — седьмая реализа­ции образуют период сопровождения, характеризующий природу ХР -проекта. Каждая итерация длится две недели, за исключением тех, которые относят к по­здней стадии реализации — «запуску в производство» (в это время темп итерации ускоряется).

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

Дата добавления: 2014-01-04