Гнучке розроблення ПЗ на основі Agile
Постійна зміна вимог під час розроблення ПЗ, необхідність забезпечення ефективної співпраці команди розробників потребували методів, які б забезпечили якість розроблення та супроводу програмних систем і уникнули недоліків занадто формалізованих методів, більшість з яких базувалась на каскадній моделі ЖЦ. У 90-х рр. ХХ ст. активно стали виникати різноманітні підходи до створення ПЗ, які забезпечували гнучку роботу програмістів. У результаті у 2001 році був написаний Маніфест гнучкого розроблення (Agile manifesto), що зафіксував цінності ефективних підходів до розроблення програмних продуктів, таких, як XP, Feature driven development, Scrum, Adaptive software development, Pragmatic Programming (прагматичне програмування). Текст маніфесту [35] підписали 17 найавторитетніших фахівців у цій галузі діяльності – Кент Бек (Kent Beck), Алістер Коуберн (Alistair Cockburn), Мартін Фаулер (Martin Fowler) та інші:
Agile-маніфест розроблення програмного забезпечення
Ми постійно відкриваємо для себе досконаліші методи розроблення програмного забезпечення, займаючись розробленням безпосередньо та допомагаючи у цьому іншим.
Завдяки цій роботі ми змогли зрозуміти, що:
Люди та співпраця важливіші за процеси та інструменти; Працюючий продукт важливіший за вичерпну документацію; Співпраця із замовником важливіша за обговорення умов контракту;
Готовність до змін важливіша за дотримання плану.
Хоча цінності, що справа, важливі, ми все ж цінуємо більше те, що зліва.
У результаті з’явився термін – Гнучке розроблення програмного забезпечення (Agile software development) – клас методологій розроблення програмного забезпечення, що базуються на ітеративному розробленні, в якому вимоги та рішення еволюціонують через співпрацю між самоорганізовуваними багатофункціональними командами.
У маніфесті озвучені основні принципи гнучкого розроблення ПЗ:
- Найвищий пріоритет – задоволення потреб замовника шляхом завчасного та регулярного постачання програмного забезпечення.
- Схвальне ставлення до змін, навіть на завершальних стадіях розроблення. Agile-процеси використовують зміни для забезпечення конкурентоспроможності замовника.
- Працюючий продукт необхідно випускати якомога частіше, з періодичністю від двох тижнів до двох-трьох місяців.
- Упродовж усього проекту розробники і представники бізнесу повинні працювати разом щодня.
- Над проектом повинні працювати вмотивовані професіонали, які працюють у зручних умовах, із повною підтримкою та довірою менеджменту проекту.
- Особиста комунікація – найефективніший та найпрактичніший метод обміну інформацією в команді.
- Працюючий продукт – головний показник прогресу.
- Інвестори, розробники і користувачі повинні мати можливість підтримувати постійний ритм роботи. Agile допомагає налагодити такий сталий процес розроблення.
- Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.
- Простота – мистецтво мінімізації зайвої роботи – дуже необхідна.
- Найкращі вимоги, архітектурні та технічні рішення виникають у командах, які здатні самоорганізовуватись.
- Команда постійно шукає способи підвищення ефективності та відповідно коригує свою роботу.
Більшість гнучких методологій націлені на мінімізацію ризиків шляхом зведення розроблення до серії коротких циклів – ітерацій, які, як правило, тривають один-два тижні. Кожна ітерація є програмним проектом у мініатюрі і включає всі завдання, необхідні для отримання мінімального приросту функціональності: планування, аналіз вимог, проектування, кодування, тестування та документування. Гнучкий програмний проект передбачає в кінці кожної ітерації отримання працездатного, готового до встановлення у реальному середовищі продукту. Після закінчення кожної ітерації команда виконує переоцінку пріоритетів розроблення.
Гнучкі методи орієнтовані на різні аспекти життєвого циклу розроблення програмного забезпечення. Деякі акцентують увагу на практичних завданнях (екстремальне програмування, прагматичне програмування, Agile- моделювання), інші зосереджені на управлінні програмними проектами (Scrum). Також серед agile-методів існують підходи, які забезпечують повне охоплення життєвого циклу розроблення – метод розроблення динамічних систем (dynamic systems development method, DSDM) та уніфікований процес розроблення (RUP), розглянутий вище. Більшість гнучких методів для використання упродовж життєвого циклу ПЗ потрібно доповнювати іншими підходами, окрім DSDM та RUP.
Особливістю гнучких методів є те, що на даний час відсутні дані про провальні agile-проекти, але є результати опитувань, які підтвердили їх успішне використання [36]. Тому і потужні компанії-розробники активно їх запроваджують у свою діяльність, наприклад, Oracle запроваджує гнучкі методи управління ЖЦ продуктів (Agile product lifecycle management), фірма IBM є власником продуктів, які підтримують використання методології RUP.
Потрібно виділити фактори, які можуть негативно вплинути на використання гнучких методів:
- масштабні зусилля у галузі розвитку (більше 20 розробників);
- розподілена у просторі команда;
- примусове впровадження гнучкого процесу усупереч вимогам команди розробників;
Небажане використання agile-методів у критично важливих системах (табл.6), де відмова ПЗ неможливий ні в якому разі (наприклад, управління повітряним рухом).
Таблиця 6 – Порівняння використання гнучких та формальних методів
| Agile-методи | Методи із чітким планом | Формалізовані методи |
| Низька критичність | Висока критичність | Життєвоважлива критичність |
| Досвідчені розробники | Молодші розробники | Досвідчені розробники |
| Вимоги часто змінюються | Вимоги змінюються не часто | Обмежені вимоги |
| Малі команди розробників | Великі групи розробників | Вимоги обов’язково моделюються |
| Культура, що залежить від змін | Стала культура розроблення | Екстремальна увага на якості розроблення |
Agile акцентує увагу на безпосередньому спілкуванні між учасниками проекту. Більшість agile-команд розміщені в одному офісі (bullpen). До команди обов’язково включають представників замовника (замовники, які визначають продукт, менеджери продукту, бізнес-аналітики або користувачі). Також до команди входять тестувальники, дизайнери інтерфейсу, технічні автори та менеджери.
Із agile-методів потрібно виділити Scrum, що встановлює правила керування процесом розроблення та дозволяє використовувати вже існуючі практики кодування, коригуючи вимоги або вносячи тактичні зміни. Використання цієї методології дає можливість виявляти і усувати відхилення від бажаного результату на найбільш ранніх етапах розроблення програмного продукту.
Scrum–методи ітераційні та інкрементні. Кожна ітерація (спринт) триває упродовж 15-30 днів і повинна закінчитися приростом функціональних можливостей. Під час спринту обов’язково відбуваються зустрічі дійових осіб:
- Планування спринту (Planning Meeting) – відбувається на початку ітерації. Не більше 4-8 годин.
- Мітинг (Daily Scrum) – відбувається кожного дня упродовж спринту. Триває 15 хвилин.
- Демонстрація (Demo Meeting) – відбувається в кінці ітерації (спринту). Обмежена 4 годинами.
- Ретроспектива (Retrospective Meeting). Усі члени команди розповідають про своє ставлення до ходу спринту. Обмежено 1-3 годинами.
Дійові особи розподіляються на дві групи:
- повністю задіяні у процесі розроблення («свині»):
- Власник Продукту (Product Owner);
- Керівник (ScrumMaster);
- Команда (Scrum Team);
- причетні до розроблення («кури»):
- Користувачі (Users);
- Клієнти, Продавці (Stakeholders);
- Експерти-консультанти (Consulting Experts).
Віддаючи перевагу безпосередньому спілкуванню, agile- методи зменшують обсяг письмової документації порівняно з іншими методами, що викликає критику прихильників більш формалізованих підходів.
Патерни проектування
Створюючи об’єкт, у тому числі й програмний продукт, розробник часто стикається із завданнями, які вже хто-небудь вирішив. У 70-ті рр. ХХ ст архітектор Кристофер Александер (Christopher Alexander) [37] запропонував шаблони проектування будинків та міст. Через десятиліття ця ідея переросла у процесі розроблення ПЗ до шаблонів проектування інтерфейсу користувача, запропонованих Вардом Каннінгемом (Ward Cunningham) та Кентом Беком [38]. Далі ідея була активно підхоплена та розвинута у вигляді каталогу патернів ООП. Цей каталог [39] став дуже популярним серед розробників і часто згадується як патерни GoF («Gang of Four», або «банда чотирьох», – за кількістю авторів). Ідея повторного використання не тільки коду, а й архітектурних та проектних рішень виявилася настільки успішною, що сьогодні патерни проектування широко застосовуються в різних методиках розроблення програмного забезпечення.
У роботі [39] під патернами проектування об’єктно- орієнтованих систем розуміють опис взаємодії об’єктів і класів, адаптованих для вирішення спільної задачі проектування в конкретному контексті.
Існує багато патернів розроблення програмних систем, які відмінні сферою застосуання, масштабом, змістом, стилем опису. Наприклад, залежно від області використання існують такі патерни, як патерни аналізу, проектування, кодування, рефакторингу, тестування, реалізації корпоративних застосувань, шаблони роботи з базами даних, шаблони розподілених додатків, шаблони роботи із багатопотоковістю, шаблони документування та ін.
В останнє десятиліття шаблони впроваджені навіть у роботу менеджера процесу розроблення ПЗ (Джеймса Коплі, Ніла Харрісона «Organizational Patterns of Agile Software Development», Тома Демарко, Тіма Лістера «Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior»).
У даний час найбільш популярними патернами є патерни проектування. Однією з найпоширеніших класифікацій таких патернів є класифікація за ступенем деталізації та рівнем абстракції розглянутих систем. Патерни проектування програмних систем поділяються на три категорії [40] (рис.44). Архітектурні патерни, найбільш високорівневі, описують структурну схему програмної системи в цілому. У даній схемі зазначаються окремі функціональні складові системи (підсистеми), а також взаємовідносини між ними. Прикладом архітектурного патерну є добре відома програмна парадигма “модель-вигляд-контролер” (model-view-controller – MVC).
Рисунок 44 – Шаблони проектування програмних систем
Ідіоми, низькорівневі патерни, мають справу з питаннями реалізації певної проблеми з урахуванням особливостей мови програмування. При цьому часто одні й ті самі ідіоми для різних мов програмування мають різний вигляд або взагалі відсутні. Наприклад, в C++ для усунення можливих втрат пам’яті можуть використовуватися інтелектуальні покажчики. Інтелектуальний покажчик містить покажчик на ділянку динамічно виділеної пам’яті, що буде автоматично звільнений при виході із зони видимості. У середовищі Java такої проблеми просто не існує, оскільки там використовується автоматичне складання сміття. Як правило, для використання ідіом потрібно глибоко знати особливості застосовуваної мови програмування.
Завдання кожного патерну – дати чіткий опис проблеми та її вирішення у відповідній області. У загальному випадку опис патерну завжди містить такі елементи [38]:
Назва патерну – унікальне змістове ім’я, що однозначно визначає дану задачу або проблему і її рішення.
Розв’язувана задача – надається розуміння того, чому розв’язувана проблема дійсно є такою, чітко описує її межі.
Рішення – зазначається, як саме дане рішення пов’язане з проблемою, наводяться шляхи її вирішення.
- Результати використання патерну – як правило, це переваги, недоліки та компроміси.
Рисунок 45 – Шаблони проектування інформаційнх систем
На рис.45 показана класифікація шаблонів проектування інформаційних систем [41].
Архітектурні патерни також об’єднуються у групи:
- структурні, архітектурні патерни – слугують для організації класів або об’єктів системи у базовій підструктурі;
- патерни управління – для забезпечення необхідного системного функціоналу.
У свою чергу, патерни управління розділені на патерни централізованого управління (патерни, в яких одна з підсистем повністю відповідає за управління, запускає і завершує роботу решти підсистем), патерни управління, які передбачають децентралізоване реагування на події (згідно з цим патернам на зовнішні події відповідає відповідна підсистема), та патерни, які описують організацію зв’язку з базою даних
Патерни інтеграції інформаційних систем знаходяться на верхньому рівні класифікації патернів проектування. Аналогічно патернам більш низьких рівнів класифікації серед патернів інтеграції виділена група структурних патернів. Структурні патерни описують основні компоненти інтегрованої метасистеми. Для опису взаємодії окремих корпоративних систем, включених до інтегрованої метасистеми, використовується група патернів, об’єднаних відповідно до методу інтеграції. Інтеграція корпоративних інформаційних систем передбачає організований обмін даними між системами, для якого використовується відповідний патерн. Необхідно зазначити, що на відміну від патернів проектування класів/об’єктів і архітектурних системних патернів віднесення окремого патерну інтеграції до того чи іншого виду є менш умовним.
Про шаблони проектування знають розробники, проектувальники, архітектори, але про це явище абсолютно нічого не відомо користувачам,для яких і розроблялася мова шаблонів Александера [37]. Основна роль шаблонів – це повторне використання досвіду в різних областях розроблення ПЗ, усунення комунікаційного бар’єру всередині команди розробників і між ними, підвищення якості створюваного продукту за рахунок використання перевірених роками рішень.