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

Технологія розробки програмного забезпечення

Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Вимоги Специфікація Архітектура Дизайн Реалізація Тестування Розгортання Реліз Супровід
Методології Процес
Гнучка Чистого приміщення DSDM Ітеративна RAD RUP Спіраль Водоспад XP Scrum Lean V-Model FDD TDD BDD
Допоміжні дисципліни
Керування конфігурацією Документування Якість ПЗ Управління проєктами Досвід користування
Практики
Неперервна інтеграція Керована поведінкою розробка
Інструменти
Компілятор Зневаджувач Профілювальник GUI designer IDE Автоматизація складання Інфраструктура як код Тестування
Стандарти та галузі знань
CMMI ISO 9001 ITIL PMBOK SWEBOK

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

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

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

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

Історія

• 1992 — сімейство методологій Crystal стало початковою точкою розвитку методів розробки програмного забезпечення, що і призвело до появи Agile. Розробка Crystal належить Алістеру Коберну. Методологія була названа Crystal у 1997 році. Застосовується командами з 6-8 чоловік, які знаходяться в одному місці й працюють над створенням програмних систем, котрі не є критичними для життя користувачів.
• 1993 — рефакторинг. Термін вперше ввів Біл Опдайк в статті під назвою «Creating Abstract Superclasses by Refactoring».
• 1994 — Dynamic Systems Development Method. DSDM був розроблений консорціумом, що є об'єднанням постачальників і виробників програмного забезпечення. Метою їх роботи було — спільними зусиллями розробити і поширити незалежний фреймворк для швидкої розробки додатків з використанням накопиченого досвіду. Jennifer Stapleton, будучи одним із засновників і членом DSDM, внесла істотний внесок у компіляцію вихідних ідей і думок. Arie van Bennekum є одним з авторів Agile-маніфесту і брав активну участь у роботі консорціуму DSDM починаючи з 1997 року.
• 1995 — Scrum та Парне програмування. SCRUM був розроблений спільно Джефом Сазерлендом і Кеном Швабером. Парне програмування як концепція була описана одночасно і незалежно кількома авторами. Джим Копліен опублікував статтю «A Development Process Generative Pattern Language», в якій міститься опис патерну «Розробка в парах». Ларрі Константін писав про «Dynamic Duos» у своїй книзі «Constantine on Peopleware», опублікованій у тому ж році. Дана концепція стала складовою частиною методології Extreme Programming. Незалежно від того, що було виконано кілька досліджень, що демонструють ефективність програмування в парах, дана концепція не знайшла реального відображення в Agile-маніфесті.
• 1997 — Feature Driven Development. Методологію Feature Driven Development (FDD) розробив Джеф де Лука. Процес розробки ПЗ за методологією FDD був представлений світу за допомогою публікації книги «Java Modeling in Color with UML: Enterprise Components and Process», де Джеф виступив у співавторстві з Пітером Кодом. Пітер заснував компанію TogetherSoft, яку потім продав компанії Borland.
• 1999 — Адаптивна розробка. Джим Хайсміт сформулював концепцію Adaptive System Development і опублікував книгу з такою ж назвою. Ідея виросла з його роботи за методологіями швидкого створення додатків (RAD). Він запропонував три фази життєвого циклу: 1) Speculation; 2) Collaboration; 3) Learning. Під час роботи в Chrysler Кент Бек розробив концепцію екстремального програмування (Extreme Programming). Він опублікував цей метод в 1999 в книзі — Extreme Programming Explained. Частиною Extreme Programming є концепція історій користувача і планування релізу (Release Planning). Дана методологія описує найкращі практики у сфері планування, управління, проєктування, кодування і тестування. Ворд Каннінгем і Рон Джефрі також привнесли свої ідеї, так що всі троє вважаються засновниками методу EP.
• 2000 — Події, що призвели до маніфесту. Боб Мартін проявив ініціативу і взявся за організацію, що стала історичною, зустрічі, яка відбулася у лютому 2001 року на гірськолижному курорті. Він є власником компанії Uncle Bob Consulting.

Маніфест гнучкої розробки

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

Маніфест гнучкої розробки розроблений і прийнятий 17 розробниками 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. Основна мета — ефективне моделювання і документування; але не охоплює програмування та тестування, не включає питання управління проєктом, розгортання і супроводу системи. Однак включає в себе перевірку моделі кодом.
• 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). Використовує підходи з концепції бережливого виробництва.

Джерела

• Smith G. Improving the process of drafting families of software systems elements of agile methodologies / GI Smith, AL Kolesnik, K. Lavrischeva, O. Slabospitsky // programming problems. — 2010. — № 2-3. — S. 261—270. (англ.)
• История Agile (рос.)
• Статья Введение в гибкую разработку программного обеспечения (рос.)
• Статья Гибкий подход разработки ПО — Scrum (рос.)
• Статья Scrum — зачем заказчику знать такие непонятные слова? (рос.)
• Agile, каталог посилань Open Directory Project

• Two Ways to Build a Pyramid, John Mayo-Smith (VP Of Technology At R/GA), October 22, 2001
• The New Methodology Martin Fowler's description of the background to agile methods
• Ten Authors of The Agile Manifesto Celebrate its Tenth Anniversary
• A look into the PMI-ACP (Agile Certified Practitioner)