Відмінності між версіями «Екстремальне програмування (XP)»

Поточна версія на 10:31, 26 лютого 2019

Екстремальне програмування (XP)

• Екстремальне програмування (XP від англ. Extreme Programming) — методологія розробки програмного забезпечення. Має на меті поліпшення якості програмного забезпечення та чутливість до змін у вимогах замовників. Як вид гнучких методологій, XP радить часті "випуски" програми у коротких циклах розробки, що має на меті поліпшити продуктивність праці та покращити можливості виконання вимог замовника що змінюються. Авторами даної методології є Кент Бек, Ворд Каннінгем, Мартін Фаулер та інші.
• Мета методики XP - впоратися з постійно мінливими вимогами до програмного продукту та скоротити вартість неочікуваних змін і підвищити якість розробки. Тому XP добре підходить для складних і невизначених проектів. У традиційних методах розробки вимоги до розвитку системи визначаються на початку роботи над проектом, і часто виправляються пізніше. Це означає, що вартість проекту через зміни буде більшою за заплановану. XP використовується для скорочення вартості змін, завдяки представленню простих значень, принципів і методів. При використанні екстремального програмування, проект повинен стати гнучкішим щодо змін. Методологія XP будується навколо чотирьох процесів: кодування, тестування, дизайну і слухання. Крім того, екстремальне програмування має цінності: простоту, комунікацію, зворотний зв'язок, сміливість і повагу.

Основні прийоми (XP)

Дванадцять основних прийомів екстремального програмування можуть бути об'єднані в чотири групи:

1) Короткий цикл зворотного зв'язку (Fine-scale feedback)

• Розробка через тестування (Test-driven development)
• Гра в планування (Planning game) - швидко сформувати приблизний план роботи і постійно оновлювати його в міру того, як умови задачі стають все більш чіткими
• Замовник завжди поруч (Whole team, Onsite customer) - XP стверджує, що замовник повинен бути весь час на зв'язку і доступний для питань.
• Парне програмування (Pair programming) - передбачає, що весь код створюється парами програмістів, які працюють за одним комп'ютером. Один з них працює безпосередньо з текстом програми, інший переглядає його роботу і стежить за загальною картиною того, що відбувається.

2) Безперервний, а не пакетний процес

• Безперервна інтеграція (Continuous integration) - В XP інтеграція коду всієї системи виконується кілька разів на день, після того, як розробники переконалися в тому, що всі тести модулів коректно спрацьовують.
• Рефакторинг (Design improvement, Refactoring) - XP має на увазі, що одного разу написаний код в процесі роботи над проектом майже напевно буде неодноразово перероблений.
• Тести модулів дозволяють розробникам переконатися в тому, що їх код працює коректно. Вони також допомагають іншим розробникам зрозуміти, навіщо потрібен той чи інший фрагмент коду та як він функціонує. Тести модулів також дозволяють розробнику без будь-яких побоювань виконувати рефакторинг. Розробники XP безжально переробляють написаний раніше код для того, щоб поліпшити його
• Часті невеликі релізи (Small releases) - версії (releases) продукту повинні надходити в експлуатацію якомога частіше. Робота над кожною версією повинна займати якомога менше часу. При цьому кожна версія має бути достатньо осмисленої з точки зору корисності для бізнесу.

3) Розуміння, що розділяється всіма

• Простота (Simple design) - XP виходить з того, що в процесі роботи умови задачі можуть неодноразово змінитися, а значить, що розробляється продукт не слід проектувати завчасно цілком і повністю. Проектування повинно виконуватися невеликими етапами, з урахуванням постійно змінюються вимог. У кожен момент часу слід намагатися використовувати найбільш простий дизайн, який підходить для вирішення поточної задачі, і міняти його в міру того, як умови задачі змінюються.
• Метафора системи (System metaphor) - це уявлення про компоненти системи і їх взаємозв'язках між собою. Розробникам необхідно проводити аналіз архітектури програмного забезпечення для того, щоб зрозуміти, в якому місці системи необхідно додати нову функціональність, і з чим буде взаємодіяти новий компонент.
• Колективне володіння кодом (Collective code ownership) або обраними шаблонами проектування (Collective patterns ownership)-означає, що кожен член команди несе відповідальність за весь вихідний код. Таким чином, кожен має право вносити зміни в будь-яку ділянку програми. Парне програмування підтримує цю практику: працюючи в різних парах, все програмісти знайомляться з усіма частинами коду системи. Важлива перевага колективного володіння кодом в тому, що воно прискорює процес розробки, оскільки при появі помилки її може усунути будь-який програміст.
• Стандарт кодування (Coding standard or Coding conventions) - в рамках XP необхідно домогтися того, щоб було складно зрозуміти, хто є автором тієї чи іншої ділянки коду, - вся команда працює уніфіковано, як одна людина. Команда повинна сформувати набір правил, а потім кожен член команди повинен слідувати цим правилам в процесі кодування. Перелік правил не повинен бути вичерпним або занадто об'ємним. Завдання полягає в тому, щоб сформулювати загальні вказівки, завдяки яким код стане зрозумілим для кожного з членів команди.

4) Соціальна захищеність програміста (Programmer welfare)

• 40-годинний робочий тиждень (Sustainable pace, Forty-hour week)

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

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

Недоліки екстремального програмування

• Успіх проекту залежить від залучення замовника, якої не так просто домогтися важко передбачити витрати часу на проект, тому що на початку ніхто не знає повного списку вимог.
• Успіх XP сильно залежить від рівня програмістів, методологія працює тільки з senior фахівцями.
• Менеджмент негативно відноситься до парного програмування, не розуміючи, чому він повинен оплачувати двох програмістів замість одного.
• Регулярні зустрічі з програмістами дорого обходяться замовникам.
• Вимагає занадто сильних культурних змін.
• Через нестачу структури і документації не підходить для великих проектів.