Prg67.ru

Онлайн вебинары
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Унифицированный процесс разработки и экстремальное программирование

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

Экстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционный метод разработки ПО «снизу вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method) . В группу «живых» методов входят, помимо экстремального программирования , методы SCRUM, DSDM ( Dynamic Systems Development Method , метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки [5], появившемся в 2000 году.

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

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

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

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

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).

  • Живое планирование (planning game)

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

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

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

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

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

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

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

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

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

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

Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

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

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

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

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

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

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

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

XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System , разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики [6,7,8]. Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.

Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Свободный доступ к коду

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

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

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

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

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

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

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

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

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

Как работает команда

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

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

Читать еще:  Язык программирования на андроид

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

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

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

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

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

Заключение

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

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) — это один из фреймворков Agile подхода, который позволяет создавать программное обеспечение высокого качества, при этом поддерживать высокое качество жизни у членов команды разработки.

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

Давайте разберем этот фреймворк более детально.

  • Таблица расчета юнит–экономики стартапа и PnL компаний.
  • Постеры ведущих подходов к управлению — Agile, Scrum, LeanKanban.
  • Постеры методов запуска стартапов — Lean Startup и Customer Development.
  • ТОП 20 основополагающих книг по менеджменту и стартапам.
  • 100+ эссе по управлению разработкой новых продуктов.
  • Карта компетенций руководителя стартапа и digital–продуктов.
  • . и еще сотня полезного материала и инструментов. Бесплатно.

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

В экстремальном программировании выделяются пять ценностей. Они — основа, на котором держится этот фреймворк.

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

Обратная связь [Feedback]

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

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

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

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

Читать еще:  Для чего нужен язык программирования питон

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

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

  • Lean Startup, Customer Development и Юнит–экономика.
  • Как получить деньги с первых продаж до запуска бизнеса.
  • Как формулировать сильные бизнес–идеи и гипотезы.

  • Вы приобретёте 14 управленческих компетенций, которыми владеют востребованные руководители в крупных компаниях.
  • Вы получите собственный кейс по бережливому запуску нового продукта — а при желании, веб–сайт вашего стартапа, с правильно упакованной идеей и оффером, а также самое главное — трафик, продажи и деньги.
  • Вы освоите основные инструменты и принципы работы крутых руководителей на должностях Chief Product Owner, Scrum Master, Agile Coach и Chief Executive Officer.
  • При получении всех навыков из карты компетенций вы получите сертификат «Lean Startup Professional».

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

В XP довольно много практик и рекомендаций, как организовать рабочий процесс.

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

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

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

  • Основы Agile–мышления, фреймворка Scrum и Kanban–метода.
  • Будет полезно предпринимателям, менеджерам и профессионалам, которые хотят быть востребованными на рынке.

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

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

Идея такого метода в том, чтобы ускорить работу и сделать её более сфокусированной.

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

Целостная команда

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

У вас может быть “Заказчик” (Customer), который определяет требования и то, что нужно сделать. Хорошо, если это конечный пользователь, который разбирается в том, что нужно. Также могут быть программисты, тестировщики, аналитики, менеджеры, коучи.

Ни одна из этих ролей не является обязательной — скорее такое распределение возможно.

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

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

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

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

Так с одной стороны поощряется коммуникация, с другой — дается безопасное пространство.

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

«Энергичная» работа (Energized Work)

Хотя эта практика про энергичность, она значит не то, чем может показаться с первого раза.

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

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

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

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

Пользовательские истории

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

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

Также User Story помогают собирать обратную связь, поскольку на этом языке проще говорить с пользователем.

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

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

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

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

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

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

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

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

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

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

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

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

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

А бизнес и клиент максимально быстро получают ценность.

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

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

Это улучшает качество кода и снижает количество дефектов.

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

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

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

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

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

Extreme Programming исповедует другой принцип: «Если это больно — делай это чаще».

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

Заключение

Как видно из перечисленного, основу XP составляют ценности и практики.

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

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

Ссылка на основную публикацию
Adblock
detector
×
×