Последнее время благодаря усилиям компании Russee, которая занимается консалтингом и обучением в области программной инженерии, российские разработчики получают возможность очного знакомства с гуру мировой программной индустрии. Вслед за Айваром Якобсоном и Майклом Кузумано в Москву приехал создатель концепции экстремального программирования (Extreme Programming, XP) Кент Бек. Его семинары положили начало целой серии мероприятий под общим названием Guru Workshop Series.

Идеям XP уже десять лет, и Бек, являясь основателем и директором института Three Rivers Institute и сотрудником компании Agitar Software, продолжает их развивать и активно продвигать. Он сам занимается программированием, пишет книги по XP и проводит профессиональные тренинги. В своем московском выступлении Бек, помимо чисто практических вопросов применения принципов XP, подробно остановился на общих идеях «скорой» (agile) разработки, одним из направлений которой является XP, и тем преимуществах, которые они способны обеспечить индустрии программного обеспечения.

Термин agile появился в 2001 году, когда представители нескольких нетрадиционных направлений в программировании, включая XP, Feature Driven Development, Crystal, Adaptive Software Development, SCRUM, собрались, чтобы сформулировать общие принципы, которыми они руководствуются. Бек объясняет суть agile как возможность быстро реагировать на изменения условий разработки — изменения в бизнесе заказчика и разработчика, влекущие за собой изменения в требованиях к программному проекту, технологические изменения и т.д. Эта общая идея подразумевает следование нескольким принципам. Прежде всего, команда, которая хочет быть agile, должна стремиться работать с меньшим количеством дефектов. Эту ключевую проблему разработки Бек предлагает начинать решать с изменения менталитета, отношения к процессу — разработчик должен рассматривать ошибки как недопустимую аномалию.

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

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

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

С этим во многом связана третья тенденция — все более активное проникновение в разработку принципов подотчетности, что Бек объясняет, в частности, влиянием аутсорсинга. Если первые десятилетия формирования отрасли разработки бизнес прощал программистам многое и редко серьезно призывал к ответу за невыполнение взятых обязательств, то в условиях договорных отношений между заказчиком и исполнителем последнему уже не остается возможностей для оправданий и извинений за срыв сроков.

По окончании семинара Бек ответил на вопросы журнала "Открытые системы.СУБД".

Экстремальное программирование появилось десять лет назад. Наверняка уже существует легенда о создании ХР. 

Это началось во время работы над проектом для корпорации Chrysler, на который были потрачены миллионы долларов без особого успеха. Я принял решение начать проект с начала. К тому времени у меня накопилось много идей по поводу разработки программного обеспечения, правда, еще не оформленных в единое целое. На первом этапе вновь начатого проекта я провел интервью со всеми его участниками. Первому своему собеседнику я представил небольшую часть того, что потом получило название экстремального программирования, а именно понятие об итерациях и историях. В разговоре со следующим я добавил еще несколько элементов нового метода, в частности, тот факт, что каждая история в процессе разработки должна сопровождаться тестированием. Со следующим участником проекта я говорил также о том, как программировать в парах. И таким образом, добавляя в каждой беседе еще несколько идей, к концу дня я сформулировал все технологические основы XP.

В чем состоит суть XP? Что в XP помогает улучшать процесс разработки?

У XP есть очевидные технические преимущества: программирование в парах позволяет делать меньше ошибок, поступательное движение проекта по небольшим этапам с небольшими усовершенствованиями упрощает и улучшает дизайн системы и т.д. Но сегодня я понимаю, что суть XP состоит в том, чтобы каждый член команды разработки брал на себя ответственность за обеспечение качественного конечного результата для заказчика. Если я программист, я не должен считать, что я только программирую, а все остальное меня не касается. Разработка ПО — это длинная цепочка этапов для реализации конечного продукта. И даже если вы работаете над некоторым небольшим элементом этой цепочки, вы должны представлять себе перспективу проекта в целом, осознавая важность задач других его участников. Вы должны понимать свою индивидуальную ответственность в проекте не просто как ответственность программиста за некоторый код, а как ответственность за код, который вносит весомый вклад в реализацию продукта для заказчика. В этом, по моему мнению, главный смысл ХР. В понимании, что то, что я делаю здесь и сейчас, будет оказывать влияние на мою команду, на нашего заказчика, на общество в целом. Я не должен игнорировать важность взаимодействия с людьми, которые вместе со мной участвуют в процессе разработки.

Судя по всему, XP за свою историю претерпел определенную эволюцию. На семинаре вы упомянули о создании второй редакции XP. В чем ее отличия от первой?

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

Существуют ли условия, в которых ХР не применим, или это универсальная методика?

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

Как вы определяете качество программного продукта, и как ХР помогает обеспечить качество?

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

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

Критическое значение для того, чтобы обеспечить максимальное использование возможностей участников разработки в интересах проекта, играет степень ответственности за достижение наилучшего конечного результата, которую члены команды готовы на себя принять. Если я участвую в проекте и считаю, что моя задача писать код, а все остальное меня не волнует, то я упускаю возможность использовать свой талант в интересах всего проекта в целом. Но чем большую ответственность я на себя возьму, тем больше у меня будет возможностей проявить свою энергию и творческие способности, чтобы приблизить проект к успешному завершению. Есть ли возможность проявить творческое начало в XP? Безусловно. Я могу приложить свои творческие способности в тестировании, дизайне, построении взаимоотношений. В XP очень важны доверительные отношения в команде разработки, и требуются время и значительные усилия, в том числе творческие, чтобы сформировать такие отношения.

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

