Extreme-programming

До змісту

eXtreme Programming — гнучка методологія розробки програмного забезпечення.

Автор (американський розробник Кент Бек) XP не придумав нічого нового, а взяв кращі практики гнучкої розробки і посилив до максимуму. Тому програмування і називається екстремальним.

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

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

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

Принципи XP

1. Простота - XP розробка починається з самого простого рішення, яке задовольнить поточну потребу в функціональності. Члени команди враховують тільки те, що повинно бути зроблено зараз, і не закладають в код функціональність, яка знадобиться завтра, через місяць або ніколи.
2. Комунікація - XP комунікація між розробниками ведеться не за допомогою документації, а наживо. Команда активно спілкується між собою і з замовником.
3. Зворотній зв’язок - Зворотний зв’язок у XP реалізується відразу в трьох напрямках:
   • фідбек від системи при постійному тестування модулів
   • фідбек від замовника, так як він входить в команду і бере участь у написанні приймальних тестів
   • фідбек від команди під час планування щодо часу на розробку.
4. Сміливість - Деякі методики екстремального програмування настільки незвичні, що вимагає сміливості і постійного контролю над собою.
5. Повага - В екстремальному програмуванні повага розглядається з точки зору поваги до команди і самоповаги. Члени команди не повинні заливати зміни, які поламають компіляцію, модульні тести, або сповільнюють роботу колег. Кожен прагне до вищої якості коду та дизайну.

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

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

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

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

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

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

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

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

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

1. Часті релізи версій - XP версії випускаються часто, але з невеликим функціоналом. По-перше, маленький обсяг функціональності легко тестувати і зберігати працездатність всієї системи. По-друге, кожну ітерацію замовник отримує частину функціоналу, яка має бізнес-цінність.
2. Користувальницькі тести - Замовник сам визначає автоматизовані приймальні тести, щоб перевірити працездатність черговий функції продукту. Команда пише ці тести і використовує їх для тестування готового коду.
3. Колективне володіння кодом - В XP будь-який розробник може правити будь-який шматок коду, так як код не закріплений за своїм автором. Кодом володіє вся команда.
4. Безперервна інтеграція коду - Це означає, що нові частини коду відразу ж вбудовуються в систему — команди XP заливають новий білд кожні кілька годин і частіше. По-перше, відразу видно, як останні зміни впливають на систему. Якщо новий шматок коду щось зламав, то знайти помилку і виправити в рази простіше, ніж через тиждень. По-друге, команда завжди працює з останньою версією системи.
5. Стандарти кодування - Коли кодом володіють всі, важливо прийняти єдині стандарти оформлення, код виглядав так, як ніби він написаний одним професіоналом. Можна виробити свої стандарти або прийняти готові.
6. Метафора системи - Метафора системи — це її порівняння з чимось знайомим, щоб сформувати у команди спільне бачення. Зазвичай метафору системи продумує той, хто розробляє архітектуру і представляє систему цілком.
7. Стійкий темп - XP команди працюють на максимумі продуктивності, зберігаючи стійкий темп. При цьому екстремальне програмування негативно ставиться до переробок і пропагує 40-годинний робочий тиждень.
8. Розробка, заснована на тестуванні - Одна з найважчих практик методології. В XP тести пишуться самими програмістами, причому ДО написання коду, який потрібно протестувати. При такому підході кожен шматок функціоналу буде покритий тестами на 100%. Коли пара програмістів заливають код в репозиторій, відразу запускаються модульні тести. І всі вони повинні спрацювати. Тоді розробники будуть впевнені, що рухаються в правильному напрямку.
9. Парне програмування - Уявіть двох розробників за одним комп’ютером, що працюють над одним шматком функціональності продукту. Це і є парне програмування, сама спірна практика XP. Стара приказка «одна голова добре, а дві краще» відмінно ілюструє суть підходу. З двох варіантів вирішення проблеми вибирається найкращий, код оптимізується відразу ж, помилки відловлюються ще до їх здійснення. У підсумку маємо чистий код, в якому добре розбираються відразу двоє розробників.
10. Простий дизайн - Простий дизайн в XP означає робити тільки те, що потрібно зараз, не намагаючись вгадати майбутню функціональність. Простий дизайн і безперервний рефакторинг дають синергетичний ефект — коли код простий, його легко оптимізувати.
11. Рефакторинг - Рефакторинг — це процес постійного поліпшення дизайну системи, щоб привести його у відповідність новим вимогам. Рефакторинг включає видалення дублів коду, підвищення зв’язності і зниження сполучення. XP передбачає постійні рефакторинги, тому дизайн коду завжди залишається простим

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

Переваги

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

Недоліки

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

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

• тестування - Команда створює тести ПЕРЕД написанням нового коду і поступово переробляє старий код. Для старого коду тести пишуться по мірі необхідності: коли потрібно додати нову функціональність, виправити помилку або переробити частину старого коду.
• проектування - Команда поступово рефакторить старий код, зазвичай перед додаванням нової функціональності. Як і у випадку з тестуванням, рефакторинг старого коду проводять тільки за необхідності. При цьому команді варто сформулювати довгострокові цілі переробки коду і поступово досягати їх.
• планування - Команда повинна перейти на тісну взаємодію з замовником. На цьому етапі важливо донести до нього переваги роботи в одній команді з розробниками і інтегрувати його в команду.
• менеджмента - Роль менеджерів при переході на XP — контролювати, щоб всі члени команди працювали за новими правилами. Менеджер проекту приймає рішення, коли розлучитися з членом команди, який не справляється з роботою в нових умовах, або знайти нового і правильно інтегрувати його в роботу.
• розробки - Перетворення в розробці починаються з організації робочих місць для програмування парами. Наступне завдання — програмувати парами більшу частину робочого часу, як би важко це не давалося розробникам.