Войти
Циклы планирования и обратной связи в экстремальном программировании Экстремальное программирование (XP) - это методология разработки программного обеспечения, которая предназначена для улучшения качества программного обеспечения и способности реагировать на меняющиеся требования клиентов. Как тип гибкой разработки программного обеспечения, он поддерживает частые «выпуски» в короткие циклы разработки, которые предназначены для повышения производительности и введения контрольных точек, в которых могут быть приняты новые требования клиентов.
Другие элементы экстремального программирования включают: программирование в парах или выполнение обширного обзора кода, модульное тестирование всего кода, нет. функции программирования до тех пор, пока они действительно не понадобятся, плоская структура управления, простота и ясность кода, ожидание изменений в требованиях клиентов по прошествии времени и более глубокое понимание проблемы, а также частое общение с заказчиком и программистами. Эта методология получила свое название от идеи, что полезные элементы традиционных практик разработки программного обеспечения доводятся до «экстремального» уровня. Например, проверка кода считается полезной практикой; доведенный до крайности, код можно просматривать постоянно, то есть практика парного программирования.
Кент Бек разработал экстремальное программирование во время своего работа над проектом Комплексной системы вознаграждения Chrysler (C3) по проекту. Бек стал руководителем проекта C3 в марте 1996 года. Он начал совершенствовать методологию разработки, использованную в проекте, и написал книгу по этой методологии (Extreme Programming Explained, опубликованная в октябре 1999 года). Chrysler отменил проект C3 в феврале 2000 года, через семь лет, когда Daimler-Benz приобрела компанию.
Многие практики экстремального программирования существуют уже некоторое время; методология доводит "передовой опыт " до крайнего уровня. Например, «практика разработки, планирования и написания тестов перед каждым микроинкрементом» использовалась еще в проекте NASA Project Mercury в начале 1960-х годов. Чтобы сократить общее время разработки, некоторые формальные тестовые документы (например, для приемочного тестирования ) были разработаны параллельно (или незадолго до этого) с программным обеспечением, готовым к тестированию. Независимая группа тестирования НАСА может написать процедуры тестирования на основе формальных требований и логических ограничений, прежде чем программисты напишут программное обеспечение и интегрируют его с оборудованием. XP доводит эту концепцию до крайнего уровня, создавая автоматизированные тесты (иногда внутри программных модулей), которые проверяют работу даже небольших участков программного кода, а не только тестируют более крупные функции.
На разработку программного обеспечения в 1990-х годах повлияли два основных фактора:
Быстро меняющиеся требования требовали более коротких жизненных циклов продукта и часто противоречили традиционным методам разработки программного обеспечения.
Комплексная система компенсации Chrysler (C3) началась с того, чтобы определить лучший способ использования объектных технологий, используя системы расчета заработной платы в Chrysler в качестве объекта исследования, с Smalltalk в качестве языка и GemStone в качестве уровня доступа к данным. Крайслер привлек Кента Бека, известного специалиста по Smalltalk, для настройки производительности в системе, но его роль расширилась, поскольку он заметил несколько проблем в процессе разработки. Он воспользовался этой возможностью, чтобы предложить и реализовать некоторые изменения в практике разработки - на основе его работы со своим постоянным сотрудником Уордом Каннингемом. Бек описывает раннюю концепцию методов:
Когда меня впервые попросили возглавить команду, я попросил их сделать кое-что из того, что я считаю разумным, например, тестирование и обзоры. Во второй раз на кону было намного больше. Я подумал: «К черту торпеды, по крайней мере, из этого будет хорошая статья», [и] попросил команду поднять все ручки до 10 на том, что я считал важным, и исключить все остальное.
Бек пригласил Рон Джеффрис в проект, чтобы помочь разработать и усовершенствовать эти методы. После этого Джеффрис выступал в роли тренера, чтобы привить практику как привычку в команде C3.
Информация о принципах и методах, лежащих в основе XP, распространялась по всему миру посредством обсуждений на исходной вики, WikiWikiWeb Каннингема. Различные участники обсуждали и расширяли идеи, в результате чего были получены некоторые дополнительные методологии (см. гибкая разработка программного обеспечения ). Кроме того, концепции XP объяснялись в течение нескольких лет с использованием системной карты гипертекст на веб-сайте XP http://www.extremeprogramming.org около 1999 года.
Бек редактировал серию книг по XP, начиная со своей собственной книги «Объяснение экстремального программирования» (1999, ISBN 0-201-61641-6 ), распространяя свои идеи на гораздо более широкие круги. аудитория. Авторы этой серии рассмотрели различные аспекты, связанные с XP и ее практиками. В серию вошла книга с критикой практик.
XP вызвала значительный интерес среди программных сообществ в конце 1990-х и начале 2000-х годов, когда было принято во многих средах, радикально отличных от его первоначального.
Высокая дисциплина, требуемая изначальными практиками, часто уходила на второй план, в результате чего некоторые из этих практик, например те, которые считались слишком жесткими, становились устаревшими, сокращались или даже оставались незавершенными на отдельных сайтах. Например, практика завершения рабочего дня интеграционных тестов для конкретного проекта может быть изменена на расписание на конец недели или просто сведена к тестированию во взаимно согласованные сроки. Такой более расслабленный график поможет избежать того, чтобы люди чувствовали спешку с созданием искусственных заглушек только для того, чтобы пройти тестирование в конце дня. Менее жесткий график позволяет вместо этого разрабатывать сложные функции в течение нескольких дней.
Между тем, другие практики гибкой разработки не стояли на месте, и по состоянию на 2019 год XP продолжает развиваться, усваивая больше уроков из практического опыта для использования других практик. Во втором издании «Объяснение экстремального программирования» (ноябрь 2004 г.), через пять лет после первого издания, Бек добавил больше ценностей и практик и провел различие между первичными и побочными практиками.
Теория устойчивой разработки программного обеспечения объясняет, почему группы экстремального программирования могут процветать, несмотря на сбои в работе команды.
Объяснение экстремального программирования описывает экстремальное программирование. программирование как дисциплина разработки программного обеспечения, которая объединяет людей для более продуктивного производства высококачественного программного обеспечения.
XP пытается снизить стоимость изменения требований за счет использования нескольких коротких циклов разработки, а не длинного. Согласно этой доктрине, изменения являются естественным, неизбежным и желательным аспектом проектов разработки программного обеспечения, и их следует планировать, а не пытаться определить стабильный набор требований.
Экстремальное программирование также вводит ряд базовых ценностей, принципов и практик поверх среды гибкого программирования.
XP описывает четыре основных действия, которые выполняются в процессе разработки программного обеспечения: кодирование, тестирование, прослушивание и проектирование. Каждое из этих мероприятий описано ниже.
Сторонники XP утверждают, что единственный действительно важный продукт процесса разработки системы - это код - программные инструкции, которые компьютер может интерпретировать. Без кода нет рабочего продукта.
Для поиска наиболее подходящего решения можно использовать кодирование. Кодирование также может помочь передать мысли о проблемах программирования. Программист, имеющий дело со сложной проблемой программирования или испытывающий трудности с объяснением решения другим программистам, может запрограммировать ее в упрощенной форме и использовать код, чтобы продемонстрировать, что они имеют в виду. Кодекс, говорят сторонники этой позиции, всегда ясен и лаконичен и не может быть интерпретирован более чем одним способом. Другие программисты могут дать отзыв об этом коде, также написав свои мысли.
Тестирование занимает центральное место в экстремальном программировании. Подход экстремального программирования заключается в том, что если небольшое тестирование может устранить несколько недостатков, то большое количество тестов может устранить гораздо больше недостатков.
Общесистемная интеграция Первоначально тестирование поощрялось как ежедневное мероприятие в конце рабочего дня для раннего обнаружения несовместимых интерфейсов, чтобы повторно подключиться до того, как отдельные разделы будут сильно отличаться от согласованной функциональности. Однако общесистемное интеграционное тестирование сократилось до еженедельного или реже, в зависимости от стабильности общих интерфейсов в системе.
Программисты должны прислушиваться к тому, что клиенты нужна система, какая нужна "бизнес-логика ". Они должны достаточно хорошо понимать эти потребности, чтобы давать клиентам обратную связь о технических аспектах того, как проблема может быть решена или не может быть решена. Взаимодействие между заказчиком и программистом дополнительно рассматривается в игре планирование.
С точки зрения простоты, конечно, можно сказать, что для разработки системы не требуется ничего, кроме кодирования, тестирование и прослушивание. Если эти действия выполняются хорошо, результатом всегда должна быть работающая система. На практике это не сработает. Можно пройти долгий путь без проектирования, но в определенный момент он застрянет. Система становится слишком сложной, и зависимости внутри системы перестают быть ясными. Этого можно избежать, создав структуру дизайна, которая организует логику в системе. Хороший дизайн позволит избежать многих зависимостей внутри системы; это означает, что изменение одной части системы не повлияет на другие части системы.
Экстремальное программирование первоначально признавало четыре ценности в 1999 году: общение, простота, обратная связь и смелость. Во втором издании «Объяснения экстремального программирования» было добавлено новое значение - уважение. Эти пять значений описаны ниже.
Для построения программных систем необходимо сообщить системные требования разработчикам системы. В формальных методологиях разработки программного обеспечения эта задача решается с помощью документации. Приемы экстремального программирования можно рассматривать как методы быстрого накопления и распространения институциональных знаний среди членов команды разработчиков. Цель состоит в том, чтобы дать всем разработчикам общее представление о системе, которое соответствует представлению пользователей системы. С этой целью экстремальное программирование способствует простому дизайну, распространенным метафорам, сотрудничеству пользователей и программистов, частому устному общению и обратной связи.
Экстремальное программирование побуждает начинать с самого простого решения. Дополнительные функции могут быть добавлены позже. Разница между этим подходом и более традиционными методами разработки систем заключается в сосредоточении внимания на проектировании и кодировании для нужд сегодняшнего дня, а не для нужд завтрашнего дня, следующей недели или следующего месяца. Иногда это называют подходом «Тебе это не понадобится » (ЯГНИ). Сторонники XP признают тот недостаток, что иногда это может повлечь за собой дополнительные усилия по изменению системы; они утверждают, что это более чем компенсируется преимуществом отказа от инвестирования в возможные будущие требования, которые могут измениться до того, как станут актуальными. Кодирование и проектирование с учетом неопределенных будущих требований подразумевает риск потратить ресурсы на то, что может оказаться ненужным, и, возможно, отложить важные функции. Что касается ценности «коммуникации», простота дизайна и кодирования должна улучшить качество коммуникации. Простая конструкция с очень простым кодом может быть легко понятна большинству программистов в команде.
В экстремальном программировании обратная связь относится к различным аспектам разработки системы:
Обратная связь тесно связана с общением и простотой. Об ошибках в системе легко сообщить, написав модульный тест, который доказывает, что определенный фрагмент кода сломается. Прямая обратная связь от системы говорит программистам перекодировать эту часть. Заказчик может периодически тестировать систему в соответствии с функциональными требованиями, известными как пользовательские истории. Цитируя Кента Бека : «Оптимизм - это профессиональная опасность программирования. Обратная связь - это лечение».
Смелость воплощается в нескольких практиках. Одна из них - это заповедь всегда проектировать и кодировать для сегодняшнего дня, а не для завтрашнего дня. Это попытка не увязнуть в дизайне и не требует больших усилий для реализации чего-либо еще. Смелость позволяет разработчикам чувствовать себя комфортно при рефакторинге своего кода, когда это необходимо. Это означает пересмотр существующей системы и ее модификацию, чтобы облегчить внедрение будущих изменений. Другой пример смелости - знать, когда выбросить код: смелость удалить устаревший исходный код, независимо от того, сколько усилий было затрачено на создание этого исходного кода. Кроме того, смелость означает настойчивость: программист может застрять на сложной проблеме на целый день, а на следующий день быстро решить ее, но только если они будут настойчивы.
Ценность уважения включает уважение к другим, а также самоуважение. Программисты никогда не должны фиксировать изменения, которые нарушают компиляцию, приводят к сбою существующих модульных тестов или иным образом задерживают работу их коллег. Члены уважают свою собственную работу, всегда стремясь к высокому качеству и ища лучший дизайн для подручного решения посредством рефакторинга.
Принятие четырех предыдущих ценностей приводит к уважению со стороны других в команде. Никто в команде не должен чувствовать себя недооцененным или проигнорированным. Это обеспечивает высокий уровень мотивации и поощряет лояльность к команде и цели проекта. Эта ценность зависит от других ценностей и ориентирована на командную работу.
Первая версия правил для XP была опубликована в 1999 году Доном Уэллсом на веб-сайте XP. 29 правил приведены в категориях планирования, управления, проектирования, кодирования и тестирования. Планирование, управление и проектирование призваны явным образом противостоять утверждениям о том, что XP не поддерживает эти действия.
Другая версия правил XP была предложена Кеном Ауэром в XP / Agile Universe 2003. Он чувствовал, что XP определяется своими правилами, а не практиками (которые подвержены большему разнообразию и двусмысленности). Он определил две категории: «Правила взаимодействия», которые определяют среду, в которой разработка программного обеспечения может происходить эффективно, и «Правила игры», определяющие поминутные действия и правила в рамках Правил взаимодействия.
Вот некоторые из правил (неполные):
Кодирование
Тестирование
Принципы, которые формируют Основы XP основаны на только что описанных ценностях и предназначены для принятия решений в проекте разработки системы. Принципы должны быть более конкретными, чем ценности, и их легче перевести в практическую ситуацию.
В экстремальном программировании обратная связь наиболее полезна, если она выполняется часто и быстро. Он подчеркивает, что минимальная задержка между действием и его обратной связью имеет решающее значение для обучения и внесения изменений. В отличие от традиционных методов разработки систем, контакт с заказчиком происходит чаще. Заказчик имеет четкое представление о разрабатываемой системе, может дать обратную связь и направить разработку по мере необходимости. При частой обратной связи с заказчиком ошибочное проектное решение, принятое разработчиком, будет замечено и быстро исправлено, прежде чем разработчик потратит много времени на его реализацию.
Модульные тесты способствуют принципу быстрой обратной связи. При написании кода запуск модульного теста обеспечивает прямую обратную связь о том, как система реагирует на внесенные изменения. Это включает в себя запуск не только модульных тестов, которые тестируют код разработчика, но и запуск всех модульных тестов для всего программного обеспечения с использованием автоматизированного процесса, который может быть инициирован одной командой. Таким образом, если изменения, внесенные разработчиком, вызывают сбой в какой-либо другой части системы, о которой разработчик мало что знает или ничего не знает, автоматизированный комплексный набор тестов немедленно обнаружит сбой, предупредив разработчика о несовместимости их изменения с другие части системы, а также необходимость удаления или изменения их изменений. При традиционных методах разработки отсутствие автоматизированного комплексного набора модульных тестов означало, что такое изменение кода, которое разработчик считает безопасным, осталось бы на месте и появилось бы только во время интеграционного тестирования - или, что еще хуже, только в производственной среде; а определение того, какое изменение кода вызвало проблему, среди всех изменений, внесенных всеми разработчиками в течение недель или даже месяцев, предшествовавших тестированию интеграции, было сложной задачей.
Речь идет о том, чтобы рассматривать каждую проблему так, как если бы ее решение было «чрезвычайно простым». Традиционные методы разработки систем говорят о планировании будущего и кодировании для повторного использования. Экстремальное программирование отвергает эти идеи.
Сторонники экстремального программирования говорят, что сразу внести большие изменения не получится. Экстремальное программирование применяет постепенные изменения: например, система может выпускать небольшие выпуски каждые три недели. Когда делается много маленьких шагов, заказчик получает больше контроля над процессом разработки и разрабатываемой системой.
Принцип принятия изменений заключается в том, чтобы не работать против изменений, а принять их. Например, если на одной из итеративных встреч выясняется, что требования заказчика резко изменились, программисты должны принять это и спланировать новые требования для следующей итерации.
Экстремальное программирование описывается как имеющее 12 практик, сгруппированных в четыре области:
Практика XP является предметом серьезных дискуссий. Сторонники экстремального программирования утверждают, что если запрос клиента на месте изменяется неформально, процесс становится гибким и экономит формальные накладные расходы. Критики XP утверждают, что это может привести к дорогостоящим переделкам и расширению масштабов проекта сверх того, что было согласовано или профинансировано ранее.
Доски контроля изменений являются признаком того, что есть потенциальные конфликты в целях проекта и ограничения между несколькими пользователями. Ускоренные методы XP в некоторой степени зависят от того, могут ли программисты принять единую точку зрения клиента, поэтому программист может сосредоточиться на кодировании, а не на документации компромиссных целей и ограничений. Это также применимо, когда задействовано несколько организаций, занимающихся программированием, особенно организаций, которые конкурируют за долю в проектах.
Другие потенциально противоречивые аспекты экстремального программирования включают в себя:
Критики отметили несколько потенциальных недостатков, в том числе проблемы с нестабильными требованиями, отсутствие документированных компромиссов, связанных с конфликтами пользователей, а также отсутствие общей проектной спецификации или документа.
ThoughtWorks заявила о разумном успехе в распределенных проектах XP с участием до шестидесяти человек.
В 2004 году промышленное экстремальное программирование (IXP) было представлено как эволюция XP. Он предназначен для обеспечения возможности работы в больших и распределенных командах. Сейчас в нем 23 практики и гибкие ценности.
В 2003 году Мэтт Стивенс и Дуг Розенберг опубликовали «Рефакторинг экстремального программирования: аргументы против XP», в которых ставится под сомнение ценность процесса XP и предлагаются способы в котором это могло быть улучшено. Это вызвало длительные дебаты в статьях, группах новостей в Интернете и чатах на веб-сайтах. Основной аргумент книги состоит в том, что практики XP взаимозависимы, но лишь немногие практические организации готовы / могут принять все методы; поэтому весь процесс терпит неудачу. В книге также содержится другая критика, и в ней проводится негативное сходство модели «коллективной собственности» XP с социализмом.
Некоторые аспекты XP изменились с момента публикации Extreme Programming Refactored; в частности, XP теперь позволяет вносить изменения в практику, если все еще выполняются требуемые цели. XP также использует все более общие термины для обозначения процессов. Некоторые утверждают, что эти изменения сводят на нет предыдущую критику; другие утверждают, что это просто размывает процесс.
Другие авторы пытались согласовать XP со старыми методологиями, чтобы сформировать единую методологию. Некоторые из этих XP стремились заменить, например, методология водопада ; пример: Жизненные циклы проекта: водопад, Быстрая разработка приложений (RAD) и все такое. JPMorgan Chase Co. пыталась объединить XP с методами компьютерного программирования интеграции модели зрелости возможностей (CMMI) и Six Sigma. Они обнаружили, что эти три системы хорошо дополняют друг друга, что ведет к лучшему развитию, и не противоречат друг другу.
Первоначальный шум экстремального программирования и противоречивые принципы, такие как парное программирование и непрерывный дизайн вызвали особую критику, например, со стороны Макбрина, Бема и Тернера, Мэтта Стивенса и Дуга Розенберга. Однако многие из критических замечаний практикующие Agile считают неправильным пониманием гибкой разработки.
В частности, экстремальное программирование было рассмотрено и раскритиковано Мэттом Стивенсом и Дугом Розенбергом в книге Extreme Programming Refactored.
Критика включает:
 | На Викискладе есть материалы, связанные с Экстремальным программированием. |
 | Викицитатник содержит цитаты, связанные с: Экстремальным программированием |
