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

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

Чтобы вы не терялись и не путались, рассказываем, что такое экстремальное программирование и почему экстремальное управление — не методология.

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

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

Термин «экстремальное управление проектами» придумал эксперт по менеджменту Дуг ДеКарло в 2004 году. На самом деле он просто собрал опыт разных компаний, проанализировал, выделил самое лучшее и получил авторский метод менеджмента. Весь процесс управления по ДеКарло основан на принципах экстремального программирования (Extreme Programming).

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

Главная особенность XP — методология применима только в сфере разработки программного обеспечения. Ее не использовать там, где нет никакого digital-продукта.

Ценности и практики экстремального программирования

XP — это agile-методология, но она опирается на свои ценности.

Основные ценности XP

Упрощение кода и процесса работы.

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

Постоянно общаться с заказчиком и следить за изменениями требований.

Не бояться рисковать и использовать новые непроверенные практики.

Уважать себя, коллег, правила и цели проекта.

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

Основные практики

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

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

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

Разработка через тестирование

Подготовка к тестированию начинается еще до начала написания кода. Программист сначала пишет тесты и только потом — код.

Свободный доступ к коду

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

Единое оформление кода

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

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

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

Общее видение системы

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

Никаких переработок

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

Как работает команда

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

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

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

Как применить идеи экстремального программирования в управлении

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

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

XP — только одна из гибких методологий, принципы которых активно используют в управлении проектами. Она не так популярна, как, например, Scrum. Только небольшой процент команд использует весь комплекс практик XP в работе над проектом. Чаще выбирают одну или несколько, которые больше всего подходят и могут реально упростить процесс.

Заключение

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

Унифицированный процесс разработки и экстремальное программирование

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

Экстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционный метод разработки ПО «снизу вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method) . В группу «живых» методов входят, помимо экстремального программирования , методы SCRUM, DSDM ( Dynamic Systems Development Method , метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

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

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

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

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

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

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).

• Живое планирование (planning game)

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

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

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

В каждый момент времени система должна быть сконструирована настолько просто, насколько это возможно. Не надо добавлять функции заранее — только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

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

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

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

В любой момент любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности, вся команда в целом отвечает за весь код.

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

Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

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

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

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

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

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

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

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

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System , разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики [6,7,8]. Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.

Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.

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

extreme Programming (ХР) — это еще одна гибкая методика разработки программного обеспечения, позволяющая команде (разработчикам, пользователям и руководителям проекта) быстро адаптировать продукт к изменяющимся требованиям. Методика ХР имеет следующие достоинства:

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

Для создания ХР его автор Kent Beck исходил из следующих соображений [7].

Если в классических методиках считается, что тестирование — это хорошо, то тестировать следует все, что можно, и при этом непрерывно.

Если полезно проектирование системы, то анализ и синтез структуры продукта будут выполняться ежедневно.

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

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

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

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

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

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

Рассмотрим теперь более подробно принципы ХР, которые определяют его достоинства.

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

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

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

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

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

Такой подход, основанный на выборе приоритетов, гарантирует, что разработчик всегда занимается самой приоритетной задачей по проекту, что облегчает быстрое завершение итерации. Для заказчика такое планирование также удобно: он практически безболезненно для хода проекта может изменять требования к системе (что-то улучшить, что-то поменять и что-то вообще выбросить из системы). Итерацией в ХР называется фаза разработки, в результате которой создается рабочая версия проекта (релиза).

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

Если команда разработчиков делает продукт долго и без связи с заказчиком, то такая ситуация считается большим риском — наверняка делается то, что не надо, или не так, как надо. Рекомендуется выпуск релизов не реже раза в 1—2 недели.

Непрерывная интеграция. Сборка продукта выполняется много раз в день. Такой подход снимает множество проблем, связанных со стыковкой модулей, разработанных разными программистами, а также позволяет избежать ситуации, когда новая функциональность оказывается несовместимой с остальным проектом. Для сведения к минимуму риска нежелательных последствий интеграции рекомендуется выполнять ее на отдельном компьютере парой программистов.

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

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

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

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

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

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

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

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

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

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

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

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

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

«Нетология» запускает новую программу обучения — «Экстремальное программирование: пишем код, за который не стыдно». Сегодня объясняем, что это такое и кому пригодится.

Почему экстремальное?

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

А мне Agile больше нравится!

Agile, Scrum — это методологии построения процессов. Они помогают организовать работу, но не влияют на прямую на код. Agile подходит не только программистам — по этим методикам успешно работают даже маркетологи. Экстремальное программирование — это о том, как писать код, строить архитектуру, то есть про инженерную часть. Agile рассказывает, как руководить проектом гибко. А экстремальное программирование — как разработчику соответствовать Agile-подходам.

Кто это вообще придумал?

Программист Кент Бек, ныне работающий в Facebook, в 1999 году выпустил книгу «Extreme Programming Explained: Embrace Change». Именно из неё и появилось экстремальное программирование.

Ну ок. А подробнее?

В основе XP лежат ценности, принципы и практики.

Главные ценности XP:

Общение — программисты сидят рядом и постоянно обсуждают детали проекта. Или сидят не рядом, но всегда на связи.

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

Кураж — не ныть, а постоянно делать шаги к улучшению. Лучше сделать одно улучшение сегодня, чем весь день планировать работу на неделю.

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

И какие практики предлагают?

Расскажем о нескольких.

«Сидите вместе». Кодеры сидят рядом. Если у одного возник вопрос, он может в буквальном смысле подкатиться к коллеге и обсудить гипотезу. Суть — общаться экстремально часто.

Парное программирование. Два программиста, один компьютер, две клавиатуры, одна программа. Сначала один пишет код, а второй следит. Если что-то пошло не так, бьёт коллегу по рукам и сразу исправляет. Через 15 минут — смена. Плюс в том, что во время перерыва ты продолжаешь работать — пока коллега вбивает код, сложно отвлечься на Facebook или трёп у кулера. За полтора часа два программиста сделают меньше кода, чем поодиночке, но качество выйдет выше.

Непрерывная интеграция. Делать упор на автоматизацию и интегрировать изменения постоянно. Что-то сделали — внедрили. Ещё — внедрили.

Разработка test-first. Сначала пишем тест, а потом код, который делает тест «зелёным», то есть успешно пройденным.

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

А для какого языка программирования подходит XP?

Для любого. Главное, чтобы кодеры понимали друг друга.

Звучит как какая-то программистская религия.

Это не так. XP — набор практик. Не нужно применять их все одновременно, программист выбирает удобные и внедряет. Это значит, что если кодер один, то парное программирование ему, конечно, не подойдёт, а вот test-first вполне.

Ключевые навыки, которые вы сможете добавить в резюме после обучения:

Понятие экстремального программирования (ХР)

Экстремальное программирование (eXtreme Programming, XP) — облегченный (подвижный) процесс (или методология), главный автор которого — Кент Бек (1999). ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим структуру «идеального» ХР-процесса. Основным структурным элементом процесса является ХР-реализация, в которую многократно вкладывается базовый элемент — ХР-итерация. В состав ХР-реализации и ХР-итерации входят три фазы — исследование, блокировка, регулирование. Исследование (exploration) — это поиск новых требований (историй, задач), которые должна выполнять система. Блокировка (commitment) — выбор для реализации конкретного подмножества из всех возможных требований (иными словами, планирование). Регулирование (steering) — проведение разработки, воплощение плана в жизнь.

Основным структурным элементом ХР-процесса является ХР-реализация. Рассмотрим ее организацию.