Экстремальное программирование (Extreme Programming — XP) — оригинальная методология, предлагаемая некоторыми специалистами в качестве подхода к разработке программного обеспечения для изменчивого мира Web.

Несмотря на свое название, XP — это процесс, предусматривающий строгую дисциплину, однако многие противопоставляют его жестким процессам программирования в таких моделях, как Software Capability Maturity Model [1]. Авторы статьи рассказывают о XP и SW-CMM, показывая, что XP в состоянии помочь добиться целей SW-CMM.

SW-CMM

Software Engineering Institute, входящий в состав университета Карнеги-Меллона, разработал SW-CMM в качестве эталонной модели организации разработки программного обеспечения, и эта модель теперь широко применяется в программистском сообществе. SW-CMM — пятиуровневая модель (см. таблицу 1), которая описывает лучшие инженерные и управленческие решения и задает приоритеты развития для организаций, работающих в области программного обеспечения.

Документация с полным описанием SW-CMM занимает около 500 страниц, однако требования к пятому уровню зрелости процесса разработки укладываются всего в 52 предложения — 52 цели для 18 ключевых областей (KPA — key process area). Специалисты могут руководствоваться составляющими данную модель методами, подметодами и примерами, принимая разумные и обоснованные решения при реализации самого широкого круга процессов.

Рекомендации по SW-CMM ориентированы, в первую очередь, на крупные проекты и большие организации. Однако при минимальной адаптации и разумном отношении эту модель можно применять к совершенно разным средам, начиная от проектов, в которых участвует два-три человека, и заканчивая проектами, над которыми работает 500 человек, создающих сложные, критически важные системы [2, 3]. Cоставляющие SW-CMM компоненты умышленно абстрактны и содержат, на первый взгляд, «прописные истины» о высокоэффективных организациях.

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

Экстремальное программирование

Авторство метода XP обычно приписывают Кенту Беку, Рону Джеффрису и Варлу Каннингэму [4, 5]. Экстремальное программирование рассчитано, прежде всего, на небольшие и средние группы, создающие программное обеспечение с неопределенными или быстро меняющимися требованиями. Группы XP, как правило, работают в одном месте и состоят не более чем из 10 человек.

Важное базовое предположение XP состоит в том, что разработчики могут сократить традиционно высокие затраты, сделав процесс разработки весьма динамичным. Книга Бека так и называется «Всеобъемлющее изменение» (Embrace Change). Группы XP, как правило, следуют требованиям, динамично меняющимся в течение итеративного жизненного цикла программ, разделенного на достаточно короткие этапы.

Жизненный цикл XP состоит из четырех видов деятельности: кодирование, тестирование, прослушивание и проектирование. Динамизм XP обусловлен четырьмя характеристиками:

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

Большинство принципов XP — минимализм, простота, эволюционный жизненный цикл, вовлечение заказчиков и так далее — общеприняты и характерны для любого процесса со строгой дисциплиной. Как показано в таблице 3, «экстремальность» XP достигается как раз за счет доведения общепринятых решений до экстремального уровня. В то время как многие интерпретируют такие решения, как «фокусировка на минималистских решениях», как полную свободу, в действительности, XP предусматривает очень жесткую дисциплину. Простота в терминах XP означает необходимость сосредотачиваться на самых приоритетных на данный момент компонентах системы, вместо того чтобы решать проблемы, которые еще не возникли и, возможно, никогда и не возникнут, учитывая, что требования и операционное окружение постоянно меняется.