Риски проекта тоже можно воспринимать как с положительной, так и с отрицательной точек зрения. Например, некоторый поставщик предоставляет новую версию своей системы, возможности которой вы хотите использовать в разработке программного обеспечения. При этом существует риск не получить ожидаемого. Предположим, мы смотрим на эту ситуацию негативно. Тогда мы скажем, что есть серьезный риск для проекта, и если он оправдается, то весь проект может сорваться. Но эту же ситуацию я могу воспринимать позитивно и считать, что да, есть риск для проекта, но это просто факт, не отрицательный и не положительный. Что я могу сделать? Я могу разбить проект на два этапа. На первом мы будем использовать в разработке уже существующие технологии этого вендора, а на втором применим новое поколение возможностей его продукта. В этом состоит позитивное отношение к возможному риску — я ищу пути решения проблемы. А негативный взгляд на вещи порождает безнадежное отношение к ситуации: наверняка что-нибудь произойдет, и весь проект рухнет.

Существует ли сейчас сообщество приверженцев методов скорой (agile) разработки, которое занимается их продвижением, популяризацией, обучением?

Есть сообщества, деятельность которых сфокусирована на отдельных методах. Самый масштабный сбор людей, которые занимаются agile-разработкой, я наблюдал в этом году на конференции в Миннеаполисе. Число участников таких конференций растет из года в год очень быстро. Однако я не думаю, что ведется какая-либо деятельность по унификации agile-методов. Мне как раз нравится, что между ними есть различия, и их приверженцы делают акцент на разных особенностях разработки. Я, как представитель XP, веду диалог с программистами и менеджерами с точки зрения роли программирования в проекте. Приверженцы методики SCRUM ставят во главу угла управление проектами. Так что хорошо, что в разных методах находят отражение разные аспекты принципов agile.

Что можно сделать для того, чтобы поднять статус профессии программиста?

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

А что означает слово «экстремальное»? И для чего лучше подходит XP — для преодоления экстремальных условий в разработке или для предотвращения появления таких условий?

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

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

Что вы думаете о необходимости строгой архитектуры и моделирования в программном проекте, находят ли они отражение в XP?

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

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

Принципы XP

Наш журнал еще в 2000 году опубликовал большую статью Кента Бека, посвященную экстремальному программированию (Кент Бек, Экстремальное программирование. «Открытые системы», 2000, № 1-2). Напомним основные принципы, следование которым предполагает этот метод разработки.

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

Частая смена версий (small releases). Система запускается в эксплуатацию через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Новые версии появляются часто, с периодичностью, которая колеблется от ежедневного до ежемесячного выпуска.

Метафора (metaphor). Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты.

Простой проект (simple design). В каждый момент времени разрабатываемая система выполняет все тесты, поддерживает все взаимосвязи, которые определяет программист, не имеет дубликатов кода и содержит наименьшее возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз».

Тесты (tests). Программисты постоянно пишут тесты для модулей (unit test). Эти тесты собираются вместе, и все они должны работать корректно. Заказчики пишут функциональные тесты (functional test) для историй в итерации. Все эти тесты также должны работать правильно, хотя на практике подчас приходится идти на компромисс. Чтобы принять правильное решение, необходимо понять, во сколько обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки для исправления дефекта.

Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов.

Программирование в паре (pair programming). Весь код проекта пишется двумя людьми, которые используют одну настольную систему.

Непрерывная интеграция (continuous integration). Новый код интегрируется в существующую систему не позднее чем через несколько часов. После этого система вновь собирается в единое целое и прогоняются все тесты. Если хотя бы один из них не выполняется корректно, внесенные изменения отменяются.

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

Постоянное участие заказчика (on-site customer). Представители заказчика все время работы над системой взаимодействуют с командой разработчиков.

40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одной рабочей недели. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, являются сигналом серьезных проблем, которые требуют безотлагательного разрешения.

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

Не более чем правила (just rules). Если вы входите в коллектив, работающий по методам ХР, вы обязуетесь выполнять вышеизложенные правила. Однако, это не более чем правила. Команда может в любой момент поменять их, если ее члены достигли принципиального соглашения по поводу внесенных изменений.

XP и CMMI

Кент Бек провел интересное сравнение метода экстремального программирования и модели зрелости процессов разработки CMMI. CMMI предназначена для оценки зрелости процессов массового производства программного обеспечения, а особенностью XP является учет социологических аспектов разработки. По существу, цель CMMI — снизить вариативность разработки, обеспечить плавный, согласованный, четко определенный (как сказал Бек, механистический) процесс разработки с минимумом изменений. XP же, как метод agile-разработки, направлен прежде всего на то, чтобы дать возможность оперативно реагировать на изменения и быстро начинать зарабатывать деньги на результатах разработки. Бек заметил, что если такая методика разработки, как Rational Unified Process, определяется архитектурой системы, то для XP главным руководящим принципом является экономика разработки, возможность извлечь максимум в денежном выражении из всех этапов цепочки разработки.

Еще одно отличие между XP и CMMI состоит их ориентации на потребителя. XP предназначен для программистов и всех участников разработки, нацелен на улучшение выполнения разных ее этапов. Модель CMMI привлекает прежде всего заказчиков программных продуктов, поскольку сфокусирована на измерении ключевых показателей в различных областях разработки и обеспечении предсказуемости проекта. Бек отметил также, что в отличие от CMMI, которая была заказана Министерством обороны CША, создание XP никем официально не инициировалось, а стало следствием многолетних размышлений о способах совершенствования процесса программирования.

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

Однако при всех различиях сходство между XP и CMMI заключается в том, что они нацелены на улучшение процессов разработки. И Бек считает, что коллективы разработчиков, использующие принципы XP, начинают не менее чем с уровня 5 модели зрелости. Замечу, что создатель одной из первых версий CMM Марк Полк уверен, что команды, практикующие методы agile-разработки, могут рассчитывать не более чем на третий уровень зрелости.