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

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

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

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

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

План релизов

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

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

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

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

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

Простота

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

как не путаться в терминах — статьи на 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-проектами»

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

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

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)

7. Экстремальное программирование. Extreme Programming (XP)

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

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

Главные принципы методологии:

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

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

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

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

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

ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ

Что такое экстремальное программирование (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 — это акцент на совершенстве практики. Этот метод предписывает небольшое количество абсолютно необходимых практик и побуждает команды выполнять эти практики настолько хорошо, насколько это возможно, почти до крайности. Отсюда и название.Не потому, что сами практики обязательно радикальны (хотя некоторые считают некоторые из них довольно далекими), а потому, что команды постоянно сосредоточены на постоянном улучшении своей способности выполнять эти несколько практик.

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

.

Extreme Programming: Мягкое введение.

Первый
Проект Extreme Programming стартовал 6 марта,
1996. Экстремальное программирование — один из нескольких популярных Agile
Процессы. Уже доказано, что это очень успешно
во многих компаниях разных размеров и отраслей по всему миру.
Экстрим
Программирование
успешен, потому что подчеркивает удовлетворенность клиентов. Вместо того
доставить все, что вы, возможно, захотите, на какое-то время далеко
в будущем это
процесс поставляет необходимое программное обеспечение, как вы
нужно это.Экстремальное программирование дает вашим разработчикам возможность уверенно
реагировать на изменение
требования заказчика, даже на поздних этапах жизненного цикла.
Экстрим
В программировании упор делается на командную работу. Менеджеры, клиенты и
все разработчики — равноправные партнеры в совместной команде. Экстремальный
Программирование реализует простую, но эффективную среду, позволяющую
команды, чтобы стать высокопроизводительными. Команда
самоорганизуется вокруг проблемы, чтобы решить ее так же эффективно, как
возможное.

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

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

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

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

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

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

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

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

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

XP имеет простые правила, основанные на 5 значениях .

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

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

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

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

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

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

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

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

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

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

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

Клиент на месте

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

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

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

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

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

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

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

Небольшие релизы

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

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

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

Специалисты

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

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

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

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

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

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

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

Условия работы программиста

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

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

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

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

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

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

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

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

Заключение

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

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

Команды

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

.

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

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

Незадолго до 2000 года Кен Бек разработал экстремальное программирование (XP) во время своей работы в проекте расчета заработной платы Chrysler Comprehensive Compensation System. Бек стал руководителем этого проекта и, таким образом, усовершенствовал используемую методологию разработки, что в конечном итоге привело его к написанию книги о методологии, названной им «Объяснение экстремального программирования».

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

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

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

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

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

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

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

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

Карты пользовательских историй:

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

Приемочные испытания:

• Один или несколько тестов для проверки правильности реализации истории (см. Выше).

Оценок:

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

Карточки задач:

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

Конструкция:

• Содержит простой дизайн, достаточный для реализации пользовательской истории.

Примеры модульных тестов:

• Содержит модульные тесты, управляющие кодированием и модульным тестированием.

Записи о взаимодействии с заказчиком и разработчиком:

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

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

Extreme Programming (XP) имеет 5 значений, которые считаются его правилами:

Связь:

• Члены команды работают вместе на каждом этапе проекта.

Простота:

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

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

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

Репутация:

• Каждый участник проекта вносит свой вклад в общую цель.

Мужество:

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

Пять принципов, которым следует XP:

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

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

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

Предполагаемая простота:

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

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

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

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

Разработчики следуют принципам YAGNI (Вам это не понадобится) и DRY (Don’t Repeat Yourself). Например: (И да! Это действительно правильные принципы, изложенные так!)

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

Дополнительные изменения:

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

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

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

Обнимая изменение:

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

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

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

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

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

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

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

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

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

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

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

В рамках этой практики существует «этап планирования выпуска».

Этот этап влечет за собой определения в отношении предстоящих выпусков: Разделы этапа планирования выпуска:

Этап разведки:

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

Фаза обязательства:

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

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

Этап управления позволяет скорректировать ранее разработанные планы в соответствии с меняющимися требованиями проекта.

За этапом планирования выпуска следует «этап планирования итераций». Хотя он имеет те же подэтапы, есть вариации в реализации.

Этап разведки:

Требования к проекту записаны.

Фаза обязательства:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мелкие релизы:

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

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

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

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

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

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

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

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

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

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

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

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

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

Условия работы программиста:

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

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

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

XP может хорошо работать для команд, которые:

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

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

Быстрый:

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

Видимый:

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

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

Все это ограничит количество ошибок и сбоев в системе.

Снижение затрат:

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

Работа в команде:

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

Крепкие отношения с клиентом:

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

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

Код превосходит дизайн:

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

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

Расположение:

Проект

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

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

Отсутствие документации:

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

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

Напряжение:

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

Резюме и факты

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

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

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

Extreme Programming (XP) имеет 5 значений, которые считаются его правилами:

• Связь
• Простота
• Обратная связь
• Уважение
• Смелость

Пять принципов, которым следует XP:

• Быстрая обратная связь
• Предполагаемая простота
• Дополнительные изменения
• Принятие изменений
• Качественная работа

Практики, задействованные в Экстремальное программирование :

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

• Разработка через тестирование
• Игра в планирование
• Заказчик на месте
• Парное программирование

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

• Рефакторинг кода
• Непрерывная интеграция
• Малые версии

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

• Простой дизайн
• Стандарты кодирования
• Собственность коллективного кода
• Системная метафора

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

• Условия работы программиста

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

Ссылки:

1. https: // www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/
2. https://www.brighthubpm.com/methods-strategies/88996-the-extreme-programming-life-cycle/
3. https://www.agilealliance.org/glossary/xp/#q=~(infinite~false~filters~(postType~(~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_ video~’a ) ~ теги ~ (~ ‘xp)) ~ searchTerm ~’ ~ sort ~ false ~ sortDirection ~ ‘asc ~ page ~ 1)
4. https://airbrake.io/blog/sdlc/extreme-programming
5. https: / / en.wikipedia.org/wiki/Extreme_programming#Origins
6. https://simpleprogrammer.com/pros-cons-extreme-programming-xp/
7. ionos.co.uk/digitalguide/websites/web-development/extreme-programming/
8. https://medium.com/@azimidev/extreme-programming-xp-35223784976e
9. https://www.tutorialspoint.com/extreme_programming/extreme_programming_activities_artifacts.htm

.