Обычно в XP выделяют 12 базовых элементов.

  • Повторяющиеся раунды планирования: быстро определить назначение следующей версии, соотнося бизнес-приоритеты и технические оценки. Пусть заказчик выбирает назначение, приоритет и сроки, исходя из бизнес-перспектив, а технические специалисты оценивают и отслеживают продвижение работ.
  • Небольшие модернизации: быстро начать производство простой системы. Выпускайте новые версии через очень короткие (скажем, двухнедельные) промежутки.
  • Метафоричность: сопровождайте всю разработку простыми, ясными описаниями того, как работает система в целом.
  • Простота архитектуры: в каждый момент архитектура системы должна быть максимально простой.
  • Тестирование: разработчики постоянно пишут модульные тесты, которые должны выполняться безупречно; заказчики также пишут тесты, чтобы убедиться в реализации требуемых им функций. Следуйте лозунгу «Тестируйте, а затем кодируйте».
  • Разбиение на составляющие: реструктурируйте систему, не меняя ее поведения, так, чтобы избавиться от дублирования, улучшить взаимодействие, упростить и увеличить гибкость.
  • Парное программирование: весь код пишется двумя программистами на одной машине.
  • Коллективное владение: всякий может улучшить любой код системы где угодно и когда угодно.
  • Непрерывная интеграция: компоновка системы по несколько раз в день, всякий раз, когда закончена очередная задача. Непрерывное регрессивное тестирование предотвращает функциональную регрессию при изменении требований.
  • Сорокачасовая рабочая неделя: работайте, по возможности, не более 40 часов в неделю; никогда не работайте сверхурочно более двух недель подряд.
  • Присутствие заказчика: необходимо постоянное присутствие пользователя, способного ответить на неожиданно возникающие вопросы.
  • Стандарты на кодирование: установите правила, определяющие соглашения о связях для кода в целом.

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

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

Разработчики XP, обычно, забывают о проектной документации сразу же, как только код написан, однако они сохранят ее, если посчитают, что впоследствии она будет полезна. Проектная документация сохраняется и тогда, когда заказчик прекращает добавлять новые запросы. Тут наступает время законсервировать систему и подготовить ее описание на 5-10 страницах. Всегда реализуется простейшее решение, которое удовлетворяет насущным нуждам. Изменение требований, скорее всего, все равно заставит отказаться от «общих решений».

Парное программирование — одна из наиболее спорных составляющих XP, главным образом из-за того, что оно потребует определенных действий по распределению ресурсов от тех менеджеров, которые принимают решение о том, разрешить или нет использование методов XP в проекте. Хотя, на первый взгляд, кажется, что парное программирование требует вдвое больше ресурсов, исследования показали, что оно приводит к уменьшению ошибок и сокращению цикла разработки [6]. Правда, это потребует увеличения усилий примерно на 15%, но время разработки сократится на 40-50%. В современных условиях увеличение скорости выпуска программных продуктов может оправдать такие затраты ресурсов. Кроме того, совместная работа способствует более эффективному решению проблем, а более высокое качество может значительно сократить затраты на обслуживание. Если рассматривать весь цикл жизни продукта, преимущества парного программирования зачастую более чем оправдывают некоторое увеличение затрат.

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

Основное средство управления XP — это метрика. В стиле XP три или четыре метрики — это обычно все, что группа может отслеживать одновременно. Эти метрики необходимо активно использовать, а их представление должно быть понятным. Одна из популярных метрик XP — это «скорость проекта», т. е. число запросов определенной трудоемкости, которые разработчики могут реализовать за одну итерацию.

Стратегии внедрения XP

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

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

XP и CMM

SW-CMM фокусируется на обоих вопросах управления: на эффективных и целесообразных процессах и на систематическом совершенствовании этих процессов. XP, с другой стороны, представляет собой конкретный набор приемов — «методологию», которая эффективна в контексте небольших, работающих в одном месте команд, вынужденных адаптироваться к быстро меняющимся требованиям. Вместе эти два метода могут создать единый комплекс, особенно в сочетании с другими хорошими инженерными и управленческими решениями. Это можно проиллюстрировать, рассматривая решения XP применительно к ключевым областям процессов (KPA) и целям CMM, собранным в таблице 2.

XP и SW-CMM уровня 2

XP реализует основные процессы управления требованиями SW-CMM уровня 2 за счет использования процедуры формулирования запросов, работы с представителем заказчика и постоянной интеграции. Хотя системные требования могут со временем динамически развиваться, XP позволяет учесть ответную реакцию заказчика и его требования за счет поддержки коротких циклов выпуска и постоянного участия пользователей. «Единое понимание» устанавливается и поддерживается за счет постоянной вовлеченности заказчика в подготовку запросов и выбор их для следующей версии (т.е., по существу, управление приоритетами требований заказчика).

Задачи планирования программного проекта в XP решаются за счет раундов и небольших модернизаций. Стратегия планирования XP является воплощением совета Уатта Хемпфри: «Если вы не можете планировать хорошо, планируйте часто». Первые три операции этой KPA направлены на то, чтобы убедить команду разработки программного обеспечения в необходимости раннего планирования. XP вовлекает команду разработчиков в процесс выполнения обязательств посредством необходимости оценивать усилия, требующиеся для реализации запросов заказчиков; на уровне двухнедельных циклов такие оценки, как правило, достаточно точны. Заказчик осуществляет контроль бизнес-приоритетов, выбирая, какие из запросов следует реализовать в следующей версии при данных ресурсах. План проекта не детализирует весь жизненный цикл проекта, но метафора системы определяет представление о направлении развития проекта. В результате, разработчики могут эффективно выявлять риски и управлять ими.

XP решает задачи управления программным проектом и его контроля за счет «общего представления» метрик, отслеживания скорости проекта и выполнения запросов для небольших версий. Процесс выполнения запросов на тактическом уровне проекта определяет четкие ожидания как для заказчика, так и для группы XP и максимально увеличивает гибкость на стратегическом уровне. Решение о сорокачасовой рабочей неделе — забота об участниках команды; хотя CMM и не затрагивает эту проблему, наличие «рационального рабочего дня» обычно считается хорошей характеристикой. В XP особый акцент делается на открытое рабочее пространство, что, как и «человеческий фактор», выходит за границы сферы действия CMM. С другой стороны, XP не рассматривает вопросы управления субконтрактами на программное обеспечение, что, вряд ли применимо к среде, на которую ориентированы приемы XP.

Независимая группа оценки качества программного обеспечения (SQA — software quality assurance) вряд ли вписывается в культуру XP, однако эту задачу можно решить с помощью парного программирования. Влияние коллег в среде XP позволяет добиться результатов, аналогичных тем, на достижение которых ориентирована оценка качества, построенная на обеспечении гарантии соответствия стандартам. Однако вовсе не обязательно, что это поможет руководству представить себе все проблемы, связанные с несоответствием им. Обеспечение гарантий качества процессов и продуктов за счет контроля со стороны коллег может быть весьма эффективным в рамках небольшой команды. Более крупные команды, как правило, требуют и более формальных механизмов объективной проверки соответствия требованиям, стандартам и процедурам. Кроме того, контроль со стороны коллег может быть неэффективным, когда его воздействие распространяется на всю команду, кроме того, и менеджер может оказаться уязвим для внешнего воздействия. Последняя проблема при рассмотрении вопросов оценки качества программного обеспечения должна разрешаться на организационном уровне.

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

XP и SW-CMM уровня 3

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

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

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

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

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

За уровнем 3

XP решает некоторые из задач, относящихся к SW-CMM уровня 4 и 5 (см. таблицу 4), скажем, обратная связь при быстрых циклах помогает предотвратить некоторые дефекты. Многие вопросы, которые XP либо игнорирует, либо охватывает частично, в реальных проектах, без сомнения, решаются. XP необходима поддержка руководства и инфраструктуры, даже если оно специально этого не требует.

Обсуждение

Как показало приведенное сравнение, метод XP, в целом, ориентирован на техническую работу, в то время как основным приоритетом CMM являются вопросы управления. Оба метода связаны с «культурой». В XP отсутствует элемент, который для SW-CMM имеет существенное значение — концепция «внедрения», т. е. установления культуры, определяющей, «как мы в данном случае поступаем».

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

Вопросы, связанные с размерами

Большая часть формализма, который отличает совершенствование процессов на базе CMM, — это следствие реализации крупных проектов и поддержки строгих требований к надежности, особенно для жизненно важных систем. Иерархическая структура SW-CMM, однако предназначена для поддержки некоторого диапазона реализаций через 18 ключевые области и 52 цели, которые определяют требования компании ко всему процессу создания программного обеспечения.

По мере роста системы некоторые приемы XP реализовать становиться все труднее. XP, в конце концов, предназначен для небольших команд, работающих над небольшими или среднего размера проектами. С увеличением масштаба проектов, ориентация на хорошую архитектурную «философию» становится все важнее для их успеха. Значительные инвестиции в проектирование архитектуры — одни из приемов, которые отличают успешные Internet-компании [7].

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

Зачем изучать XP?

