Гнучка розробка програмного забезпечення
Гнучка́ розро́бка програ́много забезпе́чення (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв'язки еволюціонують через співпрацю між багатофункціональними командами здатними до самоорганізації. Гнучка розробка — засіб для підвищення продуктивності розробників програмного забезпечення.
Більшість гнучких методологій націлені на мінімізацію ризиків, шляхом зведення розробки до серії коротких циклів, що мають назву ітерацій, які зазвичай тривають один-два тижні. Кожна ітерація сама по собі виглядає як програмний проєкт в мініатюрі, і включає всі завдання, необхідні для видачі мінімального приросту за функціональністю: планування, аналіз вимог, проєктування, кодування, тестування і документування. Хоча окрема ітерація, як правило, недостатня для випуску нової версії продукту, мається на увазі те, що гнучкий програмний проєкт готовий до випуску наприкінці кожної ітерації. Після закінчення кожної ітерації, команда виконує переоцінку пріоритетів розробки.
| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
|
| Стандарти та галузі знань |
У розробці програмного забезпечення практичні методи agile включають вивчення, дослідження вимог і вдосконалення рішень за допомогою спільних зусиль команд, які об'єднують фахівців у різних галузях та які здатні самоорганізуватися, зі своїми клієнтами/кінцевими користувачами, адаптивне планування, еволюційну розробку, швидку доставку, постійне вдосконалення та гнучкі реакції на зміни вимог, потенціал, та розуміння проблем, які необхідно вирішити.
Agile акцентує увагу на безпосередньому спілкуванні «віч-на-віч». Більшість agile команд розташовані в одному офісі, його іноді називають bullpen. Як мінімум вона включає і «замовників» (замовники, які визначають продукт, також це можуть бути менеджери продукту, бізнес аналітики або клієнти). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних авторів і менеджерів.
Основною метрикою agile методів є робочий продукт. Віддаючи перевагу безпосередньому спілкуванню, agile-методи зменшують обсяг письмової документації в порівнянні з іншими методами. Це привело до критики цих методів як недисциплінованих.
Історія
Ітераційні та інкрементальні методи розробки програмного забезпечення можна простежити ще в 1957 році, з еволюційним управлінням проектами та адаптивною розробкою програмного забезпечення, що з’явилися на початку 1970-х років.
Протягом 1990-х років ряд полегшених методів розробки програмного забезпечення розвинувся як реакція на переважаючі "важкі" методи (часто іменовані разом як Водоспад, англ. Waterfall), які критики описували як надмірно регламентовані, сплановані та мікрокеровані. Полегшені методи включали: швидку розробку додатків з 1991 року; уніфікований процес і метод розробки динамічних систем (англ. dynamic systems development method(DSDM)), обидва з 1994 року; Scrum, з 1995 року; екстремальне програмування(англ. Crystal Clear and extreme programming), обидва з 1996 року; і розробка, керована функціями, з 1997 року. Хоча всі вони виникли до публікації Agile Маніфест(англ. Agile Manifesto), зараз їх спільно називають методами гнучкої розробки програмного забезпечення. У той же час подібні зміни відбувалися у виробничому та управлінському мисленні.
У 2001 році сімнадцять розробників програмного забезпечення зустрілися на курорті в Сноуберд, штат Юта, щоб обговорити полегшені методи розробки. Ними були: Кент Бек, Ворд Каннінгем, Дейв Томас, Джефф Сазерленд, Кен Швабер, Джим Хайсміт, Алістер Кокберн, Роберт С. Мартін, Майк Бідл, Арі ван Беннекум, Мартін Фаулер, Джеймс Греннінг, Ендрю Хант, Рон Джеффріс, Джон Керн , Брайан Марік і Стів Меллор. Разом вони опублікували Маніфест для гнучкої розробки програмного забезпечення (англ. the Manifesto for Agile Software Development).
У 2005 році група на чолі з Кокберном і Хайсмітом написала додаток(примітки) до принципів управління проектами, Декларацію взаємозалежності PM(англ. the PM Declaration of Interdependence), щоб керувати проектами програмного забезпечення відповідно до методів гнучкої розробки програмного забезпечення.
У 2009 році група, яка працювала з Мартіном, написала розширення принципів розробки програмного забезпечення, Маніфест майстерності програмного забезпечення(англ. Software Craftsmanship Manifesto), щоб скеровувати гнучку розробку програмного забезпечення відповідно до професійної поведінки та майстерності.
У 2011 році Agile Alliance створив Посібник з застосування Agile(англ. Agile Practices) (у 2016 році перейменований в Agile Glossary), з відкритим збірником робочих визначень практик, термінів та елементів, а також інтерпретацій та рекомендацій щодо досвіду від світової спільноти agile-практиків.
Маніфест Agile розробки програмного забезпечення
Принципи Agile розробки програмного забезпечення
Огляд
Філософія
Методи гнучкої розробки програмного забезпечення
Досвід і запровадження
Agile управління/менеджмент
Критика
Багато керівників проєктів, що працюють у традиційних методологіях на кшталт «водоспаду», критикують agile-методи.
Один з повторюваних пунктів критики: при agile-підході часто нехтують створенням «дорожньої карти» розвитку продукту, так само як і управлінням вимогами, в процесі якого і формується така «карта». Гнучкий підхід до управління вимогами не має на увазі далекосяжних планів (по суті, управління вимогами просто не існує в даній методології), а має на увазі можливість замовника раптом і несподівано наприкінці кожної ітерації виставляти нові вимоги, що часто суперечать архітектурі вже створеного і поставленого продукту. Таке іноді призводить до катастрофічних «авралів» з масовим рефакторингом і переробками практично на кожній черговій ітерації.
Крім того вважається, що робота в agile мотивує розробників вирішувати всі прибулі завдання найпростішим і найшвидшим можливим способом, при цьому часто не звертаючи уваги на коректність коду з точки зору вимог базової платформи (підхід «працює, та й добре», при цьому не враховується, що може перестати працювати при найменшій зміні або ж породити важкі до відтворення дефекти після реального розгортання у клієнта). Це призводить до зниження якості продукту і накопиченню дефектів.
Agile-практика була названа потенційно неефективною у великих організаціях і певних типах розвитку. Багато організацій вважають, що методології гнучкої розробки програмного забезпечення є занадто екстремальними, і використовують гібридний підхід, який змішує елементи гнучкої розробки програмного забезпечення та підходи, керовані планом. Деякі методи, такі як метод розробки динамічних систем (англ. dynamic systems development method(DSDM)), намагаються зробити це дисципліновано, не жертвуючи фундаментальними принципами.
Зростаюче впровадження гнучких практик також піддавалося критиці як примха менеджменту, яка просто описує існуючі передові практики на новому жаргоні, пропагує єдиний спосіб мислення для всіх щодо стратегій розвитку та неправильно наголошує на методах, а не на результатах.
Алістер Кокберн організовував святкування 10-ї річниці Маніфесту для гнучкої розробки програмного забезпечення (англ. the Manifesto for Agile Software Development) в Сноуберді, штат Юта, 12 лютого 2011 року, зібравши близько 30+ людей, які брали участь у початковій зустрічі та з того часу. Було зібрано список з близько 20 необговорюваних тем/проблем щодо agile, включаючи аспекти: альянси, збої та обмеження практик гнучкої розробки програмного забезпечення та контекст (можливі причини: комерційні інтереси, деконтекстуалізація, відсутність очевидного способу досягти прогресу на основі невдач, обмежених об’єктивних доказів, когнітивних упереджень і помилок у міркуванні), політики та культури. Як писав Філіп Крюхтен:
Agile-рух у чомусь схожий на підлітка: дуже сором'язливий, постійно перевіряє свій вигляд в дзеркалі, приймає небагато критики, зацікавлений лише в тому, щоб бути з однолітками, відкидає по одному всі мудрості з минулого лише тому, що це з минулого, запроваджує моду та новий жаргон, часом зухвалий і зарозумілий. Але я не сумніваюся, що він дозріє далі, стане більш відкритим для зовнішнього світу, більш рефлексивним, а отже, ефективнішим. ―Філіп Крюхтен
«Маніфест» міг негативно вплинути на управління та керівництво вищою освітою, де він пропонував адміністраторам замінити повільніші традиційні та дорадчі процеси на більш «спритніші». Ця концепція рідко знаходила визнання серед викладачів університету.
Інша критика полягає в тому, що багато в чому Agile-менеджмент і традиційні методи управління в кінцевому підсумку суперечать один одному. Звичайна критика цієї практики полягає в тому, що час, витрачений на спроби навчитися та впровадити практику, є надто дорогим, незважаючи на потенційні вигоди. Перехід від традиційного менеджменту до Agile-менеджменту вимагає повного підпорядкування Agile і твердої прихильності всіх членів організації довести процес до кінця. Такі проблеми, як неоднакові результати по всій організації, занадто великі зміни, з якими співробітники не здатні впоратися, або відсутність гарантій наприкінці трансформації — це лише кілька прикладів.