Лекція 7
Тема: Екстремальне програмування. Планування та дизайн. Кодування та тестування.
План:
-
Основні принципи
-
Правила Екстремального Програмування
-
Дизайн
Екстремальне програмування (Extreme Programming, XP) виникло як еволюційний метод розробки ПЗ "від низу до верху". Цей підхід є прикладом так званого методу "живої" розробки (Agile Development Method). До групи "живих" методів входять, крім екстремального програмування, методи SCRUM, DSDM (Dynamic Systems Development Method, метод розробки динамічних систем), Feature-Driven Development (розробка, керована функціями системи) і ін.
Основні принципи "живої" розробки ПЗ:
-
Люди, що беруть участь в проекті, і їх спілкування важливіші, ніж процеси і інструменти.
-
Працююча програма важливіша, ніж вичерпна документація.
-
Співпраця із замовником важливіша, ніж обговорення деталей контракту.
-
Відробіток змін важливіший, ніж проходження планам.
"Живі" методи з'явилися як протест проти надмірної бюрократизації розробки ПО, великої кількості побічних, таких, що немає необхідними для отримання кінцевого результату документів. Велика частина таких робіт і документів не має прямого відношення до розробки ПЗ і забезпеченню його якості, а призначена для дотримання формальних пунктів контрактів на розробку, отримання і підтвердження сертифікатів на відповідність різним стандартам.
"Живі" методи дозволяють велику частину зусиль розробників зосередити власне на завданнях розробки і задоволення реальних потреб користувачів. Відсутність кіпи документів і необхідності підтримувати їх в зв'язному стані дозволяє швидше і якісно реагувати на зміни у вимогах і в оточенні, в якому доведеться працювати майбутній програмі.
XP має свою схему процесу приведену на мал.1.
За твердженням авторів XP, ця методика є не стільки проходженням якимсь загальним схемам дій, скільки застосування комбінації наступної техніки. При цьому кожна техніка важлива, і без її використання розробка вважається такою, що йде не по XP, згідно затвердженню Кента Бека (Kent Beck) одного з авторів цього підходу разом з Уордом Каннінгемом (Ward Cunningham) і Роном Джефрісом (Ron Jeffries).
-
Живе планування (planning game)
Його завдання — щонайшвидше визначити об'єм робіт, які потрібно зробити до наступної версії ПP. Рішення ухвалюється, в першу чергу, на основі пріоритетів замовника (тобто його потреб, того, що потрібне йому від системи для успішнішого ведення свого бізнесу) і, в другу, на основі технічних оцінок (тобто оцінок трудомісткості розробки, сумісності з рештою елементів системи і ін.). Плани змінюються, як тільки вони починають розходитися з дійсністю або побажаннями замовника.
Мал. 1. Схема потоку робіт в XP
-
Часта зміна версій (small releases)
Найперша працююча версія повинна з'явитися щонайшвидше і тут же повинна почати використовуватися. Наступні версії готуються через достатньо короткі проміжки часу (від декількох годин при невеликих змінах в невеликій програмі, до місяця-двох при серйозній переробці крупної системи).
-
Метафора (metaphor) системи
Метафора в достатньо простому і зрозумілому команді вигляді повинна описувати основний механізм роботи системи. Це поняття нагадує архітектуру, але повинно набагато простіше, всього у вигляді однієї-двох фраз описувати основну суть ухвалених технічних рішень.
-
Прості проектні рішення (simple design)
У кожен момент часу система повинна бути сконструйована настільки просто, наскільки це можливо. Не треба додавати функції заздалегідь — тільки після явного прохання про це. Вся зайва складність віддаляється, як тільки виявляється.
-
Розробка на основі тестування (test-driven development)
Розробники спочатку пишуть тести, потім намагаються реалізувати свої модулі так, щоб тести спрацьовували. Замовники заздалегідь пишуть тести, що демонструють основні можливості системи, щоб можна було побачити, що система дійсно заробила.
-
Постійна переробка (refactoring)
Програмісти постійно переробляють систему для усунення зайвої складності, збільшення зрозумілості коду, підвищення його гнучкості, але без змін в його поведінці, що перевіряється прогоном після кожної переробки тестів
-
Програмування парами (pair programming)
Кодування виконується двома програмістами на одному комп'ютері. Об'єднання в пари довільно і міняється від завдання до завдання. Той, в чиїх руках клавіатура, намагається якнайкращим способом вирішити поточну задачу. Другий програміст аналізує роботу першого і дає поради, обдумує наслідки тих або інших рішень, нові тести, менш прямі, але гнучкіші рішення.
-
Колективне володіння кодом (collective ownership)
У будь-який момент будь-який член команди може змінити будь-яку частину коду. Ніхто не повинен виділяти свою власну область відповідальності, вся команда в цілому відповідає за весь код.
-
Постійна інтеграція (continuous integration)
Система збирається і проходить інтеграційне тестування якомога частіше, по кілька разів в день, кожного разу, коли пара програмістів закінчує реалізацію чергової функції.
-
40-годинний робочий тиждень
Наднормова робота розглядається як ознака великих проблем в проекті. Не допускається наднормова робота 2 тижні підряд — це виснажує програмістів і робить їх роботу значно менш продуктивною.
-
Включення замовника в команду (on-site customer)
У складі команди розробників постійно знаходиться представник замовника, який доступний протягом всього робочого дня і здатний відповідати на всі питання про систему. Його обов'язком є достатньо оперативні відповіді на питання будь-якого типу, що стосуються функцій системи, її інтерфейсу, необхідної продуктивності, правильної роботи системи в складних ситуаціях, необхідності підтримувати зв'язок з іншими застосуваннями і ін.
-
Використання коду як засобу комунікації
Код розглядається як найважливіший засіб спілкування усередині команди. Ясність коду — один з основних пріоритетів. Відповідність стандартам кодування, що забезпечують таку ясність, обов'язково. Такі стандарти, крім ясності коду, повинні забезпечувати мінімальність виразів (заборона на дублювання коду і інформації) і повинні бути прийняті всіма членами команди.
-
Відкритий робочий простір (open workspace)
Команда розміщується в одному, достатньо просторому приміщенні, для спрощення комунікації і можливості проведення колективних обговорень при плануванні і ухваленні важливих технічних рішень.
-
Зміна правил з потреби (just rules)
Кожен член команди повинен прийняти перераховані правила, але при виникненні необхідності команда може поміняти їх, якщо всі її члени прийшли до згоди з приводу цієї зміни.
XP розраховане на використання в рамках невеликих команд (не більше 10 програмістів). Більший розмір команди руйнує необхідну для успіху простоту комунікації і робить неможливим застосування багатьох перерахованих прийомів.
Достоїнствами XP є велика гнучкість, можливість швидко і акуратно вносити зміни ПЗ у відповідь на зміни вимог і окремі побажання замовників, високу якість коду, що виходить в результаті, і відсутність необхідності переконувати замовників в тому, що результат відповідає їх очікуванням.
Недоліками цього підходу є нездійсненність в такому стилі достатньо великих і складних проектів, неможливість планувати терміни і трудомісткість проекту на достатньо довгу перспективу і чітко передбачити результати тривалого проекту в термінах співвідношення якості результату і витрат часу і ресурсів. Також можна відзначити непристосованість XP для тих випадків, в яких можливі рішення не знаходяться відразу на основі раніше отриманого досвіду, а вимагають проведення попередніх досліджень.
Правила Екстремального Програмування
Основні правила Екстремального Програмування:
Планування
-
Пишуться User Stories.
-
Власне план створюється в результаті Планування Релізу.
-
Випускати часті невеликі Релізи.
-
Вимірюється Швидкість проекту.
-
Проект ділиться на Ітерації.
-
Кожна ітерація починається зі зборів по плануванню.
-
Люди постійно міняються завданнями.
-
Щодня починається з ранкових Зборів стоячи.
-
XP правила коректуються якщо щось не так.
User Story
User Story (щось типу розповіді користувача) - це опис того як система повинна працювати. Кожна User Story написана на картці і представляє якийсь шматок функціональності системи, що має логічний сенс з погляду Замовника. Форма - один-два абзацу тексту зрозумілого користувачеві (не сильно технічного).
User Story пишеться Замовником. Вони схожі на сценарії використання системи, але не обмежуються призначеним для користувача інтерфейсом. По кожній історії пишуться функціональні тести, підтверджуючі що дана історія коректно реалізована, - їх ще називають приймальними (Acceptance tests).
Кожній User Story дається пріоритет з боку бізнесу (користувач, замовник, відділ маркетингу) і оцінка часу виконання з боку розробників. Кожна історія розбивається на завдання і їй призначається час коли її почнуть реалізовувати.
User Stories використовуються в XP замість традиційних вимог. Головна відмінність User Story від вимог (requirements) - рівень деталізації. User Story містить мінімум інформації, необхідної для обґрунтованої оцінки того, скільки часу треба на її реалізацію.
Типова User Story займає 1-3 тижні часу. Історія та, що вимагає менше 1 тижня дуже деталізована. Історія та, що вимагає більше 3 тижнів може бути розбита на частини - окремі історії.
План Релізу
План Релізу розробляється на зборах по плануванню Релізу. Реліз Плани описують погляд на весь проект і використовуються надалі для планування ітерацій.
Важливо, щоб технічні люди робили технічні рішення і люди бізнесу - бізнес рішення. Планування Релізу визначає набір правил, які дозволяють всім ухвалювати свої рішення. Ці правила визначають метод вироблення що задовольняє всіх.
Суть зборів по плануванню релізу для команди розробників в тому, щоб оцінити кожну User Story у ідеальних тижнях. Ідеальний тиждень - це скільки займе час виконання завдання Замовник потім вирішує які завдання найбільш важливі або мають вищий пріоритет.
Реліз можна планувати за часом або по об'єму.
Часті Релізи
Розробники повинні випускати версії системи користувачам якомога частіше. Планування Релізу використовується для пошуку невеликих функціональних фрагментів що мають значущий бізнес-сенс і які можуть бути випущені в реальне оточення на ранніх стадіях розробки. Це критично для своєчасного отримання корисних відгуків, щоб мати можливість впливати на процес розробки. Чим більше ви затримуєте випуск важливої частини системи тим менше у вас буде часу виправити її.
Швидкість проекту
Швидкість Проекту це міра того, як швидко виконується робота у вашому проекті.
Щоб зміряти швидкість проекту, ви просто повинні порахувати об'єм User Stories або як багато (за часом) завдань було виконано за ітерацію. Просто порахуйте сумарний час оцінки об'єму роботи (ідеальний час). Під час планування релізу швидкість проекту використовується для оцінки того скільки User Stories може бути зроблено. Під час планування ітерації, швидкість проекту в попередній ітерації використовується для визначення того скільки User Stories треба планувати в поточну ітерацію.