Extreme programming: характеристика

Цели

Раскрыть сущность Extreme programming (XP), выделить основные компоненты модели, коротко их охарактеризовать.

Предисловие

Ранее рассматривалась концепция Agile для разработки программного обеспечения. Это отправная точка для конкретных методик, в число которых входит и XP. Agile очень ёмкое понятие, больше философия, ряд предписаний и тезисов. Последнее время она стала очень актуальной, объясняется это тем, что традиционный способ разработки ПО сталкивается с препятствиями, неудачами, причина которых заложена в самой модели. Как раз здесь Agile (и XP в частности) предлагает пути преодоления трудностей путём тесного взаимодействия с заказчиком, командной работы, фокусировании на достижении требований, а не написания документации (корень зла традиционной модели).

Термины

Термин (и методологию) Extreme Programming ввели в обиход Kent Beck и Ward Cunningham в 90-е годы двадцатого столетия, в дальнейшем корректировали основные положения.

Порядок изложения

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

XP is an Agile Methodology (Agile is not XP)

XP исповедует Agile. Это значит, что процесс разработки эволюционный. С одной стороны, наращивание функциональности от релиза к релизу. С другой, гибкость по отношению к требованиям и их изменениям; подстраивание под реалии среды. Административная составляющая упрощается ввиду несостоятельности и ненужности. Фактически команда саморегулируемая, участники уравнены в правах.

Планирование и релизы

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

Система прецедентов

Прецеденты (или сценарии) составляются совместно с заказчиком, расставляются приоритеты. Отмечу, что когда стоит вопрос о проработке определённой функции, которая нужна для следующего релиза (не для текущего), руководствуются фразой YAGNI - "You Aren’t Going to Need It" ("вам это не нужно"). На деле это значит, что не стоит работать над тем, что может поменяться, и в последствии потребует полностью переписать код.

(Собственно) программирование

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

Тестирование

Очень большое внимание уделяется тестированию. Оно всегда продолжительное, интегрированное в процесс разработки. Тесты пишут до написания кода приложения. Это называют Test-driven Development. Порядок следующий: написать тесты, написать код, проверить код тестами, в случае ошибок исправить код и повторить тестирование. Достоинства: тесты пишутся; у программистов возникает чувство удовлетворения (преодоление теста - вызов, процесс преодоления - fun); становятся ясны детали программного продукта; имеется возможность автоматизации этого процесса.

Коллектив

Команда разработчиков - единый организм. Здесь нет уединённых участников. Члены коллектива имеют равные права по вкладу в результат и это делает их сплочёнными. Однако команда немногочисленна (иначе начинаются трудности и деление на группы) и требует привлечения профессионалов.

Что в сумме?

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

***

Кроме XP к Agile относятся Scrum, Crystal, RUP. Они будут рассмотрены позже.