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

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

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

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

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

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

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

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

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

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

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

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

Submitted by on Wed, 01/25/2012 - 02:28

7. Адаптивные модели процесса разработки: , Scrum

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

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

Принципы «живой» разработки

Основные принципы «живой» разработки ПО зафиксированы в манифесте, появившемся в 2000 году:=

Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты
Работающая программа более важна, чем исчерпывающая документация
Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
Отработка изменений более важна, чем следование планам

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

Наиболее часто используемой адаптивной моделью является модель экстремального программирования (eXtreme Programming, XP-процесс)
XP-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределенных или быстро меняющихся требований

XP-процесс (экстремальное программирование)

Основная идея XP-процесса – устранить высокую стоимость внесения изменений . Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций .
Базовыми действиями xp являются:=

кодирование,
тестирование,
выслушивание заказчика,
проектирование

Принципы XP

Высокий динамизм разработки обеспечивается следующими принципами:=

непрерывная связь с заказчиком,
простота выбираемых решений,
быстрая обратная связь на основе оперативного тестирования,
профилактика рисков

Практики XP разработки

Реализация этих принципов достигается за счет использования следующих методов:=

Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система
Простое проектирование – принимаются наиболее простые из возможных проектные решения
Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант
Реорганизация (Refactoring) – улучшение структуры системы при сохранении ее поведения
Парное программировани е – код пишется двумя программистами на одном компьютере
Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы
Непрерывная интеграция – система интегрируется как можно чаще ; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований
Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика
Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы

схема XP разработки

изображение XP (схема XP разработки):

Scrum-модель

Является еще одним примером адаптивного процесса разработки (ранее мы рассматривали )
Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году

Основная идея Scrum-модели

Экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты

Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин

«scrum» - «толкотня; схватка вокруг мяча (в регби)»

Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером

Роли

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

Этапы разработки

Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней)
Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ

Планирование спринта

Запросы на выполнение работ определяются на этапе совета по планированию спринта – sprint planning meeting

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

Выполнение спринта

Во время спринта команда выполняет определенный фиксированный список заданий - backlog items , наращивая функциональность программного продукта

На протяжении этого периода никто не имеет права менять список требований к работе , что следует понимать, как заморозку требований (requirements) во время спринта

Scrum схема =

текст опорного ответа (не позиционирую его как обязательное)

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

Основные приёмы XP

· Короткий цикл обратной связи (Fine scale feedback)

o Разработка через тестирование (Test driven development)

o Игра в планирование (Planning game)

o Заказчик всегда рядом (Whole team, Onsite customer)

o Парное программирование (Pair programming)

· Непрерывный, а не пакетный процесс

o Непрерывная интеграция (Continuous Integration)

o Рефакторинг (Design Improvement, Refactor)

o Частые небольшие релизы (Small Releases)

· Понимание, разделяемое всеми

o Простота (Simple design)

o Метафора системы (System metaphor)

o Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

o Стандарт кодирования (Coding standard or Coding conventions)

· Социальная защищенность программиста (Programmer welfare):

o 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

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

В XP особое внимание уделяется двум разновидностям тестирования:

· тестирование модулей (unit testing);

· приемочное тестирование (acceptance testing).

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

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

Для XP более приоритетным является подход, называемый TDD (Test Driven Development) - сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.

Игра в планирование

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

Заказчик всегда рядом

«Заказчик» в XP - это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Парное программирование

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

Непрерывная интеграция

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

Рефакторинг

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

Частые небольшие релизы

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

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

Простота дизайна

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

Метафора системы

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

Метафора системы (system metaphor) - это аналог того, что в большинстве методик называется архитектурой. Метафора системы дает команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты и какую форму они должны принять.

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

Стандарты кодирования

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

· члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;

· обеспечивается эффективное выполнение остальных практик.

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

Коллективное владение

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

Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным

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

Главные действующие роли в Scrum: ScrumMaster - тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster); Владелец Продукта (Product Owner) - человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.

_____________
матфак вгу и остальная классика =)

Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:

