94. Фундаментальні принципи методології eХtreme Programming

Методологія ХР описана Кентом Беком (Kent Beck) у 1995 році.

Екстремальне програмування (ХP - eXtreme Programming) – це спрощена методологія розробки інформаційних систем для невеликих і середніх команд (2-10 розробників) в умовах невизначених, або швидкозмінних вимог, яка визначає кодування як ключову основну діяльність при роботі над проектом ІС. Базується на ряді принципів та методик.

Назву «екстремальне» ця методологія отримала через те, що доводить використання багатьох загальноприйнятих і широковикористовуваних принципів програмування до екстремального рівня. Приклади наведено в таблиці 13.1.

Таблиця 13.1.

«Екстремальні» принципи екстремального програмування

Принципи традиційного програмування	Принципи екстремального програмування
Проектування	- Проектування складова частина щоденної роботи кожного розробника (переробка коду)
Перегляд коду	- Постійний перегляд коду (програмування парами)
Тестування	- Постійне тестування коду кожним розробником (тестування модулів), і замовниками (функціональне тестування)
Простота	- Збереження найпростішого дизайну, що забезпечує поточний рівень функціональності (найпростіша річ, яка спрацює)
Архітектура	- Кожний учасник проекту постійно працює над визначенням і переглядом архітектури (метафора)
Інтеграційне тестування	- Постійна збірка і тестування системи (інтеграція, що триває)
Невеликі ітерації	- Ітерації щонайменші - хвилини і секунди, а не тиждні і місяці (гра в планування)

95. Методологій гнучкої розробки інформаційних систем. Життєвий цикл scrum

Методологія SCRUM розроблена Кеном Швабером (Ken Schwaber) і Майком Бідлом (Mіke Beedle).

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

Починається життєвий цикл з формування концепції і вироблення Product Backlog.

Product Backlog - це пріоритетний список наявних на даний момент бізнес-вимог і технічних вимог до системи.

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

За Product Backlog відповідає Product Owner (ним може бути представник замовника, або менеджер проекту для внутрішньої розробки). Він також працює разом з командою для того, щоб одержати наближену оцінку виконання елементів Product Backlog.

Наступним етапом є Планування Sprіnt (ітерації) та вироблення Sprіnt Backlog (рис.13.5), який містить функціональність, обрану Product Owner з Product Backlog. Всі функції розбиті по завданнях, кожне з яких оцінюється командою. Щодня команда оцінює обсяг роботи, який потрібно проробити для завершення завдань. Сума оцінок роботи, що залишилася, може бути побудована як графік залежності від часу. Такий графік називається Sprіnt Burndown chart. Він демонструє прогрес команди по ходу спринту.

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

Під час ітерації вимоги, викладені в Sprіnt Backlog не змінюються.

Щодня проводяться короткі п’ятнадцятихвилинні збори, називані "scrum" ("бійка") - для обміну інформацією.