ХР-процес

Інкрементна модель

Інкрементна модель є класичним прикладом інкрементної стратегії конструювання (рис. 2.4). Вона об'єднує елементи послідовної водоспадної моделі з ітераційною філософією макетування.

Кожна лінійна послідовність тут виробляє поставляється інкремент ПЗ. Наприклад, ПЗ для обробки слів в 1-му інкременті реалізує функції базової обробки файлів, функції редагування та документування; у 2-му інкременті - більш складні можливості редагування та документування; в 3-му інкременті - перевірку орфографії та граматики; в 4-му інкременті - можливості компонування сторінки.

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

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

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

Рис. 2.4. Інкрементна модель

Екстремальне програмування (eXtreme Programming, XP) - полегшений (рухливий) процес (або методологія), головний автор якого - Кент Бек (1999). ХР-процес орієнтований на групи малого та середнього розміру, що будують програмне забезпечення в умовах вимог, що невизначені або швидко змінюються.

Основна ідея ХР - усунути високу вартість зміни, характерну для додатків з використанням об'єктів, патернів і реляційних БД. Тому ХР-процес повинен бути високодинамічним процесом. ХР-група має справу зі змінами вимог напротязі всього ітераційного циклу розробки, причому цикл складається з дуже коротких ітерацій. Чотирма базовими діями в ХР-циклі є: кодування, тестування, вислуховування замовника і проектування. Динамізм забезпечується за допомогою чотирьох характеристик: безперервного зв'язку із замовником (і в межах групи), простоти (завжди вибирається мінімальне рішення), швидкого зворотного зв'язку (за допомогою модульного та функціонального тестування), сміливості у проведенні профілактики можливих проблем. Більшість принципів, підтримуваних в ХР (мінімальність, простота, еволюційний цикл розробки, мала тривалість ітерації, участь користувача, оптимальні стандарти кодування і т. д.), продиктовані здоровим глуздом і застосовуються в будь-якому упорядкованому процесі. Просто в ХР ці принципи, як показано в табл. 2.2, досягають «екстремальних значень».

Таблиця 2.2. Екстремуми в екстремальному програмуванні

Базис ХР утворюють перераховані нижче 12 методів.

1. Гра планування (Planning game) - швидке визначення області дії наступної реалізації шляхом об'єднання ділових пріоритетів і технічних оцінок. Замовник формує область дії, пріоритетність і терміни з точки зору бізнесу, а розробники оцінюють і простежують просування (прогрес).

2. Часта зміна версій (Small releases) - швидкий запуск у виробництво простої системи. Нові версії реалізуються в дуже короткому (двотижневому) циклі.

3. Метафора (Metaphor) - вся розробка проводиться на основі простої, загальнодоступної історії про те, як працює вся система.

4. Просте проектування (Simple design) - проектування виконується настільки просто, наскільки це можливо в даний момент.

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

6. Реорганізація (Refactoring) - система реструктурується, але її поведінка не змінюється; мета - усунути дублювання, поліпшити взаємодію, спростити систему або додати в неї гнучкість.

7. Парне програмування (Pair programming) - весь код пишеться двома програмістами, що працюють на одному комп'ютері.

8. Колективне володіння кодом (Collective ownership) - будь-який розробник може покращувати будь-який код системи в будь-який час.

9. Безперервна інтеграція (Continuous integration) - система інтегрується і будується багато разів на день, по мірі завершення кожного завдання. Безперервне регресійне тестування, тобто повторення попередніх тестів, гарантує, що зміни вимог не приведуть до регресу функціональності.

10. 40-годинний тиждень (40-hour week) - як правило, працюють не більше 40 годин на тиждень. Не можна подвоювати робочий тиждень за рахунок понаднормових робіт.

11. Локальний замовник (On-site customer) - в групі весь час повинен знаходитися представник замовника, дійсно готовий відповідати на питання розробників.

12. Стандарти кодування (Coding standards) - повинні витримуватися правила, що забезпечують однакове уявлення програмного коду у всіх частинах програмної системи.

