Лекция
Привет, Вы узнаете о том , что такое экстремальное программирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое экстремальное программирование, extreme programming, xp, парное программирование, группове программирование, mob-программирование , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
Экстремальное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработкипрограммного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой « парное программирование », когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код.
XP отличается от других гибких методологий тем, что применимо только в области разработки программного обеспечения. Оно не может быть использовано в другом бизнесе или повседневной жизни, как scrum, kanban или lean.
Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. Поэтому XP хорошо подходит для сложных и неопределенных проектов
Методология XP строится вокруг четырех процессов: кодирования, тестирования, дизайна и слушания. Кроме того, экстремальное программирование имеет ценности: простоту, коммуникацию, обратную связь, смелость и уважение.
Двенадцать основных приемов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
XP предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том, что каждый из них по отдельности работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода, и как он функционирует — в ходе изучения кода тестов логика работы тестируемого кода становится понятной, так как видно, как он должен использоваться. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Функциональные тесты предназначены для тестирования функционирования логики, образуемой взаимодействием нескольких (часто — довольно внушительного размера) частей. Они менее детальны, чем юнит-тесты, но покрывают гораздо больше — то есть, у тестов, которые при своем выполнении затрагивают больший объем кода, шанс обнаружить какое-либо некорректное поведение, очевидно, больше. По этой причине в промышленном программировании написание функциональных тестов нередко имеет больший приоритет, чем написание юнит-тестов.
Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development — разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, еще просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошел. TDD, в некотором смысле, позволяет писать код, более удобный в использовании — потому что при написании теста, когда логики еще нет, проще всего позаботиться об удобстве будущей системы.
Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.
«Заказчик» в XP — это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть все время на связи и доступен для вопросов.
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом парное программирование усиливает взаимодействие внутри команды.
Если выполнять интеграцию разрабатываемой системы достаточно часто, то можно избежать большей части связанных с ней проблем. В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В XP интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
Рефакторинг (refactoring) — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга в связи с боязнью поломать систему, что приводит к постепенной деградации кода.
Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.
Чем раньше выпускается первая рабочая версия продукта, тем раньше заказчик начинает получать за счет нее дополнительную прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска.
XP исходит из того, что в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Попытка детально спроектировать систему в самом начале работы является напрасной тратой времени. XP предполагает, что проектирование — это настолько важный процесс, что его необходимо выполнять постоянно в течение всего времени работы над проектом. Проектирование должно выполняться небольшими этапами, с учетом постоянно изменяющихся требований. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются.
Архитектура — это представление о компонентах системы и их взаимосвязях между собой. Разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
Метафора системы (system metaphor) — это аналог того, что в большинстве методик называется архитектурой. Метафора системы дает команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять.
Подбор хорошей метафоры облегчает для группы разработчиков понимание того, каким образом устроена система. Иногда сделать это непросто.
Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнеров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объемным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта.
Коллективное владение означает, что каждый член команды несет ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки ее может устранить любой программист.
Право каждого программиста изменять код ведет к риску появления ошибок, вносимых программистами, которые считают, что знают, что делают, но не рассматривают некоторые зависимости. Хорошо определенные юнит-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск юнит-тестов будет неудачным.
Все участники проекта с применением XP работают как одна команда. В нее обязательно входит представитель заказчика, лучше, если это будет реальный конечный пользователь продукта, разбирающийся в бизнесе. Заказчик выдвигает требования к продукту и расставляет приоритеты в реализации функциональности. Ему могут помогать бизнес-аналитики. Со стороны исполнителей в команду входят разработчики и тестировщики, иногда коуч, направляющий команду, и менеджер, который обеспечивает команду ресурсами. см ниже групповое программирование
На планировании релиза команда программистов встречается с заказчиком, чтобы выяснить, какую функциональность он хочет получить к следующему релизу, то есть через 2-6 месяцев. Так как требования заказчика часто размытые, разработчики конкретизируют их и дробят на части, реализация которых занимает не более одного дня. Важно, чтобы заказчик разбирался в операционной среде, в которой будет работать продукт.
Задачи записываются на карточки, а заказчик определяет их приоритет. Дальше разработчики оценивают, сколько времени уйдет на каждую задачу. Когда задачи описаны и оценены, заказчик просматривает документацию и дает добро на начало работы. Для успеха проекта критично, чтобы заказчик и команда программистов играли на одном поле: заказчик выбирает действительно необходимую функциональность в рамках бюджета, а программисты адекватно сопоставляют требования заказчика со своими возможностями.
В XP если команда не успевает выполнить все задачи к дате релиза, то релиз не отодвигается, а режется часть функционала, наименее важная для заказчика.
В XP версии выпускаются часто, но с небольшим функционалом. Во-первых, маленький объем функциональности легко тестировать и сохранять работоспособность всей системы. Во-вторых, каждую итерацию заказчик получает часть функционала, несущую бизнес-ценность.
Заказчик сам определяет автоматизированные приемочные тесты, чтобы проверить работоспособность очередной функции продукта. Команда пишет эти тесты и использует их для тестирования готового кода.
В XP любой разработчик может править любой кусок кода, т.к. код не закреплен за своим автором. Кодом владеет вся команда.
Это значит, что новые части кода сразу же встраиваются в систему — команды XP заливают новый билд каждые несколько часов и чаще. Во-первых, сразу видно, как последние изменения влияют на систему. Если новый кусок кода что-то сломал, то ошибку найти и исправить в разы проще, чем спустя неделю. Во-вторых, команда всегда работает с последней версией системы.
Когда кодом владеют все, важно принять единые стандарты оформления, чтобы код выглядел так, как будто он написан одним профессионалом. Можно выработать свои стандарты или принять готовые.
Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.
XP команды работают на максимуме продуктивности, сохраняя устойчивый темп. При этом экстремальное программирование негативно относится к переработкам и пропагандирует 40-часовую рабочую неделю.
Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.
Представьте двух разработчиков за одним компьютером, работающих над одним куском функциональности продукта. Это и есть парное программирование, самая спорная практика XP. Старая поговорка «одна голова хорошо, а две лучше» отлично иллюстрирует суть подхода. Из двух вариантов решения проблемы выбирается лучший, код оптимизируется сразу же, ошибки отлавливаются еще до их совершения. В итоге имеем чистый код, в котором хорошо разбираются сразу двое разработчиков.
Парное программирование - это гибкий метод разработки программного обеспечения , при котором два программиста работают вместе на одной рабочей станции. Один из них , водитель , пишет код , а с другой стороны , наблюдатель или навигатор , Ревью каждой строки кода . Два программисты часто меняются ролями.
Во время обзора наблюдатель также рассматривает «стратегическое» направление работы, предлагая идеи для улучшений и возможные будущие проблемы, которые необходимо решить. Это сделано для того, чтобы водитель мог сосредоточить все свое внимание на «тактических» аспектах выполнения текущей задачи, используя наблюдателя в качестве подстраховки и ориентира.
Парное программирование увеличивает количество человеко-часов, необходимых для написания кода, по сравнению с программистами, работающими индивидуально. Однако полученный код имеет меньше дефектов. Наряду со временем разработки кода, другие факторы, такие как затраты на поддержку на месте и обеспечение качества, также влияют на окупаемость инвестиций. Парное программирование теоретически может компенсировать эти расходы за счет уменьшения количества дефектов в программах.
Парное программирование позволяет членам команды быстро обмениваться информацией, что снижает вероятность того, что программы будут скрыты друг от друга(тимбилдинг). Это помогает парным программистам легче научиться общаться. «Это увеличивает пропускную способность и частоту связи внутри проекта, увеличивая общий информационный поток внутри команды».
Простой дизайн в XP означает делать только то, что нужно сейчас, не пытаясь угадать будущую функциональность. Простой дизайн и непрерывный рефакторинг дают синергетический эффект — когда код простой, его легко оптимизировать.
Рефакторинг — это процесс постоянного улучшения дизайна системы, чтобы привести его в соответствие новым требованиям. Рефакторинг включает удаление дублей кода, повышение связности и снижение сопряжения. XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.
mob-программирование (неформально моббинг ) (также известное как ансамблевое или группове программирование ) - это подход к разработке программного обеспечения, при котором вся команда работает над одним и тем же делом в одно и то же время, в одном пространстве и на одном компьютере. Это похоже на парное программирование, когда два человека сидят за одним компьютером и одновременно работают над одним и тем же кодом. При групповом программировании сотрудничество распространяется на всех в команде, при этом по-прежнему используется один компьютер для написания кода и ввода его в базу кода.
Основная концепция моб-программирования проста: вся команда работает как одна команда одновременно над одной задачей. То есть: одна команда - одна (активная) клавиатура - один экран (проектор конечно).
- Маркус Хаммарберг, групповое программирование - полная команда, полный газ
Он основан на принципах бережливого производства , экстремального программирования и бережливой разработки программного обеспечения . Раннее использование фразы «программирование мафии» было сделано в « Экстремальных перспективах программирования» .
Помимо кодирования программного обеспечения, группа программирования может работать вместе, чтобы выполнять почти всю работу, которую выполняет типичная группа разработчиков программного обеспечения, например, определение пользовательских историй или требований, проектирование, тестирование , развертывание программного обеспечения и работа с клиентами и бизнес-экспертами. Почти вся работа выполняется на рабочих встречах или семинарах, и все люди, участвующие в создании программного обеспечения, считаются членами команды, включая клиентов и бизнес-экспертов. Моб-программирование также работает для распределенных команд в одном виртуальном пространстве с использованием совместного использования экрана.
Групповое программирование - это три (или более) разработчика и одна клавиатура. Нет, это не те странные вещи, которые вы видели в интернете. Речь идет о совместной работе и выпуске высококачественного программного обеспечения.
Поскольку большинство программистов бросает в пот от одной мысли о совместной работе с другими людьми, то более подробно расскажу, как это выглядит. Представьте, что у нас есть разработчик Стив. Он работает над приложением, где пользователи могут просматривать рецепты. Однажды Стиву поручено добавить в приложение функцию «Избранное». С помощью этой функции пользователи могут сохранять рецепты в собственном списке под названием «Мое избранное». Если они хотят посмотреть сохраненный рецепт, то просто открывают список «Избранного» и выбирают его.
Стив хочет использовать групповое программирование для реализации своей функции, поэтому бронирует переговорную и просит своих коллег Джона и Сару присоединиться к его группе. Джон и Сара появляются на встречу с ноутбуками, готовые к работе над реализацией функции «Избранного».
В данный момент Стив должен установить определенные правила (да, у мобов есть правила). Они могут быть примерно такими:
В любой момент времени один человек является «водителем» (driver). Это человек с клавиатурой и мышью. Единственный, кому разрешено изменять код.
Все остальные берут на себя роль «штурманов» (navigator). В то время как водитель тратит много времени на физический набор текста, у штурманов есть все необходимое время, чтобы обдумать, просмотреть, обсудить, описать. И это именно то, что они должны делать.
Все часто меняются местами. Нет, это не какие-то игры, как в детском саду. Если люди слишком долго сидят в одной роли, то могут устать. Если же у них есть любимая роль, то могут заскучать без нее.
И это все — теперь вы знаете, что такое групповое программирование. Добавьте его в свое резюме.
Хорошо, я понял, что это такое, расскажи больше
Если вы дочитали досюда, то вероятно думаете: «Почему этот парень объясняет групповое программирование? Google и так выдает 500 объяснений». Ну просто я занимаюсь этим каждый день в течение пяти месяцев. И вот что я узнал:
Это действительно неплохо
Помню, когда впервые узнал о групповом программировании. Мне было 19, в комнате толпилась куча студентов, не пользующихся дезодорантом, в здании, которое выглядело так, словно оно предназначено под снос (забавно, но так оно и вышло). Профессор только что закончил объяснять курс по структурам данных. В конце он пошутил: «Вы можете работать в одиночку или в группе — в индустрии все работают в группах, они называют их мобами». Боже мой, подумал я, и во взрослой жизни есть групповая работа.
Удивительно, но каждый раз, когда я объясняю концепцию группового программирования новому человеку, кажется, то же чувство страха пробегает по его лицу. Оставь себе свою групповую работу.
Но вот плохая новость — вы уже занимаетесь групповой работой. На работе у вас есть коллектив, вы обращаетесь к коллегам за помощью, они рассматривают вам код. Требуется сочетание всех усилий для определения, будет проект успешным или нет.
И тогда можно понять, что такое групповое программирование. Это не больше групповой работы, а столько же. Разница в том, что все взаимодействия с коллегами станут очень легкими — больше никогда не придется гадать, чем они занимаются, никогда.
Групповое программирование помогает лучше узнать своих коллег
Если вы когда-нибудь оторвете глаза от монитора, то можете обнаружить вокруг других людей. Оказывается, у них тоже жизнь! Если серьезно, если взаимодействовать с коллегами с утра до вечера, то узнаете их намного лучше.
Поскольку программирование — это работа, а не клуб по интересам, мы должны быть более практичными. Хорошо взаимодействующие команды лучше справляются с работой. Это факт, отсюда все эти упражнения по тимбилдингу и выезду на природу. Командам в мобах не нужен тимбилдинг, потому что они уже хорошо работают вместе.
Удаленность — не причина уклониться
«Но я работаю удаленно, меня никогда нет в офисе, чтобы вступить с кем-то в моб». Плохие новости, приятель, я все время работаю удаленно. Оказывается, в этой штуке под названием 21-й век приложений для удаленной работы вагон и маленькая тележка. Мой любимый — видеозвонок Slack. Там есть все необходимые функции: вы можете расшарить экран, когда выступаете в роли водителя, и говорить голосом в роли штурмана. Может, ваша компания не использует Slack, а что-нибудь вроде WebEx, где организация звонка занимает три года работы научно-исследовательской группы. В этом случае просто открой сессию в Appear.in, кончай искать причины отлынивать от продуктивной работы.
Я больше времени программирую, потому что меньше туплю
Как выглядит программирование в одиночестве
Итак, я собираюсь сделать признание — я плохо разбираюсь в CSS. И не просто плохо, а конкретно ПЛОХО. Так что можете представить, если я работаю над проектом, скажем, над своим сайтом (скоро), то часами стучусь головой о стену, пытаясь понять, почему мои div'ы не выравниваются (правда, почему?).
В групповой работе все иначе: я не застреваю на CSS, потому что всегда есть вторая и третья пара глаз, чтобы помочь. Значит, я меньше времени стучусь головой о стену и больше времени уделяю решению проблем.
Нет такого понятия, как «мой кусочек» кода
Позвольте рассказать историю ужасов, историю конкретного фрагмента кода. Ну вы знаете такие. Изначально его написал Фрэнк, просто Фрэнк. Когда находились баги, Фрэнк их исправлял. Когда нужны были новые функции, Фрэнк их добавлял. Никто другой в команде не знал, как работает код. Только то, что он должен делать. Если он не делал что надо, рядом есть Фрэнк. Ну вот, однажды Фрэнка не оказалось рядом. Он нашел новую работу и получил большую прибавку к зарплате, молодец. А вы остались с куском системы, который никто не понимает и никто не хочет трогать, наслаждайтесь.
Группы работают сообща, так что никогда в коде не останется тайн и загадок. Если загадочный фрагмент есть сейчас, то натравите на него группу программистов с автором этого кода — и они положат тайне конец.
В разработке программного обеспечения , коммандное программирование является управлением проектом стратегии для координации распределения задач в компьютерных программах развития проектов, которая включает в себя назначение двух или более компьютерных программистов , чтобы совместно работать над отдельной подзадачей в рамках более крупным проектом программирования. В целом, то, как этот термин используется сегодня, относится к методам, которые в настоящее время являются модными в индустрии разработки программного обеспечения, когда несколько человек работают одновременно над одним и тем же видом деятельности; в этих системах программисты часто группируются парами на одной компьютерной рабочей станции., один наблюдает, как другой работает над программным обеспечением и чередует роли через определенные промежутки времени.
Традиционная разработка программного обеспечения почти всегда вовлекала несколько программистов, работающих над отдельными частями компьютерной системы для любого проекта значительного объема и масштаба - метод разделения труда . Ясно, что неразумно предполагать, что один-единственный программист может адекватно выполнить всю необходимую работу для сложной системы, работающей полностью самостоятельно в разумные сроки; и по мере того, как проекты развития становятся более сложными, специализированные знания приобретают первостепенное значение в таких аспектах, как системный анализ , обеспечение качества., а также технические проблемы, создаваемые отдельными компонентами. Изначально это был неформальный процесс, но с развитием коммерческой разработки программного обеспечения как жизнеспособной отрасли возникла необходимость в более индустриальном и систематическом подходе.
Системные методологии, ориентированные на бумажные носители, изначально разработанные для выполнения государственных проектов, таких как Структурный системный анализ и метод проектирования (SSADM), назначали отдельных людей для выполнения отдельных задач и определяли роль дизайнеров как четко отделенную от роли программистов в модель развития водопад программного обеспечения . Эта методология также четко разделяла каждую из отдельных стадий «жизненного цикла», через которые продвигается проект разработки системы. Получающийся в результате «бумажный след» для проекта разработки системы может занять так много времени, что часто части документации по анализу - а иногда и вся документация - устаревают к моменту фактической разработки, что делает их еще хуже, чем бесполезными.
С этими старыми методами возникли трудности, такие как затраты, выходящие из-под контроля по мере роста систем, а также не соблюдение расписаний по срокам выхода на рынок. Эти проблемы привели к появлению таких методов, как парное программирование , групповое программирование (также известное как ансамблевое программирование ), а также новые структуры жизненного цикла систем, такие как спираль Бема . Спецификация этих новых подходов началась в середине 1980-х годов и продолжается сегодня. Многие из этих стратегий предполагают, что несколько программистов совместно работают над одним и тем же фрагментом исходного кода, а не по отдельности.отвечает за индивидуальные задачи. Например, в «парном программировании» ответственность за конечный продукт поровну распределяется между двумя программистами, которые вместе работают над поставленной подзадачей. Преимущества этого подхода включают способность компенсировать недостатки в знаниях и способностях в определенных областях другим программистом; Кроме того, считается, что совместная ответственность увеличивает стимулы для соблюдения сроков проекта и целевых показателей качества.
Этот метод часто используется в новых методологиях программирования, ориентированных на методы объектно-ориентированного программирования, таких как Rational Unified Process и Extreme Programming (аббревиатура «XP»), часто в сочетании с методами проектной документации, такими как Unified Modeling Language (UML). ). В объектно-ориентированных языках программирования функциональные возможности программного обеспечения образуют модульные дискретные единицы (называемые классами для функциональных элементов и пакетами для совокупностей взаимосвязанных классов, которые выполняют определенную функцию); два самых известных из них - C ++ и Java.. Это хорошо подходит для разделения проектов программирования на подгруппы, хотя по-прежнему часто возникают проблемы при интеграции конечного продукта после завершения каждой подзадачи.
Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.
В первой книге Кент Бек сформулировал такие принципы экстремального программирования: простота, коммуникация, обратная связь и смелость. В новом издании книги он добавил пятый принцип — уважение.
В XP разработка начинается с самого простого решения, которое удовлетворит текущую потребность в функциональности. Члены команды учитывают только то, что должно быть сделано сейчас, и не закладывают в код функциональность, которая понадобится завтра, через месяц или никогда.
В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Команда активно общается между собой и с заказчиком.
Некоторые методики экстремального программирования настолько непривычны, что требует смелости и постоянного контроля над собой.
В экстремальном программировании уважение рассматривается с точки зрения уважения к команде и самоуважения. Члены команды не должны заливать изменения, которые поломают компиляцию, модульные тесты, или замедлят работу коллег. Каждый стремится к высшему качеству кода и дизайна.
Бек Кент рекомендует внедрять XP для решения проблем в проекте. Команда выбирает самую насущную проблему и решает ее с помощью одной из практик экстремального программирования. Затем переходит к следующей проблеме, используя еще одну практику. При таком подходе проблемы выступают мотивацией к применению XP и команда постепенно осваивает все инструменты методологии.
Команда создает тесты ПЕРЕД написанием нового кода и постепенно перерабатывает старый код. Для старого кода тесты пишутся по мере необходимости: когда нужно добавить новую функциональность, исправить ошибку или переработать часть старого кода.
Команда постепенно рефакторит старый код, обычно перед добавлением новой функциональности. Как и в случае с тестированием, рефакторинг старого кода проводят только по необходимости. При этом команде стоит сформулировать долгосрочные цели переработки кода и постепенно достигать их.
Команда должна перейти на тесное взаимодействие с заказчиком. На этом этапе важно донести до него преимущества работы в одной команде с разработчиками и интегрировать его в команду.
Роль менеджеров при переходе на XP — контролировать, чтобы все члены команды работали по новым правилам. Менеджер проекта принимает решение, когда расстаться с членом команды, который не справляется с работой в новых условиях, или найти нового и правильно интегрировать его в работу.
Преобразования в разработке начинаются с организации рабочих мест для программирования парами. Следующая задача — программировать парами большую часть рабочего времени, как бы тяжело это не давалось разработчикам.
По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.
Не так просто найти информацию о командах, которые применяют XP, но есть и те, кто афиширует, что именно эта методология — причина их успеха. Пример экстремального программирования — компания Pivotal Software, Inc.
Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.
Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.
Книги по экстремальному программированию от создателя методологии Кента Бека. Начните с первой, в ней с примерами описывается концепция XP и обосновываются ее преимущества. Позднее автор выпустил еще несколько книг, где подробно описал отдельные практики XP.
Мартин Фаулер — программист и соавтор методологии экстремального программирования. В книге описаны основные принципы и приемы рефакторинга, а также 70 практических методов рефакторинга с примерами.
Так как экстремальное программирование стремится к чистому и легко поддерживаемому коду, к списку книг можно отнести все издания, которые учат программировать лучше.
Команды, работающие над проектами по методологии XP, применяют таск менеджеры и сервисы для agile проектов. На рынке много таких продуктов, мы рассмотрим несколько примеров.
Бесплатный менеджер задач с открытым кодом. Основные функции: работа сразу над несколькими проектами, гибкая система управления задачами, диаграмма Ганта, контроль времени, работа с документацией, создание задач через почту и др.
Простой удобный сервис для совместной работы над проектами. Включает таск менеджер, доску сообщений, встроенный чат, файлохранилище, календарь
Мощный сервис, разработанный специально для разработчиков agile проектов. Объединяет баг-трекер и сервис для управления проектами. Много функций плюс синхронизация с другими сервисами. Решения для команд разных размеров.
Безопасный сервис для работы над проектами. Позволяет ставить задачи и контролировать процесс выполнения, вести переписку по задаче, настраивать фильтры, учитывать расход времени и финансов, работать с файлами.
Экстремальное программирование — гибкая методология, в центре которой качественный работоспособный код с простой архитектурой. Ее предназначение — снизить уровень неопределенности в проектах и по-настоящему гибко реагировать на изменения требований к продукту.
Немногие компании рискуют работать по чистому XP, но его практики разработки — самые популярные в agile проектах. И это весомый довод в пользу их эффективности.
Авторы методологии советуют одну за другой осваивать практики XP, параллельно решая проблемы проекта. Если вы видите эффект, продолжайте в том же духе.
Представленные результаты и исследования подтверждают, что применение искусственного интеллекта в области экстремальное программирование имеет потенциал для революции в различных связанных с данной темой сферах. Надеюсь, что теперь ты понял что такое экстремальное программирование, extreme programming, xp, парное программирование, группове программирование, mob-программирование и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем