Экстремальное программирование: Экстремальное программирование (XP) не для слабонервных

как не путаться в терминах — статьи на Skillbox

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

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

Источник

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

Особенности экстремального программирования и менеджмента

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

В основе экстремального программирования — agile-манифест.

И принципы Agile.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема работы Scrum и Kanban. Источник

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

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

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

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

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

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

Курс «Управление Digital-проектами»

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

• 
  Живая обратная связь с преподавателями
• 
  Неограниченный доступ к материалам курса
• 
  Стажировка в компаниях-партнёрах
• 
  Дипломный проект от реального заказчика
• 
  Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Методики и принципы экстремального программирования / Хабр

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

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

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

План релизов

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

Планирование итераций

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

Собрание стоя

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

Простота

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

Система метафор

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

Заказчик на рабочей площадке

Основной проблемой разработки программного обеспечения является недостаток знаний программистов в разрабатываемой предметной области. Экстремальное программирование нашло выход и из этой ситуации. Нет, это не стажировка разработчика на предприятии заказчика — он тогда не захочет программировать. Наоборот, это участие заказчика в процессе разработки.
Разве может программист, досконально не понимая суть вопроса и не будучи телепатом, угадать, чего хочет заказчик? Ответ очевиден. Самым простым способом преодолеть такое неудобство — а экстремальное программирование учит нас находить самые простые решения — будет задать заказчику прямой вопрос. Более строгие подходы требуют всеобъемлющего предварительного анализа разрабатываемой области. В определенных случаях это оправдано, хотя и дороже обходится. Реальный опыт ведения приземленных проектов показывает, что невозможно собрать все требования заранее. Более того, даже если предположить, что все требования на текущий момент собраны, все равно останется одно узкое место: программы, как и все в природе, не создаются мгновенно, а тем временем бизнес-процессы могут поменяться. Это следует учитывать.
Многие сомневаются в возможности привлечения заказчика к процессу разработки. Действительно, заказчики бывают разные. Если привлечь заказчика или его представителя не удается, иногда оказывается целесообразным временный наем специалиста в разрабатываемой области. Такой шаг сократит неясности в работе, повысит скорость разработки и приблизит проект к тому, что желает получить заказчик. Это может быть выгодно и с финансовой стороны: ведь оплата труда программиста порой значительно превышает оклад специалистов других отраслей.
User Story. User Story (что-то типа рассказа пользователя) — это описание того как система должна работать. Каждая User Story написана на карточке и представляет какой-то кусок функциональности системы, имеющий логический смысл с точки зрения Заказчика. Форма один-два абзаца текста понятного пользователю (не сильно технического).
User Story пишется Заказчиком. Они похожи на сценарии использования системы, но не ограничиваются пользовательским интерфейсом. По каждой истории пишутся функциональные тесты, подтверждающие что данная история корректно реализована — их еще называют приемочными (Acceptance tests).

Тестирование до начала разработки

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

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

Весь код для продукционной системы пишется парами. Два разработчика сидят рядом. Один набирает, другой смотрит. Время от времени они меняются. Не разрешается работать в одиночку. Если по какой-то причине второй из пары пропустил что-то (болел, отходил и т.п.) он обязан просмотреть все изменения сделанные первым.
Звучит необычно, но после небольшого периода адаптации большинство людей прекрасно работают в парах. Им даже нравится, поскольку работа делается заметно быстрее. Действует принцип «Одна голова хорошо, а две лучше». Пары обычно находят более оптимальные решения. Кроме того, существенно увеличивается качество кода, уменьшается число ошибок и ускоряется обмен знаниями между разработчиками. Пока один человек сосредоточивает усилия на стратегическом представлении об объекте, второй реализует его свойства и методы.

Смена позиций

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

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

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

Соглашение о кодировании

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

Частая интеграция

Разработчики, по-возможности, должны интегрировать и выпускать свой код каждые несколько часов. В любом случае никогда нельзя держать изменения дольше одного дня. Частая интеграция позволяет избежать отчуждения и фрагментирования в разработке, когда разработчики не могут общаться в смысле обмена идеями или повторного использования кода. Каждый должен работать с самой последней версией.
Каждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность. Это может быть, когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция — это деятельность вида «заплати сейчас или заплати больше позднее». Поэтому, интегрируя изменения ежедневно маленькими порциями, вы не окажетесь перед необходимостью тратить неделю, чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы.