Гра планування і часта зміна версій залежать від замовника, що забезпечує набір «історій» (коротких описів), що характеризують роботу, яка буде виконуватися для кожної версії системи. Версії генеруються кожні два тижні, тому розробники і замовник повинні прийти до угоди про те, які історії будуть здійснені в межах двох тижнів. Повну функціональність, необхідну замовнику, характеризує пул історій; але для наступної двотижневої ітерації з пулу вибирається підмножина історій, найбільш важливе для замовника. У будь-який час в пул можуть бути додані нові історії, таким чином, вимоги можуть швидко змінюватися. Однак процеси двотижневої генерації засновані на найбільш важливих функціях, що входять в поточний пул, отже, мінливість управляється. Локальний замовник забезпечує підтримку цього стилю ітераційної розробки.

«Метафора» забезпечує глобальне «бачення» проекту. Вона могла б розглядатися як високорівнева архітектура, але ХР підкреслює бажаність проектування при мінімізації проектної документації. Точніше кажучи, ХР пропонує безперервне перепроектування (за допомогою реорганізації), при якому немає потреби в деталізованої проектної документації, а для інженерів супроводу єдиним надійним джерелом інформації є програмний код. Зазвичай після написання коду проектна документація викидається. Проектна документація зберігається тільки в тому випадку, коли замовник тимчасово втрачає здатність вигадувати нові історії. Тоді систему поміщають в «нафталін» и пишуть керівництво сторінок на 5-10 по «нафталіновому» варіанту системи. Використання реорганізації призводить до реалізації найпростішого рішення, що задовольняє поточну потребу. Зміни у вимогах змушують відмовлятися від усіх «загальних рішень».

Парне програмування - один з найбільш спірних методів в ХР, воно впливає на ресурси, що важливо для менеджерів, які вирішують, чи буде проект використовувати ХР. Може здатися, що парне програмування подвоює ресурси, але дослідження довели: парне програмування призводить до підвищення якості та зменшення часу циклу. Для узгодженої групи витрати збільшуються на 15%, а час циклу скорочується на 40-50%. Для Інтернет-середовища збільшення швидкості продажів покриває підвищення витрат. Співпраця покращує процес вирішення проблем, покращення якості істотно знижує витрати супроводу, які перевищують вартість додаткових ресурсів по всьому циклу розробки.

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

«Тестуй, а потім кодуй» - ця фраза виражає акцент ХР на тестуванні. Вона відображає принцип, за яким спочатку планується тестування, а тестові варіанти розробляються паралельно аналізу вимог, хоча традиційний підхід полягає в тестуванні «чорного ящика». Роздум про тестування на початку циклу життя - добре відома практика конструювання ПЗ (правда, рідко здійснювана практично).

Основним засобом управління ХР є метрика. Зазвичай використовують 3-4 метрики, причому такі, які видимі всій групі. Рекомендованої в ХР метрикою є «швидкість проекту» - кількість історій заданого розміру, які можуть бути реалізовані в ітерації.

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

Рис. 2.5. Ідеальний ХР-процес

Розглянемо структуру «ідеального» ХР-процесу. Основним структурним елементом процесу є ХР-реалізація, в яку багато разів вкладається базовий елемент - ХР-ітерація. До складу ХР-реалізації та ХР-ітерації входять три фази - дослідження, блокування, регулювання. Дослідження (exploration) - це пошук нових вимог (історій, завдань), які повинна виконувати система. Блокування (commitment) - вибір для реалізації конкретної підмножини з усіх можливих вимог (іншими словами, планування). Регулювання (steering) - проведення розробки, втілення плану в життя.

ХР рекомендує: перша реалізація повинна тривати 2-6 місяців, тривалість решти реалізацій - близько двох місяців, кожна ітерація триває приблизно два тижні, а чисельність групи розробників не перевищує 10 осіб. ХР-процес для проекту з сімома реалізаціями, здійснюваний за 15 місяців, показаний на рис. 2.5.

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

Передбачається, що тривалість першої реалізації становить 3 місяці, тривалість другої - сьомої реалізацій - 2 місяці. Друга - сьома реалізації утворюють період супроводу, що характеризує природу ХР-проекту. Кожна ітерація триває два тижні, за винятком тих, які відносять до пізньої стадії реалізації - «запуску у виробництво» (в цей час темп ітерації прискорюється).

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