Попробовать бесплатно
Гибкие2 темы

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

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

9 мин чтенияуровень: продвинутыйобновлено
КРАТКО
  • Подход появился в конце девяностых у Кента Бека и описывает инженерную сторону работы
  • Ядро практик: тесты вперёд, парная работа, непрерывная сборка, рефакторинг, простой дизайн
  • Практики поддерживают друг друга: половина набора работает заметно хуже целого
  • Смысл всех практик один — сделать изменение кода дешёвым, чтобы гибкость стала возможной
01 · ЧТО ЭТО

Что такое XP

Кент Бек собрал подход в конце девяностых на проекте расчёта зарплаты в Chrysler и описал его в книге 1999 года. Слово «экстремальное» означало доведение известных хороших практик до предела: если проверка кода полезна, проверяйте непрерывно; если тесты полезны, пишите их до кода.

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

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

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

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

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

ПОДХОДИТ, КОГДА
  • Код меняется постоянно, и цена ошибки в продуктивной среде высока
  • Команда небольшая и сидит достаточно близко для постоянного общения
  • Есть возможность автоматизировать тесты и сборку
  • Руководство готово к тому, что часть времени уходит на качество кода
НЕ ПОДХОДИТ, КОГДА
  • Работа не связана с кодом: практики теряют смысл почти полностью
  • Код меняется редко и живёт годами без правок
  • Автоматизировать проверку невозможно: наследованная система без тестового окружения
  • Ожидается рост скорости в первый же месяц: практики окупаются позже
02 · АРТЕФАКТЫ И СОБЫТИЯ

Что появляется в работе

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

ЭЛЕМЕНТ

Истории

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

владелец: Заказчик и команда
ЭЛЕМЕНТ

Набор автоматических тестов

Главный актив команды. Позволяет менять код смело: если тесты зелёные, поведение сохранилось.

владелец: Вся команда
ЭЛЕМЕНТ

Стандарт кода

Соглашение о том, как выглядит код команды. Нужен, потому что код общий и его читают все.

владелец: Вся команда
ЭЛЕМЕНТ

Быстрая сборка

Полная сборка с тестами за считанные минуты. Медленная сборка обходится, и вся конструкция рассыпается.

владелец: Вся команда
События
СОБЫТИЕЧАСТОТА И ДЛИТЕЛЬНОСТЬУЧАСТНИКИЧЕМ ЗАКАНЧИВАЕТСЯ
Недельное планирование1–2 чкоманда и заказчикистории на неделю
Квартальное планированиеполднякоманда и заказчиктемы квартала и крупные истории
Ежедневная сверка10–15 минкомандапары на день, препятствия
Смена парпо ходу дняразработчикизнание расходится по команде
03 · ВНЕДРЕНИЕ

С чего начать

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

  1. 1Ускорьте сборкуПока полная сборка идёт полчаса, ни непрерывная интеграция, ни тесты вперёд не приживутся. Цель — минуты.первый месяц
  2. 2Включите непрерывную сборкуКаждое изменение собирается и прогоняется автоматически. Сломанная сборка чинится немедленно и имеет приоритет над новой работой.первый месяц
  3. 3Начните писать тесты вперёд на новом кодеНе переписывайте старое: возьмите правило «новый код приходит с тестом». Через квартал покрытие вырастает само в тех местах, где идёт работа.второй-третий месяц
  4. 4Введите разбор кода вдвоёмНачните с сложных мест и с обучения новичков. Постоянная парная работа — следующая ступень, и к ней команды приходят по-разному.второй-третий месяц
  5. 5Договоритесь о рефакторингеУлучшение кода происходит по ходу работы над задачей. Отдельный проект по рефакторингу почти всегда отменяют первым.третий месяц
  6. 6Заведите запас в планеЧасть ёмкости недели остаётся незанятой. Без запаса первая же срочная задача съедает тесты и рефакторинг.постоянно
04 · МЕТРИКИ

Что считать

Время сборкиОт изменения до готового результата с тестами. Ключевая величина: от неё зависит, будут ли практики применяться.Медиана длительности полной сборки за неделю.
Время красной сборкиСколько сборка остаётся сломанной. Долгие периоды означают, что её починка не в приоритете.Суммарное время в состоянии сбоя за период.
Доля кода под тестамиСмотрят направление: рост в местах активной работы важнее общего процента.Покрытие по модулям, сравнение за квартал.
Дефекты после выпускаГлавный практический результат набора практик.Ошибки, найденные пользователями, к числу выпусков.
Время до выпускаОт готовности изменения до его появления у пользователя.Медиана от завершения работы до выпуска.
05 · ТИПИЧНЫЕ ОШИБКИ

Где обычно ломается

Берут одну практику из десяти

ЧТО ДЕЛАТЬПроверьте, на что она опирается. Рефакторинг без тестов опасен, тесты без быстрой сборки устаревают. Начинайте с фундамента: скорость сборки и непрерывная интеграция.

Тесты пишут после кода и потом

ЧТО ДЕЛАТЬВведите правило «новый код приходит с тестом» и держите его без исключений. Отложенные тесты не пишутся никогда: у команды всегда есть более срочная задача.

Сборка идёт полчаса

ЧТО ДЕЛАТЬВложитесь в скорость до всего остального. Медленную сборку разработчики обходят локальными приёмами, и непрерывная интеграция превращается в декларацию.

Парную работу вводят приказом

ЧТО ДЕЛАТЬНачните с добровольных пар на сложных задачах и с обучения новичков. Принудительная постоянная пара вызывает сопротивление и даёт худший результат, чем её отсутствие.

Рефакторинг выносят в отдельный проект

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

План заполняют под завязку

ЧТО ДЕЛАТЬОставляйте запас ёмкости на неделю. Без него срочная задача съедает время, которое шло на качество, и практики отмирают по одной.
07 · В SHTAB

Что из этого живёт в Shtab

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

  • 01Истории задачами с критериями приёмки в чек-листе шаблона.
  • 02Недельный цикл — повторяющееся планирование и понятный горизонт списка.
  • 03Парная работа видна назначением двух исполнителей на задачу.
  • 04Запас ёмкости поддерживается ограничением незавершённой работы по колонке.
  • 05Отдельная метка технического долга не даёт ему потеряться среди историй.
  • 06Сводный отчёт показывает, сколько недель подряд запас съедался срочным.
08 · FAQ

Частые вопросы

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

Соберите свой процесс в Shtab

Доски и статусы, оценка трудозатрат, дерево целей, отчёты и трекер времени — в одном инструменте.