Файл: Лекція 7 у оп Екстремальне програмування.pdf

Лекція 7

Тема: Екстремальне програмування. Планування та дизайн. Кодування та тестування.

План:

1.Основні принципи

2.Правила Екстремального Програмування

3.Дизайн

Екстремальне програмування (Extreme Programming, XP) виникло як еволюційний метод розробки ПЗ "від низу до верху". Цей підхід є прикладом так званого методу "живої" розробки (Agile Development Method). До групи "живих" методів входять, крім екстремального програмування, методи

SCRUM, DSDM (Dynamic Systems Development Method, метод розробки динамічних систем), FeatureDriven Development (розробка, керована функціями системи) і ін.

Основні принципи "живої" розробки ПЗ:

Люди, що беруть участь в проекті, і їх спілкування важливіші, ніж процеси і інструменти.

Працююча програма важливіша, ніж вичерпна документація.

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

Відробіток змін важливіший, ніж проходження планам.

"Живі" методи з'явилися як протест проти надмірної бюрократизації розробки ПО, великої кількості побічних, таких, що немає необхідними для отримання кінцевого результату документів. Велика частина таких робіт і документів не має прямого відношення до розробки ПЗ і забезпеченню його якості, а призначена для дотримання формальних пунктів контрактів на розробку, отримання і підтвердження сертифікатів на відповідність різним стандартам.

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

XP має свою схему процесу приведену на мал.1.

За твердженням авторів XP, ця методика є не стільки проходженням якимсь загальним схемам дій, скільки застосування комбінації наступної техніки. При цьому кожна техніка важлива, і без її використання розробка вважається такою, що йде не по XP, згідно затвердженню Кента Бека (Kent Beck) одного з авторів цього підходу разом з Уордом Каннінгемом (Ward Cunningham) і Роном Джефрісом (Ron Jeffries).

Живе планування (planning game)

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

Мал. 1. Схема потоку робіт в XP

1

