Екстремальне програмування (eXtreme Programming, XP) – спрощена методологія організації виробництва для невеликих і середніх за розміром команд розробників, які займаються розробленням програмного продукту в умовах незрозумілих або швидко змінних вимог [19].

Програмування відповідно до методик ХР доводить використання загальноприйнятих принципів програмування до екстремальних рівнів:

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

У розділі конспекту «Керування та організація робіт» наведені основні ризики розроблення ПЗ, виділені К.Беком. Для зменшення кількості можливих ризиків та усунення їх негативного впливу і розроблена методологія XP. У табл.1 наведені найпоширеніші ризики розроблення та методи їх усунення за допомогою екстремального програмування.

 

Таблиця 5.1   – Методи усунення ризиків розроблення ПЗ у методології XP

Методи усунення ризиків розроблення ПЗ у методології XP

Ризик	Метод подолання у XP
Зміна графіка	Планується короткострокове розроблення версій ПЗ
Закриття проекту	Замовник визначає найменший перелік найважливіших функцій системи, які визначають якість системи
Система втрачає корисність	Постійне розроблення та виконання тестів над системою не дозволяють накопичуватися дефектам, що впливають на роботу системи
Велика кількість дефектів і недоліків	Тести постійно створюються і виконуються не лише розробниками, а й замовниками, які перевіряють функціональність системи
Невідповідність ПЗ розв'язуваній проблемі	Представник замовника є постійним членом команди розробників. Специфікація постйно перевіряється і змінюється за потреби
Зміна характеру бізнесу	Бізнес не встигає помітно змінити напрямок діяльності у ході короткострокового розроблення версії програми
Нестача функціональних можливостей	Задачі із найбільшим пріоритетом реалізуються у першу чергу
Плинність кадрів	Програмісти самостійно оцінюють обсяг робіт та термін виконання, що підвищує їх зацікавленість

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

Для формування стилю розроблення, що дозволить досягти потрібної якості рішення, в XP пронується керуватись чотирма цінностями [19]:

• комунікацією (communication) – дисципліна XP, спрямована на забезпечення безперервної комунікації усіх учасників проекту. Під час тестування, програмування в парах та попереднього оцінювання робіт замовники, розробники та менеджери змушені постійно спілкуватись;
• простотою (simplicity) – неможливо заздалегідь точно визначити, як буде розвиватися проект, тому вирішувати необхідно лише завдання, що виникають сьогодні, у найбільш простий спосіб;
• зворотним зв'язком (feedback) – спосіб отримати точні та конкретні дані про стан проекту. Постійне виконання тестів для перевірки усіх змін у системі забезпечує програміста звороним зв’язком про якість роботи. Кожен новий опис замовником вимог до системи одразу ж оцінюється розробниками і забезпечує замовника зворотним зв’язком із інформацію про якість опису. Менеджер, який контролює строки виконання робіт, забезпечує усіх учісників проекту інформацією про виконання планових термнів розроблення. В XP найбільш важливі функції системи реалізуються в першу чергу у реально працюючий продукт, тому замовник досить швидко може оцінити хід виконання та якість розроблення, а також відповідність замовленню;
• хоробрість (courage) – для того, щоб розроблення не втратила своєї актуальності, в XP рішення повинні прийматися з максимальною швидкістю, для чого потрібна певна сміливість.

Для визначення методів вирішення проблем розроблення ПЗ на основі обраних цінностей потрібно керуватися такими фундаментальними принципами оцінки методів вирішення поставленого завдання:

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

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

У рамках XP пропонуються методи виконання чотирьох основних видів діяльності у ході розроблення ПЗ:

Кодування – від якості коду залежать робота та надійність системи. Якісне кодування потребує постійного навчання та удосконалення. Також код містить інформацію про стан проекту у найльш стислій та чітко зрозумілій формі;

Тестування – постійне тестування зменшує вартість внесення змін у розроблення та зменшує ризики, пов’язані із змінами. Виконання усіх запланованих тестів свідчить про успішне завершення чергової версії або усього проекту;

Слухання – відкрите чесне спілкування – як між розробниками, так і між розробниками і замовниками. Програмісти повинні почути бізнес-вимоги замовника, щоб виконати завдання, а замовник повинен чути зауваження розробників, щоб краще розуміти свої потреби;

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

Для розв’язання виділених проблем розроблення в методології XP використовуються такі методики [19]:

Гра в планування (planning game) – швидко визначає обсяг робіт, що необхідно виконати у наступній версії. Для цього розглядаються бізнес-пріоритети та технічні оцінки. Якщо з часом план перестає відповідати дійсності, відбувається оновлення плану. Замовники повинні приймати рішення стосовно обсягів робіт, пріоритетності завданть та строків випуску версій. Розробники повинні відповідати за оцінку часу, потрібного на реалізацію вимог, наслідки прийнятих рішень, організацію процесу розроблення та детальне планування робіт.

Невеликі версії (small releases) – найперша спрощена версія системи, що реалізує найбільш важливу функціональність, швидко вводиться в експлуатацію. Наступні версії випускаються через відносно короткі проміжки часу.

Метафора (metaphor) – проста загальнодоступна і загальновідома історія, що коротко описує, як працює вся система. Ця історія керує усім процесом розроблення.

Простий дизайн (simple design) – у кожен момент часу система повинна бути спроектована так просто, як це можливо. Виявлена надмірна складність усувається одразу.

Тестування (testing) – програмісти постійно пишуть тести для модулів, а замовники – тести, які демонструють працездатність і завершеність тієї чи іншої можливості системи. Умова продовження розроблення – усі тести спрацьовують без помилок.

Переробка (refactoring) – програмісти реструктурують систему, не змінюючи її поведінки. При цьому вони усувають дублювання коду, покращують комунікацію, спрощують код і підвищують його гнучкість.

Програмування парами (pair programming) – увесь розроблювальний код пишеться двома програмістами на одному комп'ютері.

Колективне володіння (collective ownership) – у будь-що момент часу будь-що член команди може змінити будь-що код у будь-якому місці системи.

Безперервна інтеграція (continuous integration) – система інтегрується і збирається кожного разу, коли завершується рішення чергового завдання (можливо кілька разів за день).

40-годинний тиждень (40-hour week) – програмісти працюють не більше 40 годин на тиждень. Ніколи не можна працювати понаднормово два тижні поспіль.

Замовник на місці розроблення (on-site customer) – до складу команди входить реальний користувач системи. Він доступний упродовж усього робочого дня і здатний відповідати на запитання про систему.

Стандарти кодування (coding standards) – програмісти пишуть увесь код у відповідності до правил, які забезпечують комунікацію за допомогою коду.

Постійна зміна вимог під час розроблення ПЗ, необхідність забезпечення  ефективної співпраці команди розробників потребували методів, які б забезпечили якість розроблення та супроводу програмних систем і уникнули недоліків занадто формалізованих методів, більшість з яких базувалась на каскадній моделі ЖЦ. У 90-х рр. ХХ ст. активно стали виникати різноманітні підходи до створення ПЗ, які забезпечували гнучку роботу програмістів. У результаті у 2001 році був написаний Маніфест гнучкого розроблення (Agile manifesto), що зафіксував цінності ефективних підходів до розроблення програмних продуктів, таких, як XP, Feature driven development, Scrum, Adaptive software development, Pragmatic Programming (прагматичне програмування). Текст маніфесту [35] підписали 17 найавторитетніших фахівців у цій галузі діяльності – Кент Бек (Kent Beck), Алістер Коуберн (Alistair Cockburn), Мартін Фаулер (Martin Fowler) та інші:

Agile-маніфест розроблення програмного забезпечення

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

Завдяки цій роботі ми змогли зрозуміти, що:

Люди та співпраця важливіші за процеси та інструменти;

Працюючий продукт важливіший за вичерпну документацію;

Співпраця із замовником важливіша за обговорення умов контракту;

Готовність до змін важливіша за дотримання плану.

Хоча цінності, що справа, важливі, ми все ж цінуємо більше те, що зліва.

 

У результаті з’явився термін – Гнучке розроблення програмного забезпечення (Agile software development) – клас методологій розроблення програмного забезпечення, що базуються на ітеративному розробленні, в якому вимоги та рішення еволюціонують через співпрацю між самоорганізовуваними багатофункціональними командами.

У маніфесті озвучені основні принципи гнучкого розроблення ПЗ:

