eXtreme Programming: Overview

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

Для чего

Extreme Programming очень хорошо применима для small-medium команд (от 2 до 10 человек), в процессе разработки которых присутствует неопределенность или потребность в решении быстро меняющихся требований. Длина цикла разработки составляет от 1 до 3 недель.

Почему

Методология содержит в название слово “Extreme” в силу того, что определенные принципы и практики превозносятся до экстремального уровня, вот одни из них:

• Review кода проводится на протяжении всей жизнедеятельность продукта;
• Написание тестов проводится на протяжении всей жизнедеятельность продукта; тесты пишут все, как разработчики, так и заказчики;
• Redesign, refining the architecture, refactoring проводится на протяжении всей жизнедеятельности продукта;
• Разработка ведется с принятием самых простых решений, постоянное упрощение дизайна при сохранение функциональности;
• CI/CD практики, запуск тестов по несколько раз за день;
• Планирование происходит с использованием очень маленьких шагов (не более 1 дня).

Как

В перспективе использования подхода XP:

• Разработчики работают только над задачами, которые имеют высокую важность для заказчика, которые необходимо выполнить “здесь и сейчас”;
• Заказчики и менеджеры максимально вовлечены в процесс реализации продукта и принимают в нем непосредственное участие. Через определенные промежутки времени они могут видеть определенный результат, а также могут принимать решение об изменении требований или направления развития продукта в середине разработки.

В общем, XP направлена на уменьшение рисков, увеличение отзывчивости на buiseness изменения, увеличение продуктивности и добавляет некий азарт в процесс разработки. Основными “китами” разработки являются короткие циклы разработки, инкрементальный подход к планированию и реализации. Тестирование ставится в основу разработки, а вербальное общение налаживает контакт между участниками.

Решения

Основные проблемы, которые могут быть решены с помощью XP:

• Увеличение сроков разработки, приводящее к невыполнению обязательств перед заказчиков в срок. XP использует короткие циклы разработки, поэтому в конце каждого цикла есть возможность корректировки задач и решений. В XP используется подход client driven development, согласно которому самые важные для клиента задачи выполняются в первую очередь.
• Отмена проекта на поздних стадиях. Из-за коротких release циклов, самые значимые для buiseness’а решения попадают в production раньше всего. Если buiseness понимает, что определенный функционал им не нужен или вообще пропала необходимость в продукте, то такой вывод делается уже на ранних стадиях реализации.
• Увеличение сложности системы. Увеличение стоимости изменений, приводящее к отказу от продукта

Практики

В основе XP заложены практики test first и simplify all. Поэтому система всегда находится в актуальном и рабочем состоянии.

• Высокая степень ошибок. В XP тесты пишут как developers (function-by-function), так и люди из buiseness (program-feature-by-program-feature).
• Недопонимая между buiseness и development. Сотрудники из buiseness являются неотъемлемой частью процесса разработки.
• Невозможность системы быстро меняться под нужны buiseness’a. Короткие циклы разработки и работа в стиле “делаем только то, что нужно” позволяет внедрять изменения быстро и эффективно.
• Перенасыщенный функциональностью продукт, большая часть возможностей не используется. XP выполняет только highest priority tasks.
• Смена коллектива. После формирования task’ов разработчики сами решают какие задачи они выполнять и определяют время, необходимо для выполнения. Задачи могут перераспределяться между участниками команды. Живое общение позволяет избавиться от чувства одиночества и дает уверенность в значимости собственного мнения или решения.

Контролируем самое важное

Основные неопределенности разработки, которые необходимо контролировать:

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

Существует взаимосвязь между всеми переменными, но не столь явная как может показаться на первый взгляд. Увеличение бюджета может положительно сказаться на скорости разработки — лучшее оборудование, офис или более квалифицированные сотрудники. Но нельзя нанять больше разработчиков и надеется, что разработка пойдет быстрее. Как гласит пословица: “Девять женщин не могут родить ребенка за месяц”.

Качество

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

Объем работы

Очень важной переменной в разработке является объем работы. Стоит оговориться, что под этим объемом подразумевается избыточное ее количество. Задачей XP и менеджмента в том числе является уничтожение этой переменной. Большинство разработчиков прекрасно знают, что заказчик не всегда знает точно, что он хочет. Из-за неналаженного общения или подхода между разработчиками и заказчиками, мысли последних могут быть восприняты не совсем правильно, и в кУпе с неопределенностью самих хотелок получается гремучая смесь. В результате пустая трата времени и денег. XP предлагает две основные стратегии в решении проблемы: (1) совместная практика разработчиков и заказчиков в определении estimates и получении feedback’a. За счет коротких циклов релиза feedback получается как можно раньше; (2) самые важные задачи для заказчика выполняются в первую очередь — снижается риск позднего отказа от функционала и работы вхолостую.

Принципы

Основные принципы XP:

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

С одной стороны XP кажется нам идеальным подходом для разработки программных продуктов. Конечно же такая методология не лишена недостатков. Я считаю, что основным недостатком, хоть и непрямым, является высокая требовательность к коммуникационным скилам участников команды. У людей может попросту нет такого желания. XP работает только тогда, когда соблюдаются все принципы. Такой подход перестает работать для команд более чем 10 человек, так как говорить приходится больше, чем работать. Ну а возможность постоянно говорить с заказчиком и просить его заниматься тестированием продукта или использовать что-то вроде BDD (Behaviour Drive Development) — это из ряда фантастики.

Если ваша команда состоит из людей-единомышленников, объединенных желанием работать “на максималках”, то такой подход точно для вас.