Що таке гнучка методологія? [зачинено]

Чи може хтось пояснити про гнучку методологію простими пропозиціями?

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

Ітеративний: Подумайте купу дуже маленьких водоспадів. Тобто метод водоспаду (вимоги -> специфікація -> код -> тест), але замість того, щоб робити це протягом року або близько того, ви робите це протягом декількох тижнів для керованого куска загальної кількості проект. Наприкінці "ітерації / спринту / збільшення" у вас є невеликий, але повний і перевірений набір додаткових функціональних можливостей.

Це дозволяє швидко змінити хід проекту, якщо виявиться, що те, що ти робиш, не те, що хоче клієнт, або бізнес потребує змін, або будь-що інше. Звідси і термін "спритний".

Я думаю, що нічого не ставить це краще, ніж сам маніфест Agile:

Ми розкриваємо кращі шляхи розробки
програмного забезпечення, роблячи це та допомагаючи іншим.
Завдяки цій роботі ми оцінили:

Особи та взаємодія над процесами та інструментами
Робоче програмне забезпечення над всеосяжною документацією
Співпраця з клієнтом над переговорними контрактами
Відповідає на зміни, випливаючи за планом

Тобто, хоча в елементах
праворуч є значення , ми більше цінуємо предмети зліва.

від http://agilemanifesto.org/

Для мене найважливіша ідея така:

Зміни вимог відбудуться через те, що ми змушені розробляти програмне забезпечення на самому рівні знань про те, що потрібно (старт проекту), а вимоги стануть яснішими лише протягом проекту.

Традиційні підходи (Водоспад) намагаються пом'якшити цю зміну, увімкнувши всіх у договір на початку проекту, домогшись їх підписання на комплексні характеристики. Це може працювати як CYA, але це не робить когось із задоволенням доставити щось, що не відповідає потребам користувачів, особливо якщо їхні заперечення відповідають "Добре ви підписалися на це!"

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

В одному реченні це виглядає приблизно так:

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

Це виходить із визначення вікіпедії, і мені це дуже подобається. Я виділив основні принципи.

Я хотів би також додати те, що Agile НЕ. Тут багато магазинів, які претендують на спритність, але таким чином, це означає, що вони не зацікавлені в плануванні своїх проектів і очікують, що вони будуть зроблені за необґрунтовано короткий проміжок часу.

Agile! = Немає плану проекту. Важко поводитися з людьми, які неявно вважають, що це твердження є помилковим, оскільки вони, як правило, є типами управління і не завжди легко суперечити.

Енді вже пов’язаний з Agile Manifesto, який, я думаю, саме про це висвітлює.

Я думаю, що корисно поглянути на те, звідки також з'явився Agile Manifesto. Там було декілька методологій, які мали деякі загальні елементи та багато подібних мотивацій: Екстремальне програмування (XP), Scrum, DSDM, Адаптивна розробка програмного забезпечення, Кристал, Розробка функцій, Прагматичне програмування (список з Алістера Кокберна ). Люди, що пропонують ці методології, вирішили придумати маркетинговий термін, щоб висвітлити речі, які у них були спільні, щоб посилити силу сказаного.

Цікаво (згідно з тим, що мені хтось сказав) у цьому списку було ряд імен, які можна було вибрати замість "Agile" - одне з яких було "Адаптивне". Я особисто думаю, що як єдине слово, яке підсумовує краще, що спритний насправді кращий, ніж "спритний"!

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

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

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

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

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