Короткий цикл обратной связи (Fine scale feedback)
- Разработка через тестирование (Test driven development)
- Игра в планирование (Planning game)
- Заказчик всегда рядом (Whole team, Onsite customer)
- Парное программирование (Pair programming)
Непрерывный, а не пакетный процесс
- Непрерывная интеграция (Continuous Integration)
- Рефакторинг (Design Improvement, Refactor)
- Частые небольшие релизы (Small Releases)
Понимание, разделяемое всеми
- Простота (Simple design)
- Метафора системы (System metaphor)
- Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
- Стандарт кодирования (Coding standard or Coding conventions)
Социальная защищенность программиста (Programmer welfare):
- 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

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

В XP особое внимание уделяется двум разновидностям тестирования:

тестирование модулей (unit testing);
приёмочное тестирование (acceptance testing).

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

Игра в планирование

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

Заказчик всегда рядом

«Заказчик» в XP - это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Парное программирование

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

Непрерывная интеграция

Рефакторинг

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

Частые небольшие релизы

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

Простота дизайна

Метафора системы

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

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

Стандарты кодирования

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

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

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

Коллективное владение

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

Литература

Кент Бек: Экстремальное программирование - Питер, 2002, ISBN 5-94723-032-1 .
Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование - Питер, 2003, ISBN 5-318-00111-4 .
Кент Бек: Экстремальное программирование: разработка через тестирование - Питер, 2003, ISBN 5-8046-0051-6 .
Кен Ауэр, Рой Миллер: «Экстремальное программирование: постановка процесса с первых шагов и до победного конца» - Питер, 2003, ISBN 5-318-00132-7 .

См. также

Ссылки

Ward Cunningham Wiki (англ.) - «передний край» XP.
XProgramming.com (англ.) - сайт Рона Джеффриза: статьи и ресурсы по XP и смежным вопросам, обзоры книг.
Extreme Programming: A gentle introduction (англ.) - «Ненавязчивое введение в XP» Дона Уэллса.
MAXKIR.COM (рус.) - переводы статей отцов-основателей и идеологов XP
www.agiledev.ru (рус.) - Сайт гибких методик разработки
TopCoder (англ.) - соревнование по спортивному программированию
Электронная библиотечка книг по экстремальному программированию (рус.)
Экстремальное программирование - реальность и мифы (рус.)
Тестирование в свете Экстремального Программирования. Часть 1 (рус.)
IT и психология. Человеческий фактор в парном программировании: почему многие не получают желаемого от его внедрения? (рус.)

Разработка программного обеспечения
Известные деятели
Процесс
Концепции
Направления
Модели разработки
Другие модели
Прочее

Wikimedia Foundation . 2010 .

Смотреть что такое "Экстремальное программирование" в других словарях:

экстремальное программирование - Одна из методологий разработки ПО. Тематики информационные технологии в целом EN extreme programmingXP … Справочник технического переводчика

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

Экстремальное управление проектами (англ. Extreme project management, XPM) метод управления очень сложными или неопределёнными проектами. От традиционных методов управления проектами XPM отличается открытым, гибким и… … Википедия

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

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

общение;
простота;
обратная связь;
храбрость.

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

Игра в планирование;
Тестирование до начала разработки;
Парное программирование;
Постоянная переработка;
Простота разработки;
Коллективное владение кодом;
Продолжающаяся интеграция;
Заказчик на рабочей площадке;
Быстрый выпуск версий;
Сорокачасовая рабочая неделя;
Стандарты кодирования;
Метафора системы.

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

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

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

Метафора системы. Разрабатываемые продукты или фрагменты кода сравниваются, с
какими-либо аналогичными продуктами или явлениями. Строятся метафоры. Это
упрощает понимание задачи, а, соответственно, ускоряет разработку.

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

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

Теперь давайте посмотрим, как подходы ХР могут быть использованы на практике в
наших условиях. Одной из моих на работе задач является автоматизация учебного
процесса. Собственно говоря, я на протяжении достаточно большого отрезка времени
занимаюсь написанием приложения, осуществляющего (по крайней мере по замыслу
автора:)) комплексное решение этой проблемы. Бюджет у проекта мизерный, а объем
работ – приличный. Еще одним, чуть ли не решающим фактором было постоянное
видоизменение предметной области. Регулярно меняются формы отчетной
документации, и методика их получения. Сложилась ситуация, когда проект перестал
успевать за требованиями пользователя. И однажды наступил момент, когда в силу
объективных и субъективных причин, разработку можно было смело хоронить. Однако
неожиданно передо мной была поставлена конкретная задача определения
загруженности аудиторного фонда на семестр. К этому моменту из трех участников
проекта остался я один, а данная подсистема не была реализована и реализация ее
даже не стояла в ближайших планах развития проекта. О таких мелочах как
грамотная постановка задачи, подсчет трудоемкости работ, выделении
дополнительных ресурсов никто даже и не задумался. На выполнение задачи было
отведено две недели. При этом мои аргументы, касающиеся невозможности выполнения
данной задачи не рассматривались в принципе. Первым моим решением было подыскать
себе другого работодателя, так как за две недели я был должен написать не только
модуль анализа загруженности аудиторного фонда, но и систему ввода расписания
занятий, контроля накладок и многое другое. Автономно, данная задача не решается
в принципе — нужны исходные данные. И не просто исходные данные, а корректные
исходные данные, откуда и вытекают все вышеперечисленные задачи. Тем не менее,
не знаю почему, но я взялся за решение этой задачи.

Естественно, что говорить о разработке классическими методами в данном случае
неуместно. Вот здесь-то и пригодились подходы ХР. Общее представление о задаче я
уже имел, однако имелось множество нюансов, которые потенциально могли
значительно увеличить объем работ. Начал работу я с того, что набрал номер
учебного отдела и стал засыпать снявшего трубку массой вопросов, ответы на
которые я не мог найти самостоятельно или в которых я не был уверен.
.
Я запустил Rational Rose и приступил к составлению модели. К концу рабочего дня
я набросал модель, показавшуюся мне более-менее адекватной. После работы я
предпринял еще один шаг, отвечающий идеологии ХР. Я вытащил своего приятеля,
работающего в учебном отделе попить пива. В процессе этого, важного во всех
отношениях мероприятия, я изложил ему свое виденье программы, ее интерфейса и
логики работы. Он, в свою очередь, принимался рассказывать о необходимости
решения некоторых локальных подзадач. К вечеру я уже более четко уяснил, что же
все-таки нужно сделать в рамках данного проекта (я уже не сомневался, что задачу
следует рассматривать как отдельный проект). Тем не менее, не был решен еще один
не маловажный вопрос – выбор средств разработки. Когда происходили описываемые
события, я начинал активно изучать MDA технологию. Вкратце, суть ее такова:
фрагменты кода приложения и структуры данных генерируются автоматически, исходя
из UML модели, что позволяет существенно сократить время разработки. В рамках
данной статьи я не буду детально описывать принципы работы MDA, но хочу
акцентировать ваше внимание на том, что использование этой технологии полностью
отвечает «духу XP». Связано это с тем, что одним из условий, при котором
методики XP будут успешно работать, это снижение стоимости изменений, вносимых в
приложение на поздних стадиях разработки. Среди факторов, способствующих
достижению этого, не маловажным является использование различных новых
технологий программирования. Замечу, что именно простота рефакторинга MDA
приложений является одним из основных преимуществ этой технологии. Вообще, на
сегодня существует достаточно много реализаций MDA, я остановил свой выбор на
Bold for Delphi.

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

Альтернативным вариантом было написание «обычного» Delphi приложения. Я запустил
ICQ и написал сообщение своему знакомому – адепту Bold. После того, как я
вкратце изложил ему суть проблемы, я спросил, как бы он на моем месте поступил.
Он ответил примерно следующим образом: «Либо погружаться с головой в Bold, либо
ты никогда не освоишь его. Сделать серьезный проект – лучший способ изучить
технологию». Собственно, другого ответа я и не ожидал.

