eXtreme Programming

eXtreme Programming — обычно просто XP — это самый требовательный член agile-семейства. East Agile Tracker создан прежде всего для XP; всё остальное вытекает из этого.

На этой странице рассматривается, что такое XP, почему он работает и как практиковать его, используя трекер в качестве поверхности планирования.

Что такое XP

XP был создан Кентом Беком в конце 1990-х. Первая книга — Extreme Programming Explained: Embrace Change — была опубликована в 1999 году. Всё началось, как и многое другое, с разочарованной команды, пытавшейся выпустить систему расчёта зарплаты в Chrysler.

Ставка XP заключается в том, что правильный способ справиться с неопределённостью в программном обеспечении — это делать то, что работает, и делать это чаще. Тестировать? Тестировать всё время. Интегрировать? Интегрировать ежечасно. Говорить? Говорить постоянно. Планировать? Планировать каждую итерацию и перепланировать по мере того, как вы узнаёте новое.

«XP — это лёгкая методология для малых и средних команд, разрабатывающих программное обеспечение в условиях расплывчатых или быстро меняющихся требований». — Кент Бек

Пять ценностей

XP называет пять ценностей, на которых держится всё остальное:

1. Communication (коммуникация) — Команда разговаривает. Ежедневно. О работе, дизайне, препятствиях. Лицом к лицу, когда это возможно. Изоляция — враг.
2. Simplicity (простота) — Делайте простейшее, что только может сработать. Сложность можно добавить позже, если она действительно понадобится. Скорее всего, не понадобится.
3. Feedback (обратная связь) — От кода (тесты), от команды (парное программирование, ревью), от пользователя (частые релизы). Получайте её быстро.
4. Courage (смелость) — Говорите правду о прогрессе, оценках и дизайне. Выбрасывайте код, который не работает. Рефакторите то, что вас тормозит.
5. Respect (уважение) — Каждый в команде — а теперь и каждый агент в команде — вносит ценность. Относитесь друг к другу соответственно.

Практики

XP знаменит своими двенадцатью изначальными практиками, организованными в четыре области:

Планирование

• Planning Game — Команда и заказчик планируют вместе: что будет дальше, в каком порядке, насколько велик каждый кусок.
• Small Releases — Выпускайте часто. Дни, а не месяцы. Получайте обратную связь по чему-то конкретному.
• User Stories — Требования — это разговоры, зафиксированные как короткие истории с точки зрения пользователя. «Как пользователь, я хочу X, чтобы Y».

Проектирование

• Simple Design — Простейший дизайн, который проходит тесты и выражает каждую необходимую концепцию. Не более.
• Refactoring — Улучшайте дизайн уже работающего кода. Постоянно.
• System Metaphor — Общая история о том, как работает система, используемая для согласованности проектных решений.

Кодирование

• Pair Programming — Два разработчика, одна клавиатура. Один ведёт, один направляет. Часто меняйтесь.
• Collective Code Ownership — Любой может улучшить любой код. Без вотчин.
• Continuous Integration — Интегрируйте и тестируйте код много раз в день. Ловите поломки немедленно.
• Coding Standards — Согласованный стиль, чтобы код читался так, будто его написал один человек.

Тестирование

• Test-Driven Development (TDD) — Сначала напишите падающий тест, затем код, который заставит его пройти.
• Acceptance Tests — Заказчик определяет в коде или исполняемой форме, что означает «завершено» для каждой истории.

Почему XP работает

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

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

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

Дисциплинированная модель историй

East Agile Tracker кодирует конкретную теорию планирования. Относитесь к этому разделу как к руководству по эксплуатации того, почему модель данных выглядит именно так, — и как к полевому руководству о том, что делать (и не делать) на практике.

Почему четыре типа историй имеют значение

Всё является историей, но есть четыре вида, и различие между ними и есть весь смысл:

• Features (фичи) несут баллы и являются единственным, что «засчитывается» в velocity. Это заставляет вас нарезать работу на наблюдаемую пользователем ценность.
• Bugs (баги) без баллов (ноль). Дефекты не приносят зачётных баллов, что делает стоимость переработки видимой, а не вознаграждаемой.
• Chores (рутинные задачи) тоже без баллов — необходимая работа без прямой пользовательской ценности (инфраструктура, рефакторинги, настройка). Сохранение их на нуле подталкивает команду объединять их с фичами везде, где это возможно, чтобы фрейминг ценности оставался честным.
• Releases (релизы) — это маркеры с нулём баллов, используемые для закрепления вех и позволяющие инструменту спрогнозировать дату.

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

Единый упорядоченный бэклог

Три зоны, одно правило.

• Icebox — это пул неприоритизированных идей.
• Backlog — это строго упорядоченный список с единым приоритетом — без ничьих, без «P1/P1/P1».
• Зона Current содержит активную итерацию(и).

Владелец продукта владеет порядком сверху вниз, и инвариант в том, что верх бэклога всегда самый важный и наиболее проработанный, причём ясность закономерно снижается по мере движения вниз. История у вершины с расплывчатыми критериями приёмки — это баг планирования. Icebox имеет право быть кладбищем; Backlog — нет.

Автоматическое планирование на основе velocity

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

• Вы оцениваете только фичи, используя относительные баллы (Fibonacci 1/2/3/5/8 или нашу более плотную 0/1/2/3), а не часы. Оценка — это разговор о размере, а не обещание.
• Вы не играете с velocity. Раздувание баллов, чтобы «выглядеть быстро», или оценка рутинных задач ломают прогноз, делающий всю систему честной. Velocity — это измерительный инструмент, и вы не подкручиваете собственный инструмент.

Награда в том, что прогноз даты релиза становится вычислением, а не переговорами, и разговор со стейкхолдерами смещается от «сможете ли вы обязаться сделать X к пятнице» к «при текущей velocity этот релиз выйдет примерно к дате Y — вот компромисс между объёмом и датой».

Жизненный цикл истории и цикл приёмки

Конечный автомат состояний — это Start → Finish → Deliver → Accept / Reject. Критическое состояние — Deliver: инженер помечает историю как доставленную, но она не считается завершённой, пока владелец продукта явно не примет её по критериям приёмки — или не отклонит, вернув обратно. Это встраивает цикл обратной связи с заказчиком в каждую отдельную историю, а не откладывает приёмку до демонстрации в конце спринта.

Критерии приёмки должны быть на истории до того, как её начали, в идеале в форме Given/When/Then, чтобы они напрямую отображались на приёмочные тесты. INVEST — это проверка на то, хорошо ли сформирована история:

• Independent (независимая) — может быть выпущена без других историй.
• Negotiable (обсуждаемая) — захватывает намерение, а не замороженную спецификацию.
• Valuable (ценная) — для пользователя или стейкхолдера.
• Estimable (оцениваемая) — команда может оценить её размер.
• Small (малая) — комфортно помещается в итерацию.
• Testable (тестируемая) — имеет критерии приёмки, которые можно проверить.

Ритм

Церемонии планирования лёгкие и регулярные:

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

Итерации обычно длятся одну или две недели — достаточно коротко, чтобы плохую оценку было дёшево обнаружить.

Инженерные практики, которые заставляют планирование работать

Планирование в стиле трекера — это видимая половина XP; оно рассыпается без инженерной половины.

• Test-first / TDD и реальный набор приёмочных тестов — это то, что позволяет «delivered» что-то значить.
• Непрерывная интеграция и маленькие, частые релизы сохраняют время цикла коротким, чтобы velocity была стабильной, а не рваной.
• Парное программирование (или сильное ревью) держит объём незавершённой работы низким — заканчивайте, прежде чем начинать — что является самым большим рычагом влияния на время цикла.
• Доступный владелец продукта — это то, что не даёт циклу приёмки/отклонения застопориться.

Антипаттерны, за которыми стоит следить

Повторяющиеся провалы:

• Отношение к Backlog как к парковке вместо настоящего порядка приоритетов.
• Оценка багов и рутинных задач в баллах, чтобы velocity выглядела лучше.
• Несение огромных историй, которые не могут завершиться за итерацию. Разбивайте, пока каждая не станет независимо поставляемой.
• Позволение историям накапливаться в Delivered, потому что никто не принимает.

