На початку XXI століття потреби в ПЗ досягли екстремальних значень.
Традиційно для створення проектів, компанії користуються моделями повного попереднього проектування («великовагові» процеси).
Останнім часом з'явилася група нових «полегшених підходів», які дозволяють швидко реагувати на часті зміни замовника. Такий підхід досягається завдяки використанню групи висококваліфікованих розроблювачів-універсалів і грамотного замовника.
Найпоширенішим «полегшеним» процесом є ХР-процес. (автор Кент Бэк, 1999). Процес орієнтований на групи малого або середнього розміру, що створюють програму в умовах часто змінюваних вимог. У середньому це може бути до 10 людей, що перебувають в одному приміщенні. Основною метою такого процесу є – зниження вартості програми при частій зміні умов.
Основною характеристикою такої моделі є відсутність стадії проектування. Програма проектується відразу при написанні коду (еволюційне проектування). Такий підхід дуже ризикований з погляду успішного завершення проекту.
ХР-процес – базується на наступних основних принципах:
- постійний зв'язок із замовником;
- безперервне тестування й безперервна інтеграція (кожний розроблювач може впровадити в загальну системи свою частину налагодженого коду);
- простота (завжди вибирається оптимальний алгоритм, код якого зрозумілий іншим учасникам команди);
- принцип YAGNI (You Aren't Going to Need It – це тобі не знадобитися). Розроблювач займається написанням коду для поточної функції й не витрачає час і сили на написання коду для функції, яка буде розроблятися пізніше;
- прогнозування бажань замовника (має на увазі детальне володіння розроблювачами знаннями в області, для якої пишеться програма).
Для забезпечення ХР-процесу використовують наступні підходи:
- часта зміна версій (раз в 2 тижні);
- парне кодування – один код може писатися різними учасниками групи почергово;
- колективне володіння кодом – будь-який учасник групи може вносити зміни в програму;
- 40-годинний робочий тиждень;
- використання стандартів кодування (усі розроблювачі повинні дотримуватися стандартів у програмуванні для забезпечення розуміння кодів усіма учасниками);
- уміння всіх учасників при необхідності пояснити своє рішення колегам (за допомогою коду, діаграм, засобів спілкування).
