Безсмертна класика Водоспад

Серед запитань, що неминуче виникають в кожному проєкті, виокремлюється одне: як доцільніше управляти процесом розробки продукту? Один з варіантів відповіді, перевірений роками — Water­fall (або каскадна модель управління розробкою ПЗ).

Правда, зараз ця методика невпинно критикується, але чи так все погано насправді, чи ми черговий раз прийдемо до того, що все нове — добре забуте старе?

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

Практично кожна команда розробників може створювати свою модель життєвого циклу ПЗ або використовувати щось загальновизнане. Один з варіантів — Water­fall. ​“Батьком” такої моделі вважається американець В. У. Ройс, який, за чутками, багато запозичив у колег, привласнивши собі лаври. Це сталося в 1970 році. До сьогодні у багатьох проєктах використовується описаний ним підхід: в початковому варіанті чи з доопрацюваннями.

Хоча деякі учасники IT говорять про те, що такої методології ​“відродження ніколи не було”:

Як IT-професіонал і викладач я протягом більш ніж 40 років чув багато міфів про IT-індустрію. Але що продовжує дивувати мене, так це те, чому слово ​“Water­fall” досі використовується для опису методології, якої не існує, і чому творці методів розробки систем використовують його як джерело порівняння.
David Dis­chave,
професор школи інформаційних технологій університету Сиракуз, США

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

Water­fall в сфері IT 

Основний постулат моделі Water­fall полягає в тому, що наступний етап не може бути розпочатий, поки не завершений попередній. При цьому довільні переходи вперед або назад не допускаються, а етапи не перекривають одне одного. У цьому й полягає основна відмінність каскадної методології від гнучких братів (або конкурентів): Agile, DSDM, Scrum, FDD.

Щоб зрозуміти думки Ройса, покладені в основу моделі, можна вивчити його працю в оригіналі: Royce, Win­ston (1970), Man­ag­ing the Devel­op­ment of Large Soft­ware Systems.

Процес роботи, оснований на каскаді

Виникнення ідеї та її обговорення

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

Аналіз вимог

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

По закінченню аналізу вимог у наявності має бути ТЗ для програмістів та бюджет.

Проєктування програмного забезпечення

На цьому етапі робляться конкретні кроки:

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

Етап, на якому пишеться код, що відповідає документації, розробленій раніше.

Тестування програмного забезпечення

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

Технічна підтримка програмного забезпечення

Придатний до роботи програмний продукт починають використовувати за призначенням і здійснювати його підтримку. Тобто: слідкувати за працездатністю, усувати збої в роботі, планувати розширення функціоналу на основі відгуків від користувачів.

Усі вищезгадані етапи виконуються строго послідовно, отримані результати документуються.

Щоб зрозуміти еволюцію класичної каскадної методології, описаної вище, можна вивчити PMBOK. Між 3‑ою та 4‑ю версіями є ряд відмінностей, які допоможуть зрозуміти шлях ​“каскаду”.

Плюси і мінуси каскадної моделі розробки програмного забезпечення

Нічого ідеального в нашому світі, на жаль, не існує, тому у каскадної методології теж є сильні та слабкі сторони.

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

Як і коли використовувати каскадну модель розробки?

Як показує практика, модель Water­fall цілком доречна у наступних випадках:

1. замовник бере участь у проєкті лише на першому етапі і приймає готовий продукт;
2. змінювати вимоги до продукту не планується;
3. проєкт відрізняється високою складністю, тривалістю і дорожнечею;
4. основний пріоритет — якість, навіть у збиток часу;
5. відсутність команди розробників екстра-класу;
6. допускається можливість виконання проєкту на аутсорсі.

Для розуміння ж мотивації відмови від каскадної методології можна прочитати книгу ​“Scrum. Революційний метод управління проєктами” Джеффа Сазерленда.

Приклади використання Waterfall

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

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

Розуміння особливостей роботи з такими проєктами поліпшує книга Сергія Зикова ​“Основи проєктування корпоративних систем”.

І це логічно. Про це говорить і Чак Кобб, автор книг, присвячених Agile-методам у проєктному менеджменті, наставник, інструктор:

Якщо б ви будували міст через річку, було б смішно сказати: ​“Ми побудуємо перший прогін, подивимося, як це виходить, а потім вирішимо, як закінчити залишкові прогини!

Серед компаній, в яких використовували або використовують Water­fall, можна відзначити:

Назва компанії	Для чого використовувалася модель Waterfall	Використовується чи зараз методологія	Коментар представника компанії
Wüsten­rot & Würt­tem­ber­gis­che (W&W)	Розробка ERP-системи для фінансового сектора	Немає даних	_
Cis­co	Розробка систем безпеки	Так	_
EPAM	Різноманітні продукти і рішення або їх частини	Так	Олексій Іонов: “…не обов’язково весь великий проєкт робити за Agile — можна використовувати гнучку розробку в рамках окремих фаз або потоків робіт…”
IBM	Різноманітні продукти і рішення або їх частини	Так	Розалінда Редкліфф: ​“Настав час, коли команди розробників, що займаються водопадом, не в змозі виконати вимоги бізнесу, тому ці проєкти і продукти отримують більше роботи по технічному обслуговуванню… Водопад буде поступово замінений новими технологіями та новими командами, зацікавленими у впровадженні нових бізнес-практик”.
Microsoft IT	Різноманітні продукти і рішення або їх частини	Ні	“Протягом останніх кількох років… усі наші команди прийняли гнучку методологію. Ми виявили, що вона вирішила багато проблем, пов’язаних із традиційною моделлю водопаду, де проєкти плануються заздалегідь і можуть зайняти місяці або навіть роки. У рамках цієї моделі продукт може виявитися застарілим, як тільки ми його випустили”.
AT Con­sult­ing	Різноманітні продукти і рішення або їх частини	Так	Василь Кораблев: ​“Для розробки систем з нуля ми використовуємо один з підходів гнучкої (Agile) або каскадної (water­fall) розробки, або їх комбінації”.
Par­al­lels	Різноманітні продукти і рішення або їх частини	Так	Микола Добровольський: ​“В різних проєктах у нас використовуються різні підходи — десь Agile з одно-двохтижневими спринтами, а десь — майже що Water­fall з майлстоунами по кілька місяців. За багато років роботи у нас склалося враження, що чим більший проєкт і команда, що працює над ним, тим складніше і менш ефективно намагатися приліпити розробку до agile-процесу”.
SAP	Різноманітні продукти і рішення або їх частини	Так	Євгеній Арнаутов: ​“На етапі створення продукту часто можна бачити варіанти Agile, причому іноді поєднані з Waterfall-підходом”.
Toy­ota	Різноманітні продукти і рішення або їх частини	Ні	Сатоші Ішії: “…ми намагаємося навчитися застосовувати TPS (Lean на Заході) до розробки програмного забезпечення”.

Додатки та програми для управління розробкою за каскадною моделлю

Для роботи з ​“водопадом” можна використовувати ряд сервісів для постановки задач. Ключові критерії — наявність тайм-трекера, канбан-дошок і діаграми Ганта.

Work­sec­tion

Привабливий український saas-сервіс з зручною мобільною версією.

Підходить для чіткого планування, оскільки є:

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

Вирок

Water­fall — методологія, що використовується досить давно і, що б не говорили критики, в ряді випадків — ефективно.

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