Любой из этих пунктов тихо превращает эмпирическую систему обратно в планирование на основе пожеланий. Трекер не может помешать вам делать это; он может только сделать это видимым. Смотрите на свою колонку Delivered в конце каждой итерации — если она растёт, это ваш сигнал.

XP с East Agile Tracker

Трекер — это поверхность планирования, которую XP-команды хотели со времён Pivotal Tracker. Каждая концепция отображается напрямую:

User Stories → Stories

XP-истории пользователей — это истории East Agile Tracker. Пишите их в типе Feature. Используйте описание для разговора; используйте комментарии для текущего обсуждения. Критерии приёмки место в описании.

Planning Game → Доска

Planning Game в XP — это разговор между бизнесом и командой о приоритете и размере. В East Agile Tracker:

1. Человек со стороны продукта пишет истории в Backlog и упорядочивает их по приоритету.
2. Команда оценивает фичи в баллах (шкала Fibonacci или East Agile).
3. Система автоматически планирует итерации из velocity.
4. Команда начинает истории с вершины колонки Current.

Вот и всё. «Игра» живёт в разговоре; трекер просто ведёт счёт.

Small Releases → Releases (тип истории)

XP говорит выпускать часто. Release — один из четырёх типов историй в East Agile Tracker. Создавайте релиз для каждой вехи поставки; перетаскивайте его в итерацию, в которой он выходит. Релизы пропускают Started/Finished/Delivered и идут прямо в Accepted, когда вы выпускаете.

Continuous Integration → Конечный автомат состояний истории

Конечный автомат состояний — это не CI как таковой (это ваша система сборки) — но путь Finished → Delivered → Accepted отражает цикл приёмки заказчиком, который описывает XP. Завершите работу, доставьте её заказчику, примите, когда подтверждено, что она работает.

Velocity → «вчерашняя погода»

XP называет это вчерашней погодой: сколько вы сделали в прошлой итерации — это лучший прогноз того, сколько вы сделаете в этой. East Agile Tracker рассчитывает velocity автоматически — среднее за недавние итерации, настраиваемая стратегия — и использует её для автопланирования ёмкости следующей итерации.

Acceptance Tests → Reviews

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

Pair Programming → Совместное владение

XP-команды программируют в парах. В трекере это проявляется как несколько владельцев у истории. Назначьте обоих участников пары на историю; оба имени появятся на карточке.

XP с агентами — новая практика

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

В нашей практике — и для чего создан трекер — агент — это именованный член XP-команды. У него есть собственная роль, собственный партнёр по паре (человек или агент) и собственный журнал аудита. Он может делать всё, что может член команды-человек в поверхности планирования: оценивать, владеть историями, комментировать, переводить, принимать ревью.

Ценности XP по-прежнему действуют. Коммуникация: агенты общаются, читая поток событий и публикуя комментарии. Простота: агенты ограничены ролями, которые вы им предоставляете. Обратная связь: каждое действие агента находится в журнале аудита, немедленно проверяемое. Смелость: будьте честны о том, что ваши агенты сделали правильно, а что нет. Уважение: коллеги-агенты вносят ценность — признавайте её.

Мы не помещаем агентов внутрь трекера, чтобы они кодировали. Мы даём поверхность планирования людям и агентам, работающим вместе. Вы приводите кодящего агента — Claude Code, Codex, своего собственного — и подключаете его к трекеру через API. Агент берёт истории, делает работу, комментирует, переводит. Вы проверяете след и принимаете.

Это и есть инклюзивное agile-планирование. Это XP с той командой, которая у него действительно есть.

Дополнительное чтение

• Extreme Programming Explained — Основополагающая книга Кента Бека, 1999.
• Agile-манифест — Где началось семейство.
• Agile-разработка — Более широкая картина.
• Инструкция по эксплуатации — Практическое руководство по трекеру.
• Руководство по API — Подключение вашего кодящего агента.