С утра я взял существующую модель и начал строить приложение. Именно, строить. К
кодированию я не приступал, а просто набросал пользовательский интерфейс, многие
элементы которого практически сразу заработали. На перекур я старался выходить в
компании сотрудников учебного отдела, это позволяло мне затащить очередную
«жертву» к экрану своего монитора и (не без некоторой доли гордости) показывал
промежуточные результаты. Таким образом, реализовывался принцип обратной связи.
Вы можете справедливо заметить: «А как же парное программирование?». Да,
действительно, в качестве программиста в проекте участвовал я один. Но тут я
упомяну еще об одном счастливом стечении обстоятельств. В тот период времени,
когда происходили описываемые события, я, совместно с группой разработчиков —
энтузиастов развивал Интернет-проект, посвященный, именно MDA. И вот, когда я
подошел к самому сложному месту в своей разработке, этот проект принес
совершенно неожиданные результаты.

В течение нескольких дней я писал код процедуры, реализующей отображение занятий
на экране. Стандартные элементы управления не позволяли вывести на экран все
данные, в той форме, в которой они обычно представляются. Мне же хотелось, что
бы конечный пользователь хотя бы приблизительно понимал, что же делает программа
и как с ней работать. Я написал свой компонент, на основе обычного TStringGrid.
Я не был уверен в том, что это было хорошее решение, но код работал. В форуме
нашего проекта я изложил свое решение, ожидая получить какую-то оценку в течение
достаточно долгого промежутка времени. Однако буквально через 15-20 минут пришел
первый ответ. Предлагался альтернативный вариант решения, а еще через 10 минут
пришел тестовый пример, да не один, а сразу два, от двух авторов. Если
задуматься над тем, почему разработчики, с таким энтузиазмом принялись решать
чужую задачу, то можно прийти к простому выводу. Во-первых, им просто было
интересно найти некоторое универсальное решение, которое затем можно
использовать в своих проектах. А во-вторых, им был интересен сам процесс
общения. Надо отметить, что с таким же энтузиазмом решались и другие задачи
различного уровня сложности. Конечно, это не является парным программированием в
обычном понимании. Скорее это некий суррогат, но, тем не менее, в этом есть и
свои плюсы. Скажем, все высказываемые мысли, и идеи автоматически
документировались, и к ним можно было обратиться в любой момент.

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

Как я уже говорил, я не старался строго придерживаться методик экстремального
программирования. А в прочитанных мною книгах недвусмысленно утверждалось, что
написание теста – один из наиболее важных моментов в XP, и без этого остальные
методики сработать не должны. Почему же в итоге я достиг положительного
результата? Все оказалось достаточно просто. Ответить на этот вопрос мне помог
именно этот пример с зелеными и красными лампочками. Дело в том, что в Bold
имеется возможность показать, соответствует – ли данный объект модели. И
делается это как раз с помощью подобных «лампочек». Буквально две строки,
которые я почти сразу вставил в код приложения, позволяли мне увидеть, в каком
месте происходит несоответствие (если таковое имеется). Именно это и заменило
мне тестирование. Возможно, что такой подход и не совсем соответствовал
оригинальной идее «тестирования до начала разработки», но это сработало.

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

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

http://xprogramming.com.ua/ — мир
экстремального программирования

http://www.xprogramming.ru/ —
экстремальное программирование по русски

http://www.maxkir.com/ — о разработке
программного обеспечения

http://xprogramming.com/ — сайт
идеолога XP Рона Джеффриса

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

Вначале была модель «водопада» (рис.1а): мы просим пользователей однозначно сформулировать свои требования; мы разрабатываем проект системы, которая сделает все, что хотят пользователи; мы пишем код; мы тестируем программу, дабы убедиться, что она действительно делает то, что требуется. Все получается замечательно.

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

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

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

Академическое сообщество разработчиков ПО взялось разрешить проблему высокой стоимости изменений и создало новые технологии - реляционные базы данных, модульное программирование, сокрытие информации. Но что если все эти труды уже исчерпали свой потенциал? И нам удастся найти новый способ снизить расходы на внесение изменений, не разрезая «водопад» на части, а просто смешав все его компоненты? То, что получилось в результате, показано на рисунке 1с. Мы назвали это «экстремальным программированием» (Extreme Programming, XP).

Анатомия XP

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

Цикл разработки XP

На рис. 2 процесс XP соотносится с различными осями времени, где в качестве единицы измерения используются годы, месяцы, недели и дни. Заказчик определяет очередную версию (release) системы, выбирая наиболее ценные функции (в XP их называют историями - story) из всех возможных. Ценность функций определяется материальными и временными затратами на их реализацию командой разработчиков.

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

Истории

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

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

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

Версия

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

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

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

Итерация

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

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

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

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

Задача

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

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

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

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

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

Тест

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

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

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

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

У Вас проблемы?

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

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

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

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

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

Текучесть кадров. Предположим, один из членов команды решил ее покинуть. Не окажетесь ли вы в тупиковой ситуации из-за отсутствия нужных документов ли отчетов? Прежде всего, заметим, что некоторая текучесть кадров полезна для команды разработчиков и отдельных ее членов. Хотелось бы, конечно, чтобы, уходя, люди руководствовались положительными мотивами. Если, отправляясь домой в конце очередной недели, программист видит конкретные положительные результаты своей деятельности, вероятность его разочарования в работе и возникновения желания уйти значительно снижается.

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

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

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

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

Вначале я не представлял себе достаточно четко степень адаптируемости ХР к изменениям. В первой версии ХР процесс выбора историй был частью планирования версии, и истории назначались для всех итераций в версии. Затем разработчики обнаружили, что затрачивая меньшие усилий на планирование, можно достичь лучших результатов. Поэтому теперь заказчика просят специфицировать только те истории, которые должны присутствовать в очередной итерации. Если появляется новая история, вы помещаете ее в резерв и не перетасовываете оставшуюся часть итерации. Через одну или две недели, если новая история еще не потеряла своей актуальности, заказчик выберет ее.

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

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

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

Строгое разграничение между деловыми и техническими решениями, которое проводит ХР, восходит к работам архитектора Кристофера Александра. В его книге «The Timeless Way of Building» отмечается, что те, кто эксплуатирует здание, должны быть допущены к принятию важных решений в процессе его сооружения.

Принятые в ХР принципы быстрого развития плана в соответствии с вносимыми техническими и связанными с бизнесом изменениями, отражают принципы методологии Scrum и разработанного Уордом Кэнингхемом языка шаблонов Episodes .

Идея специфицирования и планирования проекта с точки зрения реализуемых возможностей восходит к работам Ивара Якобсона .

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

«Спиральная модель» (Spiral Model) Барри Боэма была первой реакцией на устаревание модели водопада. Долгое время в освоении мощных технологий никто не мог превзойти Дейва Томаса и его коллег из Object Technology International, создавших метод JIT .

Корни принципа метафор, которые используются в ХР, можно найти в книгах Джорджа Лакоффа и Марка Джонсона, в частности, в их последней работе «Philoslphy in the Flesh» . Этот принцип предложен также Ричардом Койне, который связывал метафору и разработку программного обеспечения с точки зрения постмодернистской философии .

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

Примеры выполнения проектов с использованием XP

Компания Acxiom: на пути к достижению общей цели

Джи Ханнула

Команда: менеджеры, бизнес-аналитики, разработчики, тестировщики, технические писатели

Приложение: база данных управления кампанией

Срок реализации: 3 года

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

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

Много сил пришлось потратить на тестирование модулей, поскольку Forte не предлагает встроенных базовых средств для тестирования. Нам пришлось создать свои и с их помощью успешно провести тестирование. Недавно мы перешли на язык программирования Java и теперь как средство тестирования используем JUnit.

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

Мы поняли, что следовать принципам ХР должен каждый член команды, иначе этот подход не будет работать. Теперь мы сразу предупреждаем потенциального разработчика, что если его не устраивает принятый у нас стиль, ему лучше поискать работу в другом коллективе. Один человек, не заинтересованный в выбранном методе разработки, может свести к нулю усилия всей команды. Суть ХР - коллективная выработка новых идей в процессе создания системы.

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

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

DaimlerChrysler: лучшая в мире команда

Чет Хендриксен

Команда: 15 человек, из них 10 программистов

Приложение: полномасштабная автоматизация расчета платежных ведомостей

Срок реализации: 4 года

Работа над проектом С3 была начата в январе 1995 года. Корпорация Chrysler заключила контракт с партнерской компанией, в соответствии с которым за реализацию проекта бралась объединенная команда разработчиков из обеих организаций. Наши партнеры придерживались методологии разработки, ориентированной на использование графического интерфейса и игнорировавшей автоматизацию тестирования. В результате мы получили систему, которая изобиловала невыразительной графикой и для большинства служащих вычисляла зарплату неправильно. Для создания месячной платежной ведомости такой системе понадобилось бы около 100 дней. Мы поняли, что написанная нами программа никогда не будет реально использоваться.

Мы обратились к Кенту Беку с просьбой помочь отрегулировать производительность системы. Он обнаружил у нас те же явления, с которыми сам постоянно сталкивается, берясь за задачу настройки производительности: плохо продуманный код, тесты, которые нельзя запустить повторно, руководство, потерявшее уверенность в своем проекте. Кент Бек порекомендовал выбросить весь написанный код и начать полномасштабный ХР-проект.

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

Этот этап реализации С3 был запущен в мае 1997 года, хотя мы рассчитывали на более ранние сроки. Срыв наших планов был обусловлен двумя факторами. Во-первых, мы решили заменить только внутренние компоненты платежной системы. Все внешние интерфейсы остались нетронутыми. Поставить в соответствие выходные данные новой системы компонентам старой оказалось гораздо более сложной задачей, чем мы предполагали. Во-вторых, мы решили в течение любого платежного периода не инициировать реализацию специальных требований, таких, например, как обработка W-2, участие в прибыли или общее повышение заработной платы. В результате то, что должно было быть сделано в ноябре, перенеслось на апрель.

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

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

Ford Motor: уникальное сочетание оперативности и качества

Дон Уэлс

Команда: 17 человек, из них 12 программистов

Приложение: система анализа затрат

Срок реализации: 6 лет

Отдел финансовых систем компании Ford Motor разрабатывает аналитическую систему Vehicle Costing and Profit System (VCAPS), которая создает отчеты по доходам от производства, расходам, чистому доходу и прибыли. Входными данными для системы являются инженерные спецификации продукции, фиксированные затраты и расходы и переменные затраты, например, рабочие часы. VCAPS аккумулирует все эти данные и подготавливает подробные отчеты с анализом затрат, которые обеспечивают эффективное прогнозирование и принятие корпоративных решений. Работа над проектом VCAPS была начата в 1993 году. При разработке использовались VisualWorks и GemStone Smalltalk. В данный момент поддержкой системы VCAPS занимается небольшая группа специалистов, и в скором времени она будет заменена более современным приложением.

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

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

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

Дальше мы сделали несколько модульных тестов и уже через год 40% системы было протестировано, а руководство отметило сокращение числа сообщений об ошибках на 40%. После этого на ХР обратили пристальное внимание.

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

Через полтора года количество системных сбоев снизилось настолько, что наши заказчики и руководство смогли констатировать значительно более высокую стабильность системы. Для нас это символизировало успех принципов ХР.

Tariff System: тесты, которые можно читать

Роб Ми

Команда: три разработчика

Приложение: система вычисления тарифов на перевозки

Срок реализации: 3 месяца

Tariff System - часть большого проекта, реализованного с помощью SmallTalk/GemStone в одной из крупных международных компаний, специализирующихся на контейнерных перевозках. Подход ХР позволил за три месяца силами трех человек пройти все этапы разработки этой подсистемы, от замысла до ввода в эксплуатацию. Результат оказался замечательно стабильным и простым в сопровождении.

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

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

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