• Найвищий пріоритет – задоволення потреб замовника шляхом завчасного та регулярного постачання програмного забезпечення.
• Схвальне ставлення до змін, навіть на завершальних стадіях розроблення. Agile-процеси використовують зміни для забезпечення конкурентоспроможності замовника.
• Працюючий продукт необхідно випускати якомога частіше, з періодичністю від двох тижнів до двох-трьох місяців.
• Упродовж усього проекту розробники і представники бізнесу повинні працювати разом щодня.
• Над проектом повинні працювати вмотивовані професіонали, які працюють у зручних умовах, із повною підтримкою та довірою менеджменту проекту.
• Особиста комунікація – найефективніший та найпрактичніший метод обміну інформацією в команді.
• Працюючий продукт – головний показник прогресу.
• Інвестори, розробники і користувачі повинні мати можливість підтримувати постійний ритм роботи. Agile допомагає налагодити такий сталий процес розроблення.
• Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.
• Простота – мистецтво мінімізації зайвої роботи – дуже необхідна.
• Найкращі вимоги, архітектурні та технічні рішення виникають у командах, які здатні самоорганізовуватись.
• Команда постійно шукає способи підвищення ефективності та відповідно коригує свою роботу.

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

Гнучкі методи орієнтовані на різні аспекти життєвого циклу розроблення програмного забезпечення. Деякі акцентують увагу на практичних завданнях (екстремальне програмування, прагматичне програмування, Agile-моделювання), інші зосереджені на управлінні програмними проектами (Scrum). Також серед agile-методів існують підходи, які забезпечують повне охоплення життєвого циклу розроблення – метод розроблення динамічних систем (dynamic systems development method, DSDM) та уніфікований процес розроблення (RUP), розглянутий вище. Більшість гнучких методів для використання упродовж життєвого циклу ПЗ потрібно доповнювати іншими підходами, окрім DSDM та RUP.

Особливістю гнучких методів є те, що на даний час відсутні дані про провальні agile-проекти, але є результати опитувань, які підтвердили їх успішне використання [36]. Тому і потужні компанії-розробники активно їх запроваджують у свою діяльність, наприклад, Oracle запроваджує гнучкі методи управління ЖЦ продуктів (Agile product lifecycle management), фірма IBM є власником продуктів, які підтримують використання методології RUP.

Потрібно виділити фактори, які можуть негативно вплинути на використання гнучких методів:

• масштабні зусилля у галузі розвитку (більше 20 розробників);
• розподілена у просторі команда;
• примусове впровадження гнучкого процесу усупереч вимогам команди розробників;

Небажане використання agile-методів у критично важливих системах (табл.2), де відмова ПЗ неможливий ні в якому разі (наприклад, управління повітряним рухом).

 

Таблиця 5.2  – Порівняння використання гнучких та формальних методів

Agile акцентує увагу на безпосередньому спілкуванні між учасниками проекту. Більшість agile-команд розміщені в одному офісі (bullpen). До команди обов’язково включають представників замовника (замовники, які визначають продукт, менеджери продукту, бізнес-аналітики або користувачі). Також до команди входять тестувальники, дизайнери інтерфейсу, технічні автори та менеджери.

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

Scrum-методи ітераційні та інкрементні. Кожна ітерація (спринт) триває упродовж 15-30 днів і повинна закінчитися приростом функціональних можливостей (рис.5.1).

Рисунок 5.1   — Розроблення ПЗ із використанням Scrum

Під час спринту (рис.5.2) обов’язково відбуваються зустрічі дійових осіб:

• Планування спринту (Planning Meeting) – відбувається на початку ітерації. Не більше 4-8 годин.
• Мітинг (Daily Scrum) – відбувається кожного дня упродовж спринту. Триває 15 хвилин.
• Огляд спиринту (Sprint Review) – зустріч для оцінки зробленого у спринті та демонстрації результатів (тривалість розраховується як 1 година на кожен тиждень спринту).
• Ретроспектива (Retrospective Meeting). Усі члени команди розповідають про своє ставлення до ходу спринту. Обмежено 1-3 годинами.

Дійові особи розподіляються на дві групи:

• повністю задіяні у процесі розроблення («свині»):
  • Власник Продукту (Product Owner);
  • Керівник (ScrumMaster);
  • Команда (Scrum Team);
• причетні до розроблення («кури»):
  • Користувачі (Users);
  • Клієнти, Продавці (Stakeholders);
  • Експерти-консультанти (Consulting Experts).

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