В современных программных проектах целесообразно использовать все ценное, что есть в приемах XP, вне зависимости от того, насколько радикально их организация отличается от организации команд XP. Организации могут по-разному называть такие требования, как взаимодействие и простота, например, координация и элегантность, но без них нетривиальные проекты столкнуться с почти непреодолимыми препятствиями.

Принципы взаимодействия и простоты также являются фундаментальными для организаций, использующих SW-CMM. При определении процессов организации должны собрать минимум необходимой существенной информации, структурные определения, использующие хорошие принципы проектирования программного обеспечения (такие как сокрытие информации и абстракция), и особое значение придавать полезности и применимости [2].

Для управления процессами в реальном времени важное значение имеет оперативная обратная связь. В предыдущие эпохи эта идея выражалась в афоризме: «не трать деньги попусту»; в количественном смысле мы можем рассматривать это как суть уровня 4 в CMM. Одно из следствий культурного сдвига между уровнем 1 и уровнем 2 — это необходимость продемонстрировать смелость наших убеждений за счет реалистичности оценок, планов и обязательств.

Ошибочное противопоставление

Основное препятствие к использованию XP для совершенствования процессов состоит в том, что он лишь слегка затрагивает вопросы управления и организации, которые для SW-CMM являются приоритетными. Реализация такого рода среды, поддерживающей тесное сотрудничество, которое предполагает XP, требует осведомленного руководства и соответствующей организационной структуры.

Довод о том, что идеал CMM — строгий, статистически стабильный процесс, противоречит XP, неубедителен. XP включает в себя процессы с жесткой дисциплиной, и процесс XP сам по себе очень четко определен. Это позволяет сделать вывод о том, что CMM и XP дополняют друг друга. SW-CMM указывает организациям, что следует делать в общих чертах, но не говорит о том, как это сделать. XP представляет собой набор наилучших приемов, которые достаточно конкретно описывают действия — модель реализации — для конкретного типа среды. Приемы XP могут быть совместимы с приемами CMM, даже если они не полностью с ними сопоставимы.

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

Чтобы объединить приемы XP в методологию, возможно потребуется смена парадигмы, аналогичная той, которая оказалась необходима для совместной разработки. Хотя его концепции существовали несколько десятилетий, использование приемов совместной разработки меняет саму парадигму создания программных продуктов. XP дает системную перспективу в программировании так же, как SW-CMM дает системную перспективу в совершенствовании организационных процессов. Организации, которые хотят улучшить свои возможности, должны использовать преимущества, предлагаемые и тем, и другим, и руководствоваться здравым смыслом при выборе и реализации этих идей.

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

Благодарности

Я признателен Кенту Беку, Стиву Макконнеллу и Лори Уильямс за их замечания. Первоначальная версия статьи была представлена в XP Universe в июле 2001 года.

Литература

[1] M.C. Paulk et al., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, Mass., 1995

[2] M.C. Paulk, «Using the Software CMM with Good Judgment», ASQ Software Quality Professional, vol. 1, no. 3, June 1999

[3] D.L. Johnson, J.G. Brodman, «Applying CMM Project Planning Practices to Diverse Environments», IEEE Software, vol. 17, no. 4, July/Aug. 2000

[4] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, Reading, Mass., 1999

[5] «eXtreme Programming Pros and Cons: What Questions Remain?» IEEE Computer Soc. Dynabook, J. Siddiqi, ed., Nov. 2000; www.computer.org/seweb/dynabook/index.htm

[6] L. Williams et al., «Strengthening the Case for Pair Programming», IEEE Software, vol. 17, no. 4, July/Aug. 2000

[7] A. MacCormack, «Product-Development Practices that Work: How Internet Companies Build Software», MIT Sloan Management Rev., no. 42, vol. 2, Winter 2001

Марк Полк (mcp@sei.cmu.edu) — ведущий технический специалист в Software Engineering Institute. К области его научных интересов относятся устоявшиеся практические методы разработки и статистическое управление программными процессами. Он был идеологом первой версии книги «Развитая модель программного обеспечения» (Capability Maturity Model for Software) и руководителем проекта Software CMM Version 1.1. Он также принимал участие в разработке таких стандартов, как ISO 15504, ISO 12207 и ISO 15288.