Agile Розробка програмного забезпечення 101

Відеоролик: Agile и Scrum на пальцах / О ГИБКИХ методологиях разработки ПО понятным языком

Зміст

Короткий огляд життєвого циклу розробки програмного забезпечення
Чому гнучкі розробки різні
Agile Practices
Чому йти Agile?
Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя

Винос:

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

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

Короткий огляд життєвого циклу розробки програмного забезпечення

Життєвий цикл розробки програмного забезпечення (SDLC) - це процес створення програмних рішень або модифікації існуючих структур, призначених для задоволення певної проблеми. Він охоплює різні етапи, які виконуються в логічному порядку. У традиційних моделях SDLC це етапи, які виконуються один за одним і зазвичай виконуються ізольовано:

Збір вимог від клієнтів
Системний та техніко-економічний аналіз
Дизайн та моделювання
Кодування або реалізація
Тестування
Розгортання та доставка
Запити на обслуговування та зміни

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

Чому гнучкі розробки різні

Найпоширеніші традиційні моделі SDLC - модель водоспаду, модель швидкого застосування, ітеративна модель, спіральна модель тощо - мають свій набір плюсів і мінусів. Минуло століття, перш ніж люди змогли фактично проаналізувати, наскільки реалістичні ці моделі. Вони ідеально вписуються в ідеальні сценарії, але вони не завжди були практичними, якщо мова йде про реальні програми. В результаті команди з розробки програмного забезпечення зіткнулися з безліччю проблем. Деякі обмеження звичайних моделей SDLC включають:

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

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

Agile Practices

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

Хоча не існує вичерпного переліку принципів Agile, існують певні практики, які Agile поширює. До них належать:

Тестова розробка (TDD)
В ідеалі розробники повинні спершу написати тестові випадки для того, який функціонал вони збираються кодувати. Це забезпечить якісний код, який є меншим шансом на поломку у виняткових умовах. Цей процес також допомагає гарантувати відповідність специфікацій користувача.
Парне програмування
У розробці Agile програмісти, як правило, працюють над однією і тією ж проблемою в парах, де одна людина пише код (драйвер), а інша переглядає код і надає ідеї та пропозиції (навігатор). Це підвищує продуктивність і скорочує час, необхідний для перегляду коду.
Код рефакторингу
Рефакторинг коду включає розбиття коду на більш дрібні та прості модулі, які можуть (і повинні) існувати незалежно в ідеальному сценарії. Це значною мірою покращує читабельність, достовірність та збереженість коду.
Активна участь реальних зацікавлених сторін
Після регулярних інтервалів певного періоду часу (іменованих як "ss") клієнти повинні отримати значний робочий прототип програмного забезпечення. Це дозволяє розробникам отримувати зворотній зв'язок щодо того, що вони будують, як вони йдуть.
Розглядайте вимоги як пріоритетну групу
У Agile важливо класифікувати вимоги виходячи з їх важливості. Це може включати як неявні, так і явні очікування клієнтів щодо розроблюваного програмного продукту. Команда з розробки програмного забезпечення повинна спільно оцінювати час та ресурси, які вони збираються інвестувати на реалізацію функції, та відображати їх, грунтуючись на вимогах користувачів та відносному порядку, в якому вони будуть вирішувати кожну частину проекту.
Регресійне тестування
Регресійне тестування включає тестування функціональності всієї програми після додавання нової функції або зміни існуючої функціональності в коді. Це допомагає переконатися, що зміни не порушили існуючий код.

Чому йти Agile?

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