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

Обновлено: 05.07.2024

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

Резюме

Источник

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

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

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

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

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

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

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

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

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

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

Значения

Экстремальное программирование на основе пяти основных ценностей.

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

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

Простота

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

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

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

Храбрость

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

Уважать

Упражняться

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

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

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

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

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

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

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

Небольшие поставки

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

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

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

Приемочные испытания (или функциональные испытания)

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

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

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

Модульные тесты

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

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

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

Использование метафор

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

Рефакторинг (или доработка кода)

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

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

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

Соглашение об именовании

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

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

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

Прочие принципы

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

Этот метод основан на:

сильная реакция на меняющиеся потребности клиентов;
командная работа ;
качество кода;
качество тестов проведено в кратчайшие сроки.

Неблагоприятные условия

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

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

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

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

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

План релизов

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

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

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

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

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

Простота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile-методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным.

Автор методики — американский разработчик Кент Бек. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System и там впервые применил практики экстремального программирования. Свой опыт и созданную концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999 году. За ней были выпущены другие книги, в которых подробно описывались практики XP. К становлению методологии причастны также Уорд Каннингем, Мартин Фаулер и другие.

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

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

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

1. Вся команда

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

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

Планирование в XP проводят в два этапа — планирование релиза и планирование итераций.

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

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

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

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

3. Частые релизы версий

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

4. Пользовательские тесты

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

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

6. Непрерывная интеграция кода

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

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

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

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

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

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

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

Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.

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

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

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

13. Рефакторинг

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

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

Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.

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

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

Несмотря на все плюсы, XP не всегда работает и имеет ряд слабых мест. Итак, экстремальное программирование — недостатки:

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

Принципы XP

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

1. Простота

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

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

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

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

Обратная связь в XP реализуется сразу в трех направлениях:

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

4. Смелость

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

5. Уважение

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

Алгоритм внедрения методологии XP и процесс работы

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

Чтобы внедрить XP в существующий проект, нужно постепенно осваивать его методики в области:

тестирования
проектирования
планирования
менеджмента
разработки

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

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

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

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

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

Менеджмент.

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

Разработка.

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

В проекте, который работает по методологии XP процесс построен таким образом:

Кто использует XP

По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.

Соотношение agile методологий и практик в компаниях

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

Самые популярные практики разработки в agile компаниях в 2016 г.

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

Pivotal Software, Inc.

Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.

Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.

Парное программирование в openspace компании Pivotal Software, Inc.

Что почитать, чтобы разобраться в XP

Экстремальное программирование,
Экстремальное программирование: планирование,
Экстремальное программирование: разработка через тестирование / Кент Бек

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

Рефакторинг: улучшение существующего кода / Мартин Фаулер

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

Экстремальное программирование: постановка процесса. С первых шагов и до победного конца / Кен Ауэр, Рой Миллер

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

Приложения для внедрения XP в команде

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

Redmine

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

Basecamp

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

Worksection

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

Вердикт

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

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

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

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

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

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

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

Для чего нужно экстремальное программирование?

Популяризатором подхода Extreme Programming выступает Кент Бек, который выдвинул и оптимизировал его в середине 90-х годов прошлого века, пока работал над крупным приложением для компании Chrysler. Результатом наработок стало создание принципиально новой методологии XP. Подобный подход преследовал сразу 4 цели:

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

Кому подойдет подобный подход?

Экстремальное программирование подойдет нескольким категориям разработчиков:

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

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

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

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

В то же время, XP не подходит для решения вопросов проекта, если:

Команда слишком велика, ее численно превышает 50 человек. Часть кадровых ресурсов не будет задействована. Большого смысла в экономии не остается. Есть возможность привлечь больше специалистов и польза от XP сводится к нулю.
Объем работ четко определен и финансирование невозможно увеличить даже в минимальных пределах.
Технические требования к конечной системе жестко регламентированы. Инициатива специалистов по программированию жестко ограничена или полностью исключена.
XP подойдет при реализации большей части проектов самостоятельными командами, коллективами в рамках небольших частных фирм-разработчиков ПО.

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

Суть методологии можно описать 12-ю принципами:

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

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

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

Четкое планирование

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

Плотный контакт с заказчиком

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

Парное участие

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

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

Повторяющиеся итерации

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

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

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

Ранний релиз конечного продукта

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

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

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

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

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

Разработка метафоры системы

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

Жесткие стандарты оформления кода

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

Коллективная работа

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

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

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

Как внедрить?

Чтобы внедрить XP требуется соблюдение нескольких условий:

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

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

Среди преимуществ XP:

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

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

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

Читайте также: