Гнучка розробка програмного забезпечення

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук
Цикл розробки
програмного забезпечення
Coding Shots Annual Plan high res-5.jpg
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація
Архітектура ·  Дизайн
Реалізація ·  Тестування
Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення
DSDM ·  Iterative ·  RAD ·  RUP
Spiral ·  Водоспад ·  XP ·  Scrum
Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування
Документування
Якість ПЗ
Управління проектами
Досвід користування
Інструменти
Компілятор ·  Зневаджувач
Профілювальник
GUI designer ·  IDE

Гнучка́ розро́бка програ́много забезпе́чення (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між самоорганізовуваними багатофункціональними командами. Гнучка розробка - найкращий засіб для підвищення продуктивності розробників програмного забезпечення.

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

Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.

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

Історія[ред.ред. код]

  • 1992 - Сімейство методологій Crystal стало початковою точкою розвитку мотодів розробки програмного забезпечення, що і призвело до появи Agile. Розробка Crystal належить Алістеру Коберну (Alistair Cockburn). Методологія була названа Crystal у 1997 році. Застосовується командами з 6-8 чоловік, які знаходяться в одному місці й працюють над створенням програмних систем, котрі не є критичними для життя користувачів.
  • 1993 - Рефакторінг. Термін вперше ввів Bill Opdyke в статті під назвою "Creating Abstract Superclasses by Refactoring".
  • 1994 - Dynamic Systems Development Method. DSDM був розроблений консорціумом, що є об'єднанням постачальників і виробників програмного забезпечення. Метою їх роботи було - спільними зусиллями розробити і поширити незалежний фреймворк для швидкої розробки додатків, з використанням накопиченого досвіду. Jennifer Stapleton будучи одним із засновників і членом DSDM, внесла істотний внесок у компіляцію вихідних ідей і думок. Arie van Bennekum є одним з автором Agile-маніфесту і брав активну участь у роботі консорціуму DSDM починаючи з 1997 року.
  • 1995 - Scrum and Pair Development. SCRUM був розроблений спільно Джефом Сазерлендом (Jeff Sutherland) і Кеном Швабером (Ken Schwaber). Парне програмування як концепція була описана одночасно і незалежно кількома авторами. Jim Coplien опублікував статтю "A Development Process Generative Pattern Language", в якій міститься опис патерну "Розробка в парах". Larry Constantine писав про "Dynamic Duos" у своїй книзі "Constantine on Peopleware", опублікованій у тому ж році. Дана концепція стала складовою частиною методології Extreme Programming. Незалежно від того, що було виконано кілька досліджень, що демонструють ефективність програмування в парах, дана концепція не знайшла реального відображення в Agile-маніфесті.
  • 1997 - Feature Driven Development. Методологію Feature Driven Development (FDD) розробив Jeff De Luca. Процес розробки ПЗ за методологією FDD був представлений світу за допомогою публікації книги "Java Modeling in Color with UML: Enterprise Components and Process", де Джеф виступив у співавторстві з Пітером Кодом (Peter Coad). Пітер заснував компанію TogetherSoft, яку потім продав компанії Borland.
  • 1999 - Adaptive Software Development. Jim Highsmith сформулював концепцію Adaptive System Development і опублікував книгу з такою ж назвою. Ідея виросла з його роботи на методологіями швидкого створення додатків (RAD). Він запропонував три фази життєвого циклу: 1)Speculation; 2)Collaboration; 3)Learning. Під час роботи в Chrysler Кент Бек (Kent Beck) розробив концепцію екстремального програмування (Extreme Programming). Він опублікував цей метод в 1999 в книзі - Extreme Programming Explained. Частиною Extreme Programming є концепція історій користувача (User Stories) і планування релізу (Release Planning). Дана методологія описує найкращі практики у сфері планування, управління, проектування, кодування і тестування. Ward Cunningham і Ron Jeffries також привнесли свої ідеї, так що всі троє вважаються засновниками методу XP.
  • 2000 - Події, що призвели до маніфесту. Bob Martin проявив ініціативу і взявся за організацію, що стала історичною, зустрічі, що пройшла в лютому 2001 року на гірськолижному курорті. Він є власником Uncle Bob Consulting.

Agile-маніфест розробки програмного забезпечення[ред.ред. код]

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

Agile Manifesto розроблений і прийнятий 11-13 лютого 2001 року на лижному курорті The Lodge at Snowbird в горах Юти. Маніфест підписали представники наступних методологій Extreme programming, Scrum, DSDM, Adaptive software development, Crystal Clear, Feature-driven development, Pragmatic Programming. Agile Manifesto містить 4 основні ідеї та 12 принципів. Примітно, що Agile Manifesto не містить практичних порад.

