•     •   11 min read

Екстремальне
програмування
(XP) не для людей зі слабкими
нервами

Екстремальне програмування або XP eXtreme Programming — гнучка методологія розробки програмного забезпечення. Як і в інших agile методологій, у неї є особливі інструменти, процеси і ролі. Хоча автор XP не придумав нічого нового, а взяв кращі практики гнучкої розробки і посилив до максимуму. Тому програмування і називається екстремальним.

Автор методики — американський розробник Кент Бек. В кінці 90‑х років він керував проектом Chrysler Comprehensive Compensation System і там вперше застосував практики екстремального програмування. Свій досвід і створену концепцію він описав у книзі Extreme Programming Explained, опублікованій в 1999 році. Вслід за нею були випущені інші книги, в яких детально описувалися практики XP. До становлення методології причетні також Уорд Каннингем, Мартін Фаулер та інші.

XP відрізняється від інших гнучких методологій тим, що застосовується тільки в області розробки програмного забезпечення. Воно не може бути використане в іншому бізнесі або повсякденному житті, як scrum, kanban або lean.

Мета методики XP — впоратися з постійно мінливими вимогами до програмного продукту і підвищити якість розробки. Тому XP добре підходить для складних і невизначених проектів.

Методологія XP будується навколо чотирьох процесів: кодування, тестування, дизайну та слухання. Крім того, екстремальне програмування має цінності: простоту, комунікацію, зворотний зв’язок, сміливість і повагу.

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

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

1. Вся команда

Усі учасники проекту з застосуванням XP працюють як одна команда. У неї обов’язково входить представник замовника, краще, якщо це буде реальний кінцевий користувач продукту, що розбирається в бізнесі. Замовник висуває вимоги до продукту і розставляє пріоритети в реалізації функціональності. Йому можуть допомагати бізнес-аналітики. З боку виконавців у команду входять розробники і тестувальники, інколи коуч, що направляє команду, і менеджер, який забезпечує команду ресурсами. 

2. Гра в планування

Планування в XP проводять у два етапи — планування релізу і планування ітерацій.

На плануванні релізу команда програмістів зустрічається з замовником, щоб з’ясувати, яку функціональність він хоче отримати до наступного релізу, тобто через 2 – 6 місяців. Так як вимоги замовника часто розмиті, розробники конкретизують їх і дроблять на частини, реалізація яких займає не більше одного дня. Важливо, щоб замовник розбирався в операційному середовищі, в якому буде працювати продукт. 

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

В XP, якщо команда не встигає виконати всі задачі до дати релізу, то реліз не відсувається, а ріжеться частина функціоналу, найменш важлива для замовника. 

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

3. Часті релізи версій

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

4. Користувальницькі тести

Замовник сам визначає автоматизовані приймальні тести, щоб перевірити працездатність черговий функції продукту. Команда пише ці тести і використовує їх для тестування готового коду.

5. Колективне володіння кодом

В XP будь-який розробник може правити будь-який шматок коду, так як код не закріплений за своїм автором. Кодом володіє вся команда.

6. Безперервна інтеграція коду

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

7. Стандарти кодування

Коли кодом володіють всі, важливо прийняти єдині стандарти оформлення, код виглядав так, як ніби він написаний одним професіоналом. Можна виробити свої стандарти або прийняти готові.

8. Метафора системи

Метафора системи — це її порівняння з чимось знайомим, щоб сформувати у команди спільне бачення. Зазвичай метафору системи продумує той, хто розробляє архітектуру і представляє систему цілком.

9. Стійкий темп

XP команди працюють на максимумі продуктивності, зберігаючи стійкий темп. При цьому екстремальне програмування негативно ставиться до переробок і пропагує 40-годинний робочий тиждень.

10. Розробка, заснована на тестуванні

Одна з найважчих практик методології. В XP тести пишуться самими програмістами, причому ДО написання коду, який потрібно протестувати. При такому підході кожен шматок функціоналу буде покритий тестами на 100%. Коли пара програмістів заливають код в репозиторій, відразу запускаються модульні тести. І всі вони повинні спрацювати. Тоді розробники будуть впевнені, що рухаються в правильному напрямку. 

11. Парне програмування

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

12. Простий дизайн

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

13. Рефакторинг

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

Переваги і недоліки XP

Методологія XP викликає багато суперечок і критики з боку тих, хто так і не зміг її впровадити у своїй команді. 

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

  • замовник отримує саме той продукт, який йому потрібен, навіть якщо на початку розробки сам точно не представляє його кінцевий вигляд
  • команда швидко вносить зміни в код і додає нову функціональність за рахунок простого дизайну коду, частого планування і релізів
  • код завжди працює за рахунок постійного тестування і безперервної інтеграції
  • команда легко підтримує код т. к. він написаний за єдиним стандартом і постійно рефакториться
  • швидкий темп розробки за рахунок парного програмування, відсутність наднормової роботи, присутності замовника у команді
  • висока якість коду
  • знижуються ризики, пов’язані з розробкою, так як відповідальність за проект розподіляється рівномірно та вихід/​прихід члена команди не зруйнує процес
  • витрати на розробку нижче, так як команда орієнтована на код, а не на документацію і збори

Незважаючи на всі плюси, XP не завжди працює і має ряд слабких місць. Отже, екстремальне програмування. Недоліки:

  • успіх проекту залежить від включеності замовника, якої не так просто добитися
  • важко передбачити витрати часу на проект, так як на початку ніхто не знає повного списку вимог
  • успіх XP сильно залежить від рівня програмістів, методологія працює тільки з senior фахівцями
  • менеджмент негативно ставиться до парного програмування, не розуміючи, чому він повинен оплачувати двох програмістів замість одного
  • регулярні зустрічі з програмістами дорого обходяться замовникам
  • вимагає дуже сильних культурних змін
  • із-за нестачі структури та документації не підходить для великих проектів
  • так як гнучкі методології функціонально-орієнтовані, нефункціональні вимоги до якості продукту складно описати у вигляді користувальницьких історій.

Принципи XP

У першій книзі Кент Бек сформулював такі принципи екстремального програмування: простота, комунікація, зворотній зв’язок і сміливість. У новому виданні книги він додав п’ятий принцип — повага. 

1. Простота

XP розробка починається з самого простого рішення, яке задовольнить поточну потребу в функціональності. Члени команди враховують тільки те, що повинно бути зроблено зараз, і не закладають в код функціональність, яка знадобиться завтра, через місяць або ніколи.

2. Комунікація

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

3. Зворотній зв’язок

Зворотний зв’язок у XP реалізується відразу в трьох напрямках: 

  1. фідбек від системи при постійному тестування модулів
  2. фідбек від замовника, так як він входить в команду і бере участь у написанні приймальних тестів
  3. фідбек від команди під час планування щодо часу на розробку.

4. Сміливість

Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.

5. Повага

В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну. 

Алгоритм впровадження методології XP і процес роботи

Кент Бек рекомендує впроваджувати XP для вирішення проблем у проекті. Команда вибирає саму нагальну проблему і вирішує її за допомогою однієї з практик екстремального програмування. Потім переходить до наступної проблеми, використовуючи ще одну практику. При такому підході проблеми виступають мотивацією до застосування XP і команда поступово освоює всі інструменти методології.

Щоб впровадити XP в існуючий проект, треба поступово освоювати його методики в областях:

  • тестування
  • проектування
  • планування
  • менеджмента
  • розробки

Тестування.

Команда створює тести ПЕРЕД написанням нового коду і поступово переробляє старий код. Для старого коду тести пишуться по мірі необхідності: коли потрібно додати нову функціональність, виправити помилку або переробити частину старого коду. 

Проектування.

Команда поступово рефакторить старий код, зазвичай перед додаванням нової функціональності. Як і у випадку з тестуванням, рефакторинг старого коду проводять тільки за необхідності. При цьому команді варто сформулювати довгострокові цілі переробки коду і поступово досягати їх.

Планування.

Команда повинна перейти на тісну взаємодію з замовником. На цьому етапі важливо донести до нього переваги роботи в одній команді з розробниками і інтегрувати його в команду. 

Менеджмент.

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

Розробка.

Перетворення в розробці починаються з організації робочих місць для програмування парами. Наступне завдання — програмувати парами більшу частину робочого часу, як би важко це не давалося розробникам.

У проекті, який працює за методологією XP процес побудований таким чином:

методології XP процес побудований так

Хто використовує XP

За даними дослідження Versionone за 2016 рік усього 1% agile компаній використовують екстремальне програмування в чистому вигляді. Ще 10% працюють за гібридною методології scrum і XP

Співвідношення agile методологій і практик в компаніях

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

найпопулярніші практики розробки в agile компаніях в 2016 р

Найпопулярніші практики розробки в agile компаніях в 2016 р.

Не так просто знайти інформацію про команди, які застосовують XP, але є й ті, хто афішує, що саме ця методологія — причина їхнього успіху. Приклад екстремального програмування — компанія Pivotal Software, Inc.

Pivotal Software, Inc. 

Американська софтверна компанія, яка розробляє для бізнес-аналізу на основі big data і надає консультаційні послуги. Продуктами Pivotal користуються корпорації Ford, Mercedes, BMW, GAP, Humana, великі банки, державні установи, страхові компанії і т. д.

Pivotal — адвокат agile методологій, які єдино можливі в сучасній розробці. З усіх варіантів гнучких методологій компанія вибрала XP, win-win підхід для замовників і команд програмістів. Кожен робочий день починається зі зборів на ходу, і закінчується рівно о 18:00 — ніяких переробок. Pivotal використовує гру в планування, парне програмування, постійне тестування, безперервну інтеграцію та інші практики XP. Для багатьох практик у них є власне ПЗ.

Парне програмування в openspace компанії Pivotal Software, Inc.

Парне програмування в openspace компанії Pivotal Software, Inc.

Що почитати, щоб розібратися в XP

Екстремальне програмування,
Екстремальне програмування: планування,
Екстремальне програмування: розробка через тестування / Кент Бек

Книги з екстремального програмування від творця методології Кента Бека. Почніть з першої, в ній з прикладами описується концепція XP і обґрунтовуються її переваги. Пізніше автор випустив ще кілька книг, де докладно описав окремі практики XP

Рефакторинг: покращення існуючого коду / Мартін Фаулер

Мартін Фаулер — програміст і співавтор методології екстремального програмування.У книзі описані основні принципи і прийоми рефакторінгу, а також 70 практичних методів рефакторінгу з прикладами.

Екстремальне програмування: постановка процесу. З перших кроків і до переможного кінця / Кен Ауер, Рой Міллер

Книга описує практики XP і вчить впроваджувати їх на практиці, життєво і з прикладами.

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

Програми для впровадження XP в команді 

Команди, які працюють над проектами по методології XP, застосовують таск менеджери та сервіси для agile проектів. На ринку багато таких продуктів, ми розглянемо кілька прикладів.

Redmine

Redmine

Безкоштовний менеджер задач з відкритим кодом. Основні функції: робота одразу над кількома проектами, гнучка система управління задачами, діаграма Ганта, контроль часу, робота з документацією, створення задач через пошту та інше.

Basecamp

Basecamp

Простий зручний сервіс для спільної роботи над проектами. Включає таск менеджер, дошки повідомлень, вбудований чат, файлосховище, календар

Jira

Jira

Потужний сервіс, розроблений спеціально для розробників agile проектів. Об’єднує баг-трекер та сервіс для управління проектами. Багато функцій плюс синхронізація з іншими сервісами. Рішення для команд різних розмірів.

Worksection

Worksection

Безпечний сервіс для роботи над проектами. Дозволяє ставити задачі і контролювати процес виконання, вести листування по задачі, налаштовувати фільтри, враховувати витрати часу та фінансів, працювати з файлами.

Вердикт

Екстремальне програмування — гнучка методологія, в центрі якої якісний працездатний код з простою архітектурою. Її призначення — знизити рівень невизначеності в проектах і по-справжньому гнучко реагувати на зміни вимог до продукту. 

Ця методологія призначена виключно для сфери розробки програмних продуктів і не може бути адаптована під інший бізнес. 

Це одна з найважчих для впровадження методологій, оскільки вона включає цілих тринадцять практик! 

Деякі компанії ризикують працювати по чистому XP, але його практики розробки — найпопулярніші в agile проектах. І це вагомий аргумент на користь їх ефективності. 

Автори методології радять одну за одною освоювати практики XP, паралельно вирішуючи проблеми проекту. Якщо ви бачите ефект, продовжуйте в тому ж дусі. 

Ніхто не зобов’язує впроваджувати XP за принципом все або нічого”. Зрештою, гнучкі методології повинні бути гнучкими і в плані застосування — підлаштовуватися під потреби конкретної команди проекту.
відповісти
MrGamer 29 лютого 2020
спасибо .Статья помогла.
відповісти
Артем з Харкова 17 лютого 2023
Дуже дякую!
Я до такого ще не доходив, але дуже цікаво було ознайомитись!
відповісти
Дмитро 17 лютого 2023
Дякуємо, що оцінили! Ще більше корисного в наших сомережах :)
відповісти
junior1473 12 грудня 2023
спасибо за интересную и объёмную статью! Супер
відповісти
Дмитро 12 грудня 2023
Дякуємо, що читаєте:)

esc
Поділитись у
или
Новинки
Канбан по проєктах, Канбан по термінах та Нові автоматизації для Канбану Worksection
25 квітня 2024   •   5 min read
Школа PM
Короткий огляд [SMART] — це система встановлення цілей, які передбачає їх конкретність, вимірність, досяжність, релевантність та обмеженість у часі. Конкретні завдання є чіткими та чітко визначеними,...
24 квітня 2024   •   7 min read
Школа PM
Перед вами детальний посібник з прийняття управлінських рішень. Ефективне прийняття рішень має першочергове значення для успіху організації у сучасному динамічному бізнес-середовищі. У цій статті розглядаються...
12 квітня 2024   •   16 min read
Почніть роботу прямо зараз
Введіть, будь ласка, свій справжній email 🙂