Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Гнучка методологія розробки



План:


Введення

Гнучка методологія розробки ( англ. Agile software development , Agile-методи) - серія підходів до розробці програмного забезпечення, орієнтованих на використання ітеративної розробки і динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганизующихся робочих груп, що складаються з фахівців різного профілю. Існує кілька методик, що відносяться до класу гнучких методологій розробки, зокрема, відомі як гнучкі методики екстремальне програмування, DSDM, Scrum.

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

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

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


1. Історія

У лютому 2001 в штаті Юта США був випущений "Маніфест гнучкої методології розробки програмного забезпечення". Він був альтернативою керованим документацією, "великоваговим" практикам розробки програмного забезпечення, таким як " метод водоспаду ", який був золотим стандартом розробки в той час. Даний маніфест був схвалений і підписаний представниками методологій екстремального програмування, Crystal Clear, DSDM, Feature driven development, Scrum, Adaptive software development, Pragmatic Programming. Гнучка методологія розробки використовувалася багатьма компаніями і до прийняття маніфесту, однак саме після цієї події відбулося входження Agile-розробки в маси.


2. Принципи

Agile - сімейство процесів розробки, а не єдиний підхід в розробці програмного забезпечення, і визначається Agile Manifesto [1]. 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 [2] :

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

3. Критика

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

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

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


4. Методології

Існують методології, які дотримуються цінностей і принципів заявлених в 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 ) Використовує підходи з концепції бережливого виробництва.

Примітки

  1. Agile Manifesto - agilemanifesto.org (Англ.)
  2. Agile Manifesto principles - www.agilemanifesto.org / principles.html
  3. Agile Modeling - www.informicus.ru/default.aspx?SECTION=6&id=94

Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Гнучка
Методологія
Методологія історії
Методологія програмування
Методологія науки
Методологія економічної науки
Delphi (середа розробки)
Інтегроване середовище розробки
Eclipse (середа розробки)
© Усі права захищені
написати до нас
Рейтинг@Mail.ru