Основні ідеї:

  • Особистості та їхні взаємодії важливіше, ніж процеси та інструменти;
  • Робоче програмне забезпечення важливіше, ніж повна документація;
  • Співпраця із замовником важливіша, ніж контрактні зобов'язання;
  • Реакція на зміни важливіше, ніж дотримання плану.

Принципи, які роз'яснює Agile Manifesto:

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

Маніфест та Принципи гнучкої розробки містять високорівневі ідеї щодо того, як потрібно вибудовувати процес розробки програмного забезпечення, щоб успішно завершувати проекти й створювати команди, в яких приємно та цікаво працювати. Документи визначають, що потрібно для цього зробити, але не говорять, як це зробити. По-іншому й не могло бути, оскільки Маніфест та Принципи народилися внаслідок консенсусу представників різних (хоча й споріднених) напрямів, які могли знайти спільну основу лише на рівні базових цінностей та принципів

Критика[ред.ред. код]

Багато керівників проектів, що працюють у традиційних методологіях на кшталт "водоспаду", критикують agile-методи.

Один з повторюваних пунктів критики: при agile-підході часто нехтують створенням "дорожньої карти" розвитку продукту, так само як і управлінням вимогами, в процесі якого і формується така "карта". Гнучкий підхід до управління вимогами не має на увазі далекосяжних планів (по суті, управління вимогами просто не існує в даній методології), а має на увазі можливість замовника раптом і несподівано наприкінці кожної ітерації виставляти нові вимоги, що часто суперечать архітектурі вже створеного і поставленого продукту. Таке іноді призводить до катастрофічних "авралів" з масовим рефакторингом і переробками практично на кожній черговій ітерації.

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

Методології[ред.ред. код]

Існують методології, які дотримуються цінностей і принципів заявлених в Agile Manifesto, деякі з них:

  • Agile Modeling - набір понять, принципів і прийомів (практик), що дозволяють швидко і просто виконувати моделювання і документування в проектах розробки програмного забезпечення. Не включає в себе детальну інструкцію з проектування, не містить описів, як будувати діаграми на UML. Основна мета: ефективне моделювання і документування; але не охоплює програмування та тестування, не включає питання управління проектом, розгортання і супроводу системи. Однак включає в себе перевірку моделі кодом [3].
  • Agile Unified Process(AUP) спрощена версія IBM Rational Unified Process (RUP), розроблена Скоттом Амблером, яка описує просте і зрозуміле наближення (модель) для створення програмного забезпечення для бізнес-додатків.
  • Agile Data Method - група ітеративних методів розробки програмного забезпечення, в яких вимоги та рішення досягаються в рамках співпраці різних крос-функціональних команд.
  • DSDM заснований на концепції швидкої розробки додатків (Rapid Application Development, RAD). Являє собою ітеративний і інкрементний підхід, який надає особливого значення тривалій участі в процесі користувача/споживача.
  • Essential Unified Process (EssUP).
  • Екстремальне програмування ( англ. Extreme programming , XP).
  • Feature driven development (FDD) - функціонально-орієнтована розробка. Використовуване в FDD поняття функції або властивості ( англ. feature ) Системи досить близько до поняття прецеденту використання, використовуваному в RUP, істотна відмінність - це додаткове обмеження: "кожна функція повинна допускати реалізацію не більше, ніж за два тижні". Тобто якщо сценарій використання досить малий, його можна вважати функцією. Якщо ж великий, то його треба розбити на декілька відносно незалежних функцій.
  • Getting Real - ітераційний підхід без функціональних специфікацій, що використовується для веб-додатків. У даному методі спершу розробляється інтерфейс програми, а потім її функціональна частина.
  • OpenUP - це ітераційно -інкрементний метод розробки програмного забезпечення. Позиціюється, як легкий і гнучкий варіант RUP. OpenUP ділить життєвий цикл проекту на чотири фази: початкова фаза, фази уточнення, конструювання та передачі. Життєвий цикл проекту забезпечує надання зацікавленим особам та членам колективу точок ознайомлення і прийняття рішень впродовж усього проекту. Це дозволяє ефективно контролювати ситуацію і вчасно приймати рішення про задовільність результатів. План проекту визначає життєвий цикл, а кінцевим результатом є остаточний додаток.
  • Scrum встановлює правила керування процесом розробки та дозволяє використовувати вже існуючі практики кодування, коректуючи вимоги або вносячи тактичні зміни. Використання цієї методології дає можливість виявляти і усувати відхилення від бажаного результату на більш ранніх етапах розробки програмного продукту.
  • Бережлива розробка програмного забезпечення ( англ. lean software development ). Використовує підходи з концепції бережливого виробництва.

Додатково[ред.ред. код]

Джерела[ред.ред. код]