Рассмотрим структуру «идеального» ХР-процесса

Понятие экстремального программирования. Принципы и методики ХР. Единая команда. Короткие циклы. Стандарты кодирования.

Экстремальное программирование — или, сокращенно, XP (eXtremeProgramming) — является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.

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

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

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

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

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

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

В командах, работающих по методу XP, всегда приветствуется общение - самое быстрое средство обмена информацией и опытом. Это очень важно, когда требуется максимальная скорость разработки. Но общение, как и любое другое полезное начинание, требует постоянной поддержки. Именно поэтому кто-то из команды должен взять на себя ответственность следить за общением, стать так называемым дипломатом. Общение и необходимость объяснения своих действий другим членам команды вынуждает делать все максимально просто. Если не получается с первого раза, над упрощением работают еще и еще, пока не будет достигнута главная цель - максимальная понятность кода другим разработчикам.

Экстремальный цикл

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

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

Как следствие постоянно изменяющихся требований следует другой принцип — позднее принятие решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим структуру «идеального» ХР-процесса.

Основным структурным элементом процесса является ХР-реализация, в которую многократно вкладывается базовый элемент — ХР-итерация. В состав ХР-реализации и ХР-итерации входят три фазы — исследование, блокировка, регулирование.

Исследование (exploration) — это поиск новых требований (историй, задач), которые должна выполнять система.

Блокировка (commitment) — выбор для реализации конкретного подмножества из всех возможных требований (иными словами, планирование).

Регулирование (steering) — проведение разработки, воплощение плана в жизнь.

 

Приемочные тесты. Парное программирование. Разработка через тестирование. Коллективное владение. Непрерывная интеграция. Умеренный темп.

Приемочные тесты -

Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:

· определения удовлетворяет ли система приемочным критериям;

· вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

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

· продукт достиг необходимого уровня качества;

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

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

Хорошо написанный комплект приемочных тестов – необходимая составная часть успеха любого сложного программного проекта, особенно разрабатываемого в соответствии с принципами гибкого (agile) программирования и такими методиками, как экстремальное программирование. Одно из лучших определений приемочного теста на официальном сайте ExtremeProgramming:

Заказчик описывает подлежащие тестированию сценарии после того, как история пользователя (userstory) была корректно реализована. История может содержать один или несколько приемочных тестов – столько, сколько необходимо для проверки работоспособности системы.

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

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

Приемочные тесты с самого начала

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

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

Тут-то и приходят на помощь автоматизированные приемочные тесты: закодируйте критерии приемлемости для данной истории пользователя или функции до того, как приступать к ее реализации. Требования неясны? Уточняйте.

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