Серед багатьох питань, які рано чи пізно виникають у кожному проєкті, є одне особливо важливе: як найкраще керувати процесом розробки продукту?
Один із перевірених роками варіантів — Waterfall, або каскадна модель управління розробкою програмного забезпечення.
Сьогодні цю методологію часто критикують. Але чи справді вона настільки погана? Чи ми знову побачимо, що історія повторюється?
Життєвий цикл розробки програмного забезпечення
Кожна команда розробників може створити власну модель життєвого циклу програмного забезпечення або використати вже відомий підхід. Один із таких підходів — Waterfall.
Засновником цієї моделі вважають американця Вінстона Ройса. Його робота була представлена у 1970 році, і відтоді метод, описаний Ройсом, використовують у багатьох проєктах: як у первинному вигляді, так і в змінених варіаціях.
Водночас, деякі IT-фахівці стверджують, що такої методології фактично ніколи не існувало в тому вигляді, у якому її часто описують.
Цікаво чути такі твердження про підхід, який десятиліттями застосовували в розробці програмного забезпечення, автомобільній галузі, будівництві, фінансах, медицині, електроніці та інших сферах.
Waterfall в IT
Головний принцип Waterfall у розробці програмного забезпечення полягає в тому, що кожен наступний етап починається тільки після повного завершення попереднього.
При цьому довільні переходи вперед або назад не передбачені, а фази не повинні накладатися одна на одну.
Саме це відрізняє каскадну методологію від гнучких підходів, таких як Agile, DSDM, Scrum або FDD.
Каскадний робочий процес
Формування та обговорення ідеї
На цьому етапі розробка фактично ще не починається. Є лише нова ідея, яка зацікавила одну або кількох людей.
Аналіз вимог
Цей етап передбачає максимально детальний опис вимог замовника до проєкту.
Потрібно визначити:
- способи досягнення мети;
- строки виконання робіт;
- фінансову частину;
- резерв часу й бюджету для кожного блоку робіт.
Після завершення аналізу вимог команда має готове технічне завдання для програмістів і сформований бюджет.
Проєктування програмного забезпечення
Тут команда визначає ключові технічні рішення.
Зазвичай сюди входить:
- вибір платформи програмування, наприклад Python, PHP, JavaScript тощо;
- уточнення технічних деталей: взаємодія сервісу або продукту із серверами, використання API, логіка зовнішнього та внутрішнього інтерфейсів;
- розв’язання питань безпеки: використання HTTPS, SSL-шифрування та інших засобів захисту;
- визначення ролей користувачів продукту: адміністратор, клієнт, менеджер тощо;
- фіналізація питань надійності, ефективності та подальшої технічної підтримки продукту;
- формування окремої команди для реалізації проєкту.
Розробка програмного забезпечення
На цьому етапі команда пише код відповідно до документів, які були підготовлені раніше.
Тестування програмного забезпечення
Фахівці тестують фінальну версію продукту в умовах, максимально наближених до реальних, і фіксують помилки.
Найбільш критичні баги, які впливають на роботу продукту виправляються. Менш важливі можуть залишитися без виправлення, якщо закінчився час або бюджет.
Технічна підтримка програмного забезпечення
Готовий працездатний продукт запускають у використання за призначенням і супроводжують.
Підтримка включає:
- контроль працездатності продукту;
- виправлення збоїв;
- планування оновлень функціоналу на основі зворотного зв’язку користувачів.
Усі ці фази виконуються у суворій послідовності, а результати кожного етапу фіксуються.
Переваги та недоліки каскадної моделі розробки
Як і будь-який підхід, Waterfall має сильні та слабкі сторони.
| Переваги каскадної моделі | Недоліки каскадної моделі |
|---|---|
| Кожен етап роботи максимально деталізований, а його перебіг фіксується | Підтримка детальної документації займає багато часу, а замовнику вона не завжди зрозуміла |
| Вимоги прописані максимально чітко й не повинні суперечити одна одній або змінюватися в процесі роботи | Потрібні кваліфіковані бізнес-аналітики, які можуть підготувати технічне завдання для ефективної роботи |
| Можна заздалегідь оцінити, скільки часу й грошей знадобиться на проєкт | Якщо під час розробки виявиться, що продукт не відповідає вимогам ринку, простору для маневру майже немає |
| Методологія зрозуміла навіть розробникам із невеликим досвідом | Витрати часу й бюджету можуть бути доволі високими |
| Проєкт легко контролювати й за потреби передати іншій команді завдяки суворій системі звітності | Критичні проблеми часто виявляються на фінальному етапі, а їх виправлення в готовому продукті коштує дуже дорого |
Як використовувати каскадну модель розробки і в яких випадках?
На практиці Waterfall може бути доречним у таких випадках:
- замовник бере участь у проєкті лише на першому етапі, а потім приймає готовий продукт;
- вимоги до продукту не будуть змінюватися;
- проєкт складний, довгостроковий і дорогий;
- якість є головним пріоритетом, навіть якщо це впливає на строки;
- у команди немає великої кількості розробників найвищого рівня;
- є можливість залучити зовнішніх спеціалістів для реалізації проєкту.
Щоб краще зрозуміти, чому команди можуть відмовлятися від каскадної методології, варто також звернути увагу на підходи Scrum та гнучкого управління проєктами.
Приклади використання Waterfall
У чистому вигляді каскадна модель у сучасній розробці трапляється не так часто. Нерідко Waterfall називають усе, що не можна віднести до Agile, тому визначити реальне використання саме цієї методології не завжди просто.
За оцінками експертів, значна частина ERP-систем, програм для будівництва, медицини, державних контрактів, промислового використання та інших фундаментальних напрямів створюється з використанням модифікованих версій Waterfall.
Це логічно. Наприклад, якщо потрібно побудувати міст через річку, дивно було б сказати: “Спочатку побудуємо перший проліт, потім подивимось, що вийшло, і вже тоді вирішимо, чи добудовувати решту”.
Компанії, де використовували або використовують Waterfall
| Компанія | Для чого використовували Waterfall | Чи використовується зараз | Коментар |
|---|---|---|---|
| Wüstenrot & Württembergische | Розробка ERP-системи для фінансового сектору | Немає даних | — |
| Cisco | Розробка систем безпеки | Так | — |
| EPAM | Різні продукти, рішення або їх частини | Так | Agile не обов’язково застосовувати до всього великого проєкту, гнучку розробку можна використовувати на окремих етапах або в окремих процесах |
| IBM | Різні продукти, рішення або їх частини | Так | Waterfall-проєкти дедалі частіше потребують підтримки, а нові технології поступово замінюють старі підходи |
| Microsoft IT | Різні продукти, рішення або їх частини | Ні | Команди перейшли на гнучкі методології, бо традиційна модель Waterfall часто створювала проблеми через довге попереднє планування |
| AT Consulting | Розробка систем з нуля | Так | Використовують Agile, Waterfall або поєднання обох підходів |
| Parallels | Різні продукти, рішення або їх частини | Так | У різних проєктах застосовують різні підходи: Agile зі спринтами або квазі-Waterfall із довшими етапами |
| SAP | Різні продукти, рішення або їх частини | Так | На етапі створення продукту можуть використовуватися варіанти Agile або поєднання Agile з Waterfall |
| Toyota | Різні продукти, рішення або їх частини | Ні | Компанія вивчає, як застосовувати TPS, або Lean, до розробки програмного забезпечення |
Програми та інструменти для управління розробкою за каскадною моделлю
Для роботи з Waterfall можна використовувати інструменти, які допомагають відстежувати час, планувати етапи та будувати діаграми Ганта.
Worksection
Worksection — український SaaS-сервіс для управління проєктами зручною мобільною версією.
Він підходить для ретельного планування завдяки таким можливостям:
- діаграма Ганта зі зв’язками між задачами та дедлайнами;
- розподіл обов’язків між виконавцями з різними правами доступу;
- система різних форм звітності;
- збереження коментарів, реакцій і всієї історії активності в межах проєкту;
- обмежений доступ для замовника або клієнта для прозорості процесу розробки;
- можливість вказувати бюджети та витрати;
- чеклісти для невеликих етапів задач, щоб виконувати роботу точно за інструкцією.
Підсумуємо?
Waterfall — методологія, яку використовують уже давно. І попри критику, у багатьох випадках вона залишається ефективною. Водночас у чистому вигляді цей підхід не підходить для багатьох проєктів, де потрібно швидко реагувати на зміни ринку.
З досвіду великих компаній можна зробити висновок: Waterfall має своє місце в сучасних проєктах. Але його використання виправдане там, де вимоги стабільні й точно не зміняться до завершення проєкту.