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. Спілкування — команда розмовляє. Щодня. Про роботу, дизайн, перешкоди. Віч-на-віч, коли можливо. Силоси — це ворог.
2. Простота — робіть найпростішу річ, яка могла б працювати. Складність можна додати пізніше, якщо вона вам справді знадобиться. Імовірно, не знадобиться.
3. Зворотний зв’язок — від коду (тести), від команди (парне програмування, рецензії), від користувача (часті релізи). Отримуйте його швидко.
4. Сміливість — говоріть правду про прогрес, оцінки та дизайн. Викидайте код, який не працює. Рефакторте те, що вас стримує.
5. Повага — кожен у команді — а тепер і кожен агент у команді — приносить цінність. Ставтеся одне до одного відповідно.

Практики

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 несуть бали і є єдиним, що «рахується» до швидкості. Це змушує вас нарізати роботу на цінність, спостережувану користувачем.
• Bugs не оцінюються (нуль). Дефекти не приносять кредиту, через що вартість переробок стає видимою, а не винагороджується.
• Chores також не оцінюються — необхідна робота без прямої користі для користувача (інфраструктура, рефакторинг, налаштування). Тримання їх на нулі тисне на команду об’єднувати їх із функціями де тільки можливо, щоб рамка цінності залишалася чесною.
• Releases — це маркери з нулем балів, що використовуються для закріплення віх і дозволяють інструменту спрогнозувати дату.

Поведінковий ефект — ось що має значення: коли баги та рутина не дають балів, команда природно прагне виражати роботу як функціональність, орієнтовану на користувача, і гостро усвідомлює вартість дефектів. Це планувальна дисципліна, закодована в моделі даних.

Єдиний упорядкований беклог

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

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

Власник продукту володіє порядком згори вниз, а інваріант полягає в тому, що верх беклогу завжди є найважливішим і найкраще специфікованим, а ясність законно зменшується в міру руху вниз. Історія близько до верху з розмитими критеріями прийняття — це планувальний баг. Icebox дозволено бути кладовищем; Backlog — ні.

Автоматичне планування на основі швидкості

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

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

Винагорода в тому, що прогноз дати релізу стає обчисленням, а не переговорами, і розмова зі стейкхолдерами зміщується від «ти можеш зобов’язатися зробити X до п’ятниці» до «за поточної швидкості цей реліз вийде приблизно в дату Y — ось компроміс обсягу/дати».

Життєвий цикл історії та цикл прийняття

Скінченний автомат станів — це Start → Finish → Deliver → Accept / Reject. Критичний стан — це Deliver: інженер позначає історію як доставлену, але вона не є завершеною, доки власник продукту явно не прийме її відповідно до критеріїв прийняття — або відхилить її, повернувши назад. Це вбудовує цикл зворотного зв’язку з клієнтом у кожну окрему історію, замість того щоб відкладати прийняття до демонстрації наприкінці спринту.

Критерії прийняття мають бути в історії до її початку, бажано у формі Given/When/Then, щоб вони безпосередньо відповідали приймальним тестам. INVEST — це перевірка на здоровий глузд щодо того, чи добре сформульована історія:

• Independent — можна випустити без інших історій.
• Negotiable — фіксує намір, а не заморожену специфікацію.
• Valuable — для користувача чи стейкхолдера.
• Estimable — команда може оцінити розмір.
• Small — комфортно вписується в ітерацію.
• Testable — має критерії прийняття, які можна перевірити.

Ритм

Планувальні церемонії легкі та регулярні:

• Щотижнева Iteration Planning Meeting, щоб оцінити нові історії та закріпити критерії прийняття вгорі беклогу.
• Короткий щоденний стендап, зосереджений на потоці та блокерах.
• Ретроспектива для кожної ітерації, щоб скоригувати процес.

Ітерації зазвичай один або два тижні — достатньо короткі, щоб погану оцінку було дешево виявити.

Інженерні практики, які змушують планування працювати

Планування у стилі трекера — це видима половина XP; вона розвалюється без інженерної половини.

• Test-first / TDD та реальний набір приймальних тестів — ось що дає змогу «delivered» означати щось.
• Безперервна інтеграція та малі, часті релізи тримають час циклу коротким, тож швидкість стабільна, а не нерівна.
• Парне програмування (або сильна рецензія) тримає кількість незавершеної роботи низькою — завершуй, перш ніж починати — що є найбільшим важелем впливу на час циклу.
• Доступний власник продукту — ось що не дає циклу прийняття/відхилення застопоритися.

Антипатерни, на які варто звертати увагу

Повторювані невдачі:

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

Будь-що з цього тихо перетворює емпіричну систему назад на бажане планування. Трекер не може зупинити вас від цього; він може лише зробити це видимим. Дивіться на свою колонку Delivered наприкінці кожної ітерації — якщо вона зростає, це ваш сигнал.

XP з East Agile Tracker

Трекер — це поверхня планування, якої XP-команди хотіли ще з часів Pivotal Tracker. Кожна концепція відображається безпосередньо:

User Stories → Stories

User-історії XP — це історії East Agile Tracker. Пишіть їх типом Feature. Використовуйте опис для розмови; використовуйте коментарі для поточного обговорення. Критерії прийняття належать до опису.

Planning Game → Дошка

Planning Game у XP — це розмова між бізнесом і командою про пріоритет та розмір. У East Agile Tracker:

1. Людина від продукту пише історії в Backlog і впорядковує їх за пріоритетом.
2. Команда оцінює функції в балах (шкала Fibonacci чи East Agile).
3. Система автоматично планує ітерації на основі швидкості.
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 обчислює швидкість автоматично — середнє за останні ітерації, налаштовувана стратегія — і використовує її для автопланування місткості наступної ітерації.

Acceptance Tests → Reviews

Рецензії історій у трекері відображаються на прийняття. Призначте рецензента (клієнта, власника продукту чи навіть агента, що діє як такий). Вони схвалюють або відхиляють. Відхилення повертає історію до Started.

Pair Programming → Співволодіння

XP-команди працюють у парах над кодом. У трекері це проявляється як кілька власників історії. Призначте обох членів пари історії; обидва імені з’являться на картці.

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

XP було написано до того, як AI-агенти могли осмислено робити внесок у програмне забезпечення. Ми вважаємо, що це найважливіше оновлення XP за двадцять п’ять років.

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

Цінності XP все ще діють. Спілкування: агенти спілкуються, читаючи потік подій і публікуючи коментарі. Простота: агенти обмежені ролями, які ви їм надаєте. Зворотний зв’язок: кожна дія агента є в журналі аудиту, негайно придатна для перегляду. Сміливість: будьте чесними щодо того, що ваші агенти зробили правильно, а що ні. Повага: товариші-агенти приносять цінність — визнавайте її.

Ми не саджаємо агентів усередину трекера займатися кодуванням. Ми даємо поверхню планування людям і агентам, які працюють разом. Ви приводите кодувального агента — Claude Code, Codex, власного — і під’єднуєте його до трекера через API. Агент бере історії, виконує роботу, коментує, переводить. Ви переглядаєте слід і приймаєте.

Це Інклюзивне Agile-планування. Це XP — з командою, яку він насправді має.

Подальше читання

• Extreme Programming Explained — основоположна книга Кента Бека, 1999.
• Маніфест Agile — звідки почалося сімейство.
• Agile-розробка — ширша картина.
• Інструкція з експлуатації — практичний посібник із трекера.
• Посібник з API — підключення вашого кодувального агента.