Часта зміна версій (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 для тих випадків, в яких можливі рішення не знаходяться відразу на основі раніше отриманого досвіду, а вимагають проведення попередніх досліджень.

2

Правила Екстремального Програмування

Основні правила Екстремального Програмування:

Планування

Пишуться 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 треба планувати в поточну ітерацію.

Ітерації

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

Планування Ітерації

Iteration Planning Meeting скликається перед початком кожної ітерації для планування завдань які будуть зроблені в цій ітерації. Для ітерації вибираються User Stories які вибрав замовник в плані релізу починаючи з найважливіших для замовника і найгірших (зв'язаних з ризиком) для розробників. Також в ітерацію включаються непрацюючі Функціональні тести. User Stories і невиконані Функціональні тести розбиваються на завдання. Завдання записуються на картках. Ці картки і є детальний план на ітерацію. Кожне завдання повинне бути тривалістю від 1 до 3 днів.

Міняйтеся завданнями

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

3

Cross Training є важливим аспектом в компаніях які прагнуть уникнути концентрації знань в одній людині. Переміщення людей за кодом в комбінації з парним програмуванням означає, що замість однієї людини, яка знає все про даний шматок коду, кожен у вашій команді знає багато про код в кожному модулі. Команда стає набагато гнучкішою якщо всі знають достатньо про кожну частину системи щоб почати працювати над нею. Декілька програмістів можуть працювати над ним одночасно.

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

Збори стоячи

Кожен ранок проводяться збори для обговорення проблем, їх рішень і для посилення концентрації команди. Збори проводяться стоячи для уникнення тривалих дискусій не цікавих всім членам команди. Щоранкові збори це не ще одна витрата часу. Воно дозволить уникнути багатьох інших зборів і заощадить більше часу, чим на нього витрачено.

Дизайн

Простота.

Обов'язково вибрати Метафору системи.

Використовувати CRC карточки для дизайну.

Писати Пробні рішення для зменшення рисків.

Не додавати ніяких функцій раніше часу.

Рефакторіть безжально.

Вибирайте найпростіше рішення

"Ускладнювати - просто, спрощувати - складно" Народна мудрість

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

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

Зберігайте рішення наскільки можливо простими якомога довше. Ніколи не додайте функціональність на майбутнє - до того як з'являється в ній необхідність. Проте майте на увазі: зберігати дизайн простим - важка робота.

Метафора Системи

Завжди вибирайте System Metaphor - просту і зрозумілу концепцію щоб члени команди називали всі речі однаковими іменами. Для розуміння системи і виключення дублюючого коду надзвичайно важливо як ви називаєте об'єкти. Якщо ви можете припустити як називається який-небудь об'єкт в системі (якщо ви знаєте що він робить) і він правда так називається - ви збережете час. Створіть систему імен для своїх об'єктів так, щоб кожен член команди міг користуватися нею без спеціальних знань про систему.

Пробне рішення

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

Вам це не знадобиться

Утримаєтеся від заповнення системи речами, які знадобляться в майбутньому. Тільки 10% від очікуваного дійсно знадобиться вам в первинному вигляді, тобто 90% вашого часу буде витрачено даремно.

Безжально Рефакторить!

Рефакторинг зрештою економить час і покращує якість продукту.

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

Кодування

Замовник завжди поряд.

Весь код повинен відповідати прийнятому стандарту.

Весь код повинен бути створений парним програмуванням.

Часта інтеграція коду.

Колективне владіння кодом.

Залишати оптимізацію на потім.

Замовник

Одна з вимог XP - замовник завжди доступний. Він повинен не просто допомагати команді розробників, а бути її членом. Всі фази XP проекту вимагають комунікації із замовником. Але в якості консультанта потрібний експерт.

4

User Stories пишуться замовником за допомогою розробників. Замовник допомагає упевнитися що більшість бажаних функцій системи покрита User Story.

Учас планування релізу замовникові необхідно обговорити вибір User Stories які будуть включені

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

Угода про кодування

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

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

Парне програмування

Весь код для системи (а це означає за винятком пробних рішень) пишеться парами. Два розробники сидять поряд. Один набирає, інший дивиться. Час від часу вони міняються. Не дозволяється працювати поодинці. Якщо з якоїсь причини другої з пари пропустив щось (хворів, відходив і тому подібне) він зобов'язаний проглянути всі зміни зроблені першим.

Часта інтеграція

Розробники, по-можливості, повинні інтегрувати і випускати свій код кожні декілька годин. Кожна пара розробників повинна віддавати свій код як тільки для цього з'являється розумна можливість. Це може бути коли всі UnitTest-и проходять на 100%.

Колективне володіння кодом

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

Залишайте оптимізацію на потім

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

Тестування

Будь-який код повинен мати Unit Test.

Всі Unit тести повинні проходити перед віддачею.

Функціональні тести періодично виконуються і їх результати публікуються.

Unit Test-и

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

Коли виявлена помилка

Якщо виявляється помилка, то створюється тест, щоб запобігти її повторній появі. Помилка, що відбулася в робочій системі (вже встановленою), вимагає написання функціонального тесту. Створення функціонального тесту безпосередньо перед діагностикою помилки дозволяє замовникам чітко описати проблему і довести цю проблему до розробників. Функціональний тест, що не виконався, вимагає створення Unit Test. Це допомагає сфокусувати зусилля по відладці і чітко показує коли помилка виправлена

Функціональні тести

Приймальні тести пишуться на основі User Story. Вони розглядають систему як чорний ящик. Замовник відповідальний за перевірку коректності функціональних тестів. Ці тести використовуються для перевірки працездатності системи перед випуском її у виробництво. Функціональні тести автоматизуються так, щоб була можливість їх часто запускати.

Питання:

1.Основні принципи "живої" розробки ПЗ.

2.Схема потоку робіт в XP

3.Переваги та недоліки XP.

4.Основні правила Екстремального Програмування: планування

5.Основні правила Екстремального Програмування: дизайн

6.Основні правила Екстремального Програмування: тестування

Література:

1.Левин В.И .История информационных технологий. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру », БИНОМ. Лаборатория знаний ». Серия: Основы информационных технологий », 2007 - 336 стр.

2.Галатенко В.А., Основы информационной безопасности. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Серия: Основы информационных технологий »,2008

- 208 стр.

5