Сорокачасовая рабочая неделя

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

Заключение

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

Список используемой литературы:

• Wikipedia
• Экстремальное программирование / К. Ауэр, Р. Миллер — СПб.: Питер, 2004. – 368 с.: ил.

Что такое экстремальное программирование | Медиа Нетологии: образовательная платформа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

XP (Extreme Programming) — QA evolution

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

XP (Extreme Programming)

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

XP (Extreme Programming)

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

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

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

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

— Игра в планирование (Planning game) —  быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими

— Заказчик всегда рядом (Whole team, Onsite customer) — XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

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

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

— Непрерывная интеграция (Continuous integration) —  В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.

— Рефакторинг (Design improvement, Refactoring) — XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.

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

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

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

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

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

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

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

— Стандарт кодирования (Coding standard or Coding conventions) — в рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды.

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

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

Читать про все методологии разработки

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

Экстремальное программирование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода, 

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

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

• Короткий цикл обратной связи (Fine-scale feedback)
  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game)
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming)
  • Непрерывный, а не пакетный процесс

• Непрерывная интеграция (Continuous integration)
  • Рефакторинг (Design improvement, Refactoring) 
  • Частые небольшие релизы (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 предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:

• юнит-тестирование модулей;
• функциональное тестирование.

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

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

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

нередко имеет больший приоритет, чем написание юнит-тестов.

Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development — разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл. TDD, в некотором смысле, позволяет писать код, более удобный в использовании — потому что при написании теста, когда логики ещё нет, 

проще всего позаботиться об удобстве будущей системы.

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

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

Экстремальное программирование | Открытые системы. СУБД

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

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

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

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

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

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

Анатомия XP

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

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

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

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

Истории

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

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

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

Версия

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

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

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

Итерация

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

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

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

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

Задача

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

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

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

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

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

Тест

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кент Бек ([email protected]) — сотрудник консультативной компании First Class Software, автор книг и 50 статей по экстремальному программированию, в частности «Extreme Programming Explained: Embrace Change» (Addison Wesley Logman, Reading, Mass., 2000).

Литература

1. J.Wood and D.Silver, Joint Applicatopn Development, John Wiley & Sons, New York, 1995.
2. J.Martin, Rapid Application Development, Prentice Hall, Upper Saddle River, N.J., 1992.
3. J.Stapleton, Dynamic Systems Development Method, Addison Wesley Longman, Reading, Mass., 1997.
4. C.Alexander, The Timeless Way of Building, Oxford University Press, New York, 1979.
5. H.Takeuchi and I.Nonaka, @The New Product Development Game@, Harvard Business Rev., Jan./Feb. 1986, pp.137-146.
6. W.Cunningham, «Episodes: A Pattern Language of Competitive Development@, Pattern Languags of program Design 2, J.Vlissides, ed., Addison-Wesley, New York, 1996.
7. I.Jacobsen, Object-Oriented Software Engineering, Addison-Wesley, New York, 1994.
8. T. Gilb, Principles of Software Engineering Management, Addison-Wesley, Wokngham, UK, 1988.
9. B.Boehm, «A Spiral Model of Software Development and Enhancement», Computer, May 1988, pp.61-72.
10. D.Thomas, «Web Time Software Development», Software Development, Oct. 1998, p.80.
11. G.Lakoff and M.Johnson, Philosophy in the Flesh, Basic Books, New York, 1998.
12. R.Coyne, Designing Information Technology in the Postmodern Age, MIT Press, Cambridge, Mass., 1995.
13. J.O.Coplien, «A Generative Development Process Pattern Language», The Patterns Handbook, L.Rising, ed., Camridge University Press, New York, 1998, pp.243-300.
14. T.DeMarco and T.Lister, Peopleware, DorsetHouse, New York, 1999.
15. S. Prowell et al., Cleanroom Software Engineering. Addison Wesley Logman, Reading, Mass., 1999.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Корни ХР

Сами по себе методы ХР не являются чем-то принципиально новым. Многие приходили к сходным заключениям, пытаясь найти лучшие способы разработки программного обеспечения в среде с постоянно изменяющимися требованиями [1-3].

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

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

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

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

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

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

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

Примеры выполнения проектов с использованием 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 в одной из крупных международных компаний, специализирующихся на контейнерных перевозках. Подход ХР позволил за три месяца силами трех человек пройти все этапы разработки этой подсистемы, от замысла до ввода в эксплуатацию. Результат оказался замечательно стабильным и простым в сопровождении.

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

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

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

Embracing Change with Extreme Programming, Kent Beck. Computer, October, 1999, pp. 70-77, Reprinted with permission, Copyright IEEE, 1999, All rights reserved.

Поделитесь материалом с коллегами и друзьями

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

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

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

Экстремальное программирование (XP) основано на пяти значениях —

связь

Простота

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

бодрость

уважение

связь

Коммуникация играет важную роль в успехе проекта. Проблемы с проектами часто возникают из-за отсутствия связи. Многие обстоятельства могут привести к сбою в общении. Некоторые из общих проблем —

• Разработчик не может сказать кому-либо еще о критических изменениях в дизайне.

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

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

• Разработчик может игнорировать что-то важное, переданное клиентом.

Разработчик не может сказать кому-либо еще о критических изменениях в дизайне.

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

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

Разработчик может игнорировать что-то важное, переданное клиентом.

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

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

Простота

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

• Делай то, что нужно и просишь, но не более.

  • «Делай самое простое, что могло бы сработать». Принцип DTSTTCPW.

  • Реализуйте новые возможности самым простым способом. Также известный как принцип KISS «Делай это просто, глупый!».

  • Тренер может сказать DTSTTCPW, когда видит, как разработчик экстремального программирования делает что-то излишне сложное.

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

• Сделайте небольшие простые шаги к своей цели и устраните сбои по мере их возникновения.

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

• Никогда не применяйте функцию, которая вам не нужна сейчас, то есть принцип «Вы не будете нуждаться в этом» (YAGNI).

Делай то, что нужно и просишь, но не более.

«Делай самое простое, что могло бы сработать». Принцип DTSTTCPW.

Реализуйте новые возможности самым простым способом. Также известный как принцип KISS «Делай это просто, глупый!».

Тренер может сказать DTSTTCPW, когда видит, как разработчик экстремального программирования делает что-то излишне сложное.

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

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

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

Никогда не применяйте функцию, которая вам не нужна сейчас, то есть принцип «Вы не будете нуждаться в этом» (YAGNI).

Общение и простота поддерживают друг друга.

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

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

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

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

В экстремальном программировании обратная связь обеспечивается на всех уровнях в разных временных масштабах —

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

• Модульные тесты сообщают разработчикам о состоянии системы.

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

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

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

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

Модульные тесты сообщают разработчикам о состоянии системы.

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

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

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

Таким образом, в Extreme Programming обратная связь —

• Работает как катализатор перемен

• Указывает на прогресс

• Дает разработчикам уверенность, что они на правильном пути

Работает как катализатор перемен

Указывает на прогресс

Дает разработчикам уверенность, что они на правильном пути

бодрость

Экстремальное программирование дает смелость разработчикам следующим образом —

• Сосредоточиться только на том, что требуется

• Чтобы общаться и принимать отзывы

• Говорить правду о прогрессе и оценках

• Рефакторинг кода

• Чтобы адаптироваться к изменениям, когда они происходят

• Выбросить код (прототипы)

Сосредоточиться только на том, что требуется

Чтобы общаться и принимать отзывы

Говорить правду о прогрессе и оценках

Рефакторинг кода

Чтобы адаптироваться к изменениям, когда они происходят

Выбросить код (прототипы)

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

уважение

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

• Все уважают друг друга как ценный член команды.

• Каждый вносит свой вклад, например, в энтузиазм.

• Разработчики уважают опыт клиентов и наоборот.

• Руководство уважает право разработчиков принять ответственность и получить власть над своей работой.

Все уважают друг друга как ценный член команды.

Каждый вносит свой вклад, например, в энтузиазм.

Разработчики уважают опыт клиентов и наоборот.

Руководство уважает право разработчиков принять ответственность и получить власть над своей работой.

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

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

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

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

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

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

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

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

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

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

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

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

Основополагающими принципами экстремального программирования являются —

• Быстрая обратная связь

• Примите простоту

• Постепенное изменение

• Принимая изменения

• Качественная работа

Быстрая обратная связь

Примите простоту

Постепенное изменение

Принимая изменения

Качественная работа

Быстрая обратная связь

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

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

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

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

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

Примите простоту

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

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

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

• С хорошими модульными тестами вы можете легко реорганизовать свой код для проведения дополнительных тестов.

• Следуйте за ЯГНИ (Вам это не нужно).

• Следуйте принципу СУХОЙ (не повторяйте себя). Например,

  • Не имейте несколько копий идентичного (или очень похожего) кода.

  • Не иметь избыточных копий информации.

  • Никаких потерь времени и ресурсов на то, что может и не понадобиться.

С хорошими модульными тестами вы можете легко реорганизовать свой код для проведения дополнительных тестов.

Следуйте за ЯГНИ (Вам это не нужно).

Следуйте принципу СУХОЙ (не повторяйте себя). Например,

Не имейте несколько копий идентичного (или очень похожего) кода.

Не иметь избыточных копий информации.

Никаких потерь времени и ресурсов на то, что может и не понадобиться.

Постепенное изменение

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

В экстремальном программировании пошаговое изменение применяется многими способами.

• Дизайн меняется немного за один раз.

• План меняется немного за один раз.

• Команда меняется немного за один раз.

Дизайн меняется немного за один раз.

План меняется немного за один раз.

Команда меняется немного за один раз.

Даже принятие экстремального программирования должно быть сделано в несколько шагов.

Охватывая изменения

Лучшая стратегия — это та, которая сохраняет большинство вариантов, в то же время фактически решая вашу самую насущную проблему.

Качественная работа

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

Работает хорошо

Наслаждается работой

Чувствует себя хорошо в производстве ценного продукта

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

Определение

Extreme Programming (XP) — это гибкая среда разработки программного обеспечения, которая направлена ​​на создание более качественного программного обеспечения и повышение качества жизни команды разработчиков. XP является наиболее специфической из гибких структур в отношении подходящих инженерных практик для разработки программного обеспечения.

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

Общие характеристики, в которых подходит XP, были описаны Доном Уэллсом на сайте www.extremeprogramming.org:

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

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

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

Значения

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

Связь

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

Простота

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

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

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

Мужество

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

Респект

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

Практики

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

Практики опыта немного изменились с момента их появления. Первоначальные двенадцать практик перечислены ниже. Если вам нужна дополнительная информация о том, как изначально были описаны эти методы, вы можете посетить http: // ronjeffries.com / xprog / what-is-extreme-programming /.

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

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

Сидеть вместе

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

Вся команда

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

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

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

Работа под напряжением

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

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

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

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

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

Рассказов

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

Еженедельный цикл

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

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

Ежеквартальный цикл

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

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

Slack

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

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

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

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

Эта практика поддерживает практику непрерывной интеграции и поддерживается практикой Test First Development.

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

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

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

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

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

Эта практика требует дополнительной дисциплины и сильно зависит от Ten Minute Build и Test First Development.

Тестовое программирование

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

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

Практика программирования Test-First следует по пути:

Написать неудачный автоматический тест -> Запустить неудачный тест -> разработать код для прохождения теста -> запустить тест -> повторить

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

Инкрементальное проектирование

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

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

Роли

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

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

Заказчик

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

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

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

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

Разработчик

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

Следопыт

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

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

Тренер

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

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

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

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

Истоки

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

Первичные взносы

Основной вклад

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

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

Дополнительная литература

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

Время чтения: около 6 минут

Автор: Lucid Content Team

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

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

Хотя вы можете узнать некоторые из этих практик и ценностей из других методологий управления проектами, XP доводит эти практики до «экстремальных» уровней, как следует из названия методологии.В интервью Informit Кент объясняет:

«Когда меня впервые попросили возглавить команду, я попросил их сделать кое-что из того, что я считаю разумным, например, тестирование и обзоры. Во второй раз на кону было гораздо больше. Я … попросил команду поднять все до 10 пунктов на том, что я считаю важным, и исключить все остальное ».

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

Обзор экстремального программирования (XP) (Щелкните изображение, чтобы изменить его в Интернете)

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

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

Простота

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

Оптимизированная коммуникация

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

Последовательная, конструктивная обратная связь

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

Уважение

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

Смелость

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

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

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

Экстремальная обратная связь по программированию / Циклы планирования (Щелкните изображение, чтобы изменить онлайн)

1. Планирование

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

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

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

2. Управление

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

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

3. Проектирование

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

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

Модель Class-Responsibility-Collaborator (CRC) (Щелкните изображение, чтобы изменить в Интернете)

4. Кодирование

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

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

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

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

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

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

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

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

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

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

Экстремальное программирование (XP): ценности, принципы и практика

Время чтения: 12 минут

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

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

Extreme Programming (XP) — одна из многочисленных гибких структур, применяемых ИТ-компаниями.Но его ключевая особенность — упор на технические аспекты разработки программного обеспечения — отличает XP от других подходов.

Инженер-программист Кен Бек представил XP в 90-х годах с целью найти способы быстро писать высококачественное программное обеспечение и иметь возможность адаптироваться к меняющимся требованиям клиентов. В 1999 году он усовершенствовал подходы к XP в книге Extreme Programming Explained: Embrace Change .

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

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

Фреймворк XP обычно включает 5 этапов или этапов процесса разработки, которые повторяются непрерывно:

1. Планирование, первый этап, когда заказчик встречает команду разработчиков и представляет требования в форме пользовательских историй для описания желаемого результата.Затем команда оценивает истории и создает план выпуска, разбитый на итерации, необходимые для охвата требуемой функциональности часть за частью. Если одна или несколько историй не могут быть оценены, могут быть введены так называемые всплески , что означает, что необходимы дальнейшие исследования.
2. Проектирование на самом деле является частью процесса планирования, но его можно выделить отдельно, чтобы подчеркнуть его важность. Это связано с одной из основных ценностей XP, о которой мы поговорим ниже, — простотой.Хороший дизайн привносит в систему логику и структуру и позволяет избежать ненужных сложностей и дублирования.
3. Кодирование — это этап, на котором создается фактический код путем реализации определенных практик XP, таких как стандарты кодирования, парное программирование, непрерывная интеграция и коллективное владение кодом (весь список описан ниже).
4. Тестирование — это ядро ​​экстремального программирования. Это регулярная деятельность, которая включает как модульные тесты (автоматическое тестирование, чтобы определить, правильно ли работает разработанная функция), так и приемочные тесты (тестирование заказчиком для проверки того, что вся система создана в соответствии с первоначальными требованиями).
5. Слушание — это постоянное общение и обратная связь. Заказчики и менеджеры проектов участвуют в описании бизнес-логики и ожидаемой ценности.

Кратко о жизненном цикле XP

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

.

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

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

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

Ценности и принципы XP

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

XP имеет простые правила, основанные на 5 значениях, которые определяют командную работу:

1. Связь. Каждый член команды работает совместно на каждом этапе проекта.
2. Простота. Разработчики стремятся писать простой код, повышающий ценность продукта, поскольку он экономит время и усилия.
3. Обратная связь. Члены команды часто поставляют программное обеспечение, получают отзывы о нем и улучшают продукт в соответствии с новыми требованиями.
4. Респект. Каждый человек, участвующий в проекте, вносит свой вклад в общую цель.
5. Мужество. Программисты объективно оценивают собственные результаты, не оправдываясь и всегда готовы отреагировать на изменения.

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

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

Большинство исследователей обозначают 5 принципов опыта как:

1. Быстрая обратная связь. Члены команды понимают данную обратную связь и сразу же на нее реагируют.
2. Предполагаемая простота. Разработчики должны сосредоточиться на работе, которая важна в данный момент, и следовать принципам YAGNI (Вам это не понадобится) и DRY (Don’t Repeat Yourself).
3. Инкрементальные изменения. Небольшие изменения, внесенные в продукт постепенно, работают лучше, чем крупные, внесенные сразу.
4. Принятие перемен. Если клиент считает, что продукт необходимо изменить, программисты должны поддержать это решение и спланировать, как реализовать новые требования.
5. Качественная работа. Команда, которая хорошо работает, производит ценный продукт и гордится им.

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

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

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

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

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

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

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

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

Заказчик на месте

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

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

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

Рефакторинг кода

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

Парное программирование в итерационном цикле XP, источник: extremeprogramming.org

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

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

Малые релизы

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

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

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

Практики

XP подчеркивают, что шансы упростить конструкцию возрастают после того, как продукт находится в производстве в течение некоторого времени. Дон Уэллс советует писать код для тех функций, которые вы планируете реализовать сразу, а не писать его заранее для других будущих функций: «Лучший подход — создать код только для тех функций, которые вы реализуете, пока вы ищете достаточно знаний, чтобы выявить простейшие». дизайн. Затем постепенно реорганизуйте его, чтобы реализовать свое новое понимание и дизайн.”

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

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

Коллективный код собственности

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

Системная метафора

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

40-часовая неделя

Проекты

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

Преимущества и недостатки XP

Практика

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

XP в двух словах о плюсах и минусах

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

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

• Непрерывное тестирование и рефакторинг помогают создать стабильных и хорошо работающих систем с минимальной отладкой;

Значение

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

Крайние недостатки программирования

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

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

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

Сравнение XP с другими фреймворками

Как мы упоминали выше, XP является частью гибкой методологии. Он разделяет основные принципы гибкой разработки, то есть частые выпуски, короткие циклы разработки, постоянное общение с заказчиком, кросс-функциональные команды и т. Д. По этой причине XP часто путают с другими популярными фреймворками Agile, такими как Scrum, Kanban и Lean.Ознакомьтесь с нашим подробным техническим описанием, чтобы получить более подробную информацию, или инфографикой, чтобы получить краткое описание основных гибких методов. Здесь мы кратко сравним их и посмотрим, в чем заключаются основные различия.

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

XP против Scrum, Kanban и Lean в двух словах

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

Scrum обычно ассоциируется с самоорганизующимися командами. Также обычно есть спринты продолжительностью от 2 до 4 недель, в то время как итерации XP короче — от 1 до 2 недель. Кроме того, XP гораздо более гибок с возможными изменениями в итерациях, в то время как Scrum не позволяет вносить какие-либо изменения после того, как задан бэклог спринта. Другое отличие состоит в том, что в XP заказчик расставляет приоритеты по функциям и решает порядок их разработки, но в Scrum команда сама определяет, над чем работать в первую очередь.

Основные роли

Scrum — это владелец продукта, мастер Scrum и команда Scrum, которые отличаются от ролей в XP.

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

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

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

Роли в Канбан не определены строго.

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

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

Когда использовать XP

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

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

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

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

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

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

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

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

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

Extreme Programming — это методология разработки программного обеспечения, предназначенная для улучшения качества программного обеспечения и его способности правильно адаптироваться к меняющимся потребностям заказчика или клиента.В середине и конце девяностых, работая над Комплексной системой компенсации Chrysler (C3), помогающей управлять платежной ведомостью компании, инженер-программист Кен Бек впервые разработал методологию экстремального программирования. В октябре 1999 года он опубликовал Extreme Programming Explained , в котором подробно описал весь метод для других, и вскоре после этого был запущен официальный веб-сайт.

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

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

Некоторые более конкретные варианты SDLC включают:

Экстремальные значения

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

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

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

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

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

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

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

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

Планирование

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

Управляющий

• Предоставьте команде отдельное открытое рабочее пространство.
• Установите устойчивый темп.
• Ежедневно начинается стоячая встреча.
• Скорость проекта измерена.
• Перемещать людей.
• Fix Extreme Programming, когда он ломается.

Проектирование

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

Кодирование

• Заказчик всегда на связи.

Код

• должен быть написан в соответствии с согласованными стандартами.
• Сначала выполните модульный тест.
• Весь производственный код запрограммирован парно.
• Только одна пара интегрирует код за раз.
• Часто интегрируйтесь.
• Настройте специальный компьютер для интеграции.
• Использовать коллективную собственность.

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

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

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

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

Точная обратная связь

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

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

Планирование игры

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

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

• Этап исследования: карточки историй используются для детализации наиболее ценных требований клиентов.

Фаза принятия обязательств

• : Планирование и обязательства команды выполняются для удовлетворения потребностей следующего выпуска расписания и выполнения его вовремя.

Фаза управления

• : это позволяет скорректировать ранее разработанные планы в соответствии с меняющимися потребностями проекта, подобно многим другим методологиям Agile Model.

После планирования выпуска также находится раздел «Планирование итераций», который состоит из тех же трех собственных подэтапов, но с вариантами их реализации:

• Этап разведки: все требования к проекту записаны.

Фаза принятия обязательств

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

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

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

Вся команда

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

Непрерывный процесс

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

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

Рефакторинг кода

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

Мелкие выпуски

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

Общее понимание

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

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

Коллективный код собственности

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

Простая конструкция

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

Системная метафора

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

Благополучие программистов

Устойчивый темп

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

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

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

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

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

Команды

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

Программисты

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

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

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

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

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

Вся команда

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

Планирование игры

Планирование

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

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

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

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

Тесты клиентов

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

Лучшие команды XP относятся к своим пользовательским тестам так же, как и к тестам программистов: как только тест запускается, команда поддерживает его правильное выполнение после этого.Это означает, что система только улучшается, всегда идет вперед, а не откатывается назад.

Малые релизы

Команды

XP практикуют небольшие выпуски двумя важными способами:

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

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

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

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

Команды

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

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

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

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

Может показаться неэффективным, когда два программиста выполняют «работу одного программиста», но верно и обратное.Исследования парного программирования показывают, что парное программирование дает лучший код примерно за то же время, что и программисты, работающие поодиночке. Правильно: две головы действительно лучше, чем одна!

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

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

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

Extreme Programming одержим обратной связью, а при разработке программного обеспечения хорошая обратная связь требует хорошего тестирования. Лучшие команды XP практикуют «разработку через тестирование», работая в очень коротких циклах, добавляя тест, а затем заставляя его работать.Практически без усилий команды создают код с почти 100-процентным тестовым покрытием, что является большим шагом вперед для большинства магазинов. (Если ваши программисты уже проводят более сложное тестирование, для вас больше возможностей. Продолжайте в том же духе, это может только помочь!)

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

Улучшение дизайна (рефакторинг)

Extreme Programming фокусируется на предоставлении бизнес-ценности на каждой итерации. Чтобы добиться этого на протяжении всего проекта, программное обеспечение должно быть хорошо спроектировано. Альтернативой будет замедление и в конечном итоге застревание. Таким образом, XP использует процесс непрерывного улучшения дизайна, называемый Refactoring , из названия книги Мартина Фаулера «Рефакторинг: улучшение дизайна существующего кода».

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

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

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

Команды

Extreme Programming постоянно поддерживают полную интеграцию системы. Мы говорим, что ежедневные сборки предназначены для слабаков: команды XP создают несколько раз в день.(Одна команда XP из сорока человек строит не менее восьми или десяти раз в день!)

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

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

Коллективный код собственности

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

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

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

Команды

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

Метафора

Команды

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

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

Устойчивый темп

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

Заключение

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

Ключевые практики экстремального программирования (XP)

eXtreme Programming (также известный как «XP») — один из самых популярных методов разработки программного обеспечения, впервые представленных в 1990-х годах. В то время как многие организации выбрали «Agile» или «Scrum» в качестве основного модного слова сегодня для описания итеративной и инкрементальной разработки, XP, похоже, за последние несколько лет все меньше и меньше понимают. Многие организации пришли к выводу, что «XP» является синонимом парного программирования, что не совсем верно; Парное программирование, возможно, стало одной из основных отличительных характеристик XP, но это только одна из двенадцати практик, которые охватывает эта методология.Итак, какие из этих практик все еще важны и актуальны сегодня? Позвольте изучить несколько.

Основная практика №1 — Парное программирование

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

Основная практика №2 — Планирование игры

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

Ключевая практика № 3 — Непрерывный процесс

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

Ключевая практика №4 — Стандарты кодирования

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

Ключевая практика № 5 — Устойчивый темп

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

Ключевая практика №6 — Разработка через тестирование (TDD)

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

Завершая эту краткую статью, eXtreme Programming предлагает набор методов разработки программного обеспечения, которые могут принести пользу большинству команд разработчиков программного обеспечения.XP соответствует принципам Agile и может помочь вашей команде использовать более структурированный подход к предоставлению программных решений, таких как Scrum или Scaled Agile Framework. Я рекомендую начинать с одной или двух практик и постепенно наращивать небольшие успехи.

Ознакомьтесь с нашим каталогом Agile-обучения

Учить больше

Евгений Лай

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

Экстремальное программирование (XP) было одной из наиболее широко известных и используемых гибких методологий еще в начале 2000-х годов.XP был детищем Кента Бека, Рона Джеффриса и Уорда Каннингема, основанного на их коллективном опыте в Daimler Chrysler. Его название стало мармитом и отложило управление. Это неправильно вызывало видение серфингистов и непрофессионализма.

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

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

Практики XP

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

Значения XP

XP включила значения в методологию за десятилетия до того, как их приняла структура Scrum. Четыре значения XP:

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

Роли XP

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

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

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

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

Рекомендуемая литература

• Подпишитесь на бесплатное обучение с нашими часто задаваемыми вопросами LIVE
• Загрузите наши полезные информационные бюллетени обо всем, что касается Agile

Рекомендуемые курсы обучения

.