Extreme Programming

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

Когда применимо XP

Обстоятельства, когда XP подходит, описал Дон Уэллс на www.extremeprogramming.org:

• Изменяющиеся требования к ПО
• Риски от проектов с новой технологией и фиксированным временем
• Маленькая команда разработки в одном месте
• Используемая технология позволяет автоматизированные модульные и функциональные тесты

Из-за специфичности XP по инженерным практикам, есть ситуации, когда XP не подходит. Статья «Когда не подходит XP» на C2 Wiki — хорошее место для примеров.

Нельзя использовать весь процесс XP везде, рекомендуем использовать отдельные практики в своей практике.

Ценности

Пять ценностей XP: коммуникация, простота, обратная связь, смелость и уважение, описаны далее.

Коммуникация

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

Простота

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

Обратная связь

Через постоянную обратную связь команда улучшает свои практики. Обратная связь поддерживает простой дизайн. Команда создает что-то, получает обратную связь по дизайну и реализации, и корректирует продукт.

Смелость

Смелость — «эффективные действия в страхе» (Extreme Programming Explained P. 20). Смелость требуется для решения организационных проблем и изменений. Смелость — принять обратную связь, даже если это сложно.

Уважение

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

Практическое использование

Ядро Extreme Programming — взаимосвязанный набор практик разработки ПО, перечисленных ниже. Хотя эти практики можно выполнять изолированно, многие команды нашли, что некоторые практики укрепляют другие и следует делать их вместе, чтобы полностью устранить риски, с которыми часто сталкиваются при разработке ПО.

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

• Игра в планирование
• Маленькие релизы
• Метафоричность
• Простой дизайн
• Тестирование
• Рефакторинг
• Парное программирование
• Коллективная собственность
• Постоянная интеграция
• 40-часовая неделя
• Доступность заказчика
• Стандарт кодирования

Ниже приведены описания практик, как они описаны во втором издании «Extreme Programming Explained Embrace Change». Эти описания включают уточнения, основанные на опыте многих, кто практикует экстремальное программирование, и представляют более практичный набор практик.

Находиться вместе в одном месте

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

Вовлеченность всей команды

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

Информативное рабочее пространство

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

Энергичная работа

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

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

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

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

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

Истории

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

Недельный цикл

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

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

Квартальный цикл

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

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

Люфт

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

Десятиминутная сборка

Цель Десятиминутной сборки — автоматически создавать всю систему и запускать все тесты за десять минут. Основатели XP предложили 10-минутный временной интервал, потому что если у команды сборка занимает больше времени, ее менее вероятно запускать часто, что влечет за собой более длительные интервалы между ошибками.

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

Эта практика поддерживает практику непрерывной интеграции и поддерживается практикой Тестирования Сначала.

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

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

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

Практики XP предполагают «если болит, делайте это чаще».

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

Эта практика требует дополнительной дисциплины и в высшей степени зависит от Десятиминутной сборки и Тестирования Сначала.

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

Вместо того чтобы следовать распространенному пути:

разрабатывать код -> писать тесты -> запускать тесты

Практика XP: сначала тестирование:

Написать тест, который не проходит -> запустить тест, который не проходит -> разработать код, чтобы пройти тест -> запустить тест -> повторить

Как и с непрерывной интеграцией, test-driven development сокращает цикл обратной связи для разработчиков для выявления и устранения проблем, тем самым уменьшая количество ошибок, которые появляются в производстве.

Инкрементальный дизайн

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

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

Роли

В хотя Extreme Programming предписывает конкретные паттерны для команды. Однако, практика не устанавливает конкретные роли для людей в вашей команде.

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

Заказчик

Заказчик отвечает за все бизнес-решения, касающиеся проекта, включая:

• Что должна делать система (какие функции включены и что они достигают)?
• Как мы узнаем, что система готова (какие у нас критерии приемки)?
• Сколько у нас есть денег (какие доступны финансирование и деловое обоснование)?
• Что мы должны сделать дальше (в каком порядке мы доставим эти функции)?

Ожидается, что XP заказчик активно участвует в проекте и, в идеале, становится частью команды.

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

Разработчик

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

Трекер

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

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

Коуч

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

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

Жизненный цикл

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

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

Происхождение

XP впервые была использована в программе Comprehensive Compensation (C3) компании Chrysler, которая была начата в середине 90-х годов и перешла в проект XP, когда Кент Бек был привлечен к проекту для улучшения производительности системы. Он добавил еще несколько людей, включая Рона Джеффриса, в команду и изменил способ подхода команды к разработке. Этот проект помог сфокусировать методологию XP, а несколько книг, написанных людьми, участвовавшими в проекте, способствовали распространению знаний о данном подходе и его принятию.

Значение

Основным вкладом Extreme Programming в мир разработки программного обеспечения является взаимозависимая коллекция инженерных практик. Команды могут использовать best practice для повышения эффективности и создания кода более высокого качества. Многие команды, переходящие на гибкие методы, начинают с другой структуры. На следующих этапах они выявляют потребность в более дисциплинированных инженерных практиках. Внедряются другие практики, рекомендованные XP.

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