Про моделі у світі SDLC
Чи просили вас порівняти Waterfall та Scrum ? Або Waterfall та Agile ? Багато де ви знайдете навіть порівняння. А що, якщо я скажу, що таке порівняння є некоректним ? Десь таким як порівнювати седан та гвинтокрил. Те саме і стосується і порівнянь Waterfall та Scrum.
Чому ? Бо Waterfall — це модель, а Scrum- методологія, а поняття Agile взагалі не підходить до одного чи іншого.
Сьогодні буде про моделі SDLC.
Давайте спочатку розберемось, що взагалі таке модель SDLC.
Software Development Life Cycle -абстракція, яка описує етапи, які потрібні для розробки ПЗ та їхню взаємодію.
Етапи чи стадії у різних джерелах називаються по різному, може бути більше чи менше, але мають один і той ж сенс. Це :
- Постановка завдання \ Аналіз вимог
- Розробка
- Тестування
- Підтримка \ Супровід
Власне, у різних SDLC ми по різному розглядаємо взаємодію між етапами. Етапи тут є високорівневі частинки процесу. Тут не йде мова про низькорівневі деталі: типу які наради проводити; чи писати документацію чи ні. Це вирішуються методологією та вашим внутрішнім процесом, але не моделлю SDLC.
Моделей SDLC існує декілька, але я виділю лише дві, котрі вважаю реальними:
- Waterfall або каскадна модель
- Ітеративна
Ви також можете в інтернеті зустріти й інші моделі, такі як інкрементна модель, V- модель чи спіральна. Але, я особисто ніде не зміг побачити якісь чіткі особливості цих моделей чи відмінності від двох перших. От був би радий почути чим відрізняється ітеративна від інкрементної модель. Або, наприклад, модель V має красиву діаграму, але якщо розібратись глибше,- це просто Waterfall з тестами на кожному етапі. Можна також виділити спіральну модель. Вона представлена Барі Бомом у 1986. І її я бачу як розширення ітеративної моделі за допомогою аналізу ризиків. Також, мені важко відповісти чим ця модель відрізняється від ітеративної.
Waterfall
Цю модель прийнято вважати першою. Я часто чую, що ця модель “використовується в основному на серйозних проектах”, але це все фігня. Вперше Waterfall назвали Waterfall-ом десь у 60-тих. Посилаються в основному на ось цю доповідь. Але в цій вже доповіді критикується Waterfall як модель! І це все у 60-тих роках! На мою думку, все логічно. Ви ніколи не зможете продумати всі вимоги чи всі нюанси архітектури спочатку. Поки ви будете обдумувати всі деталі — ваш продукт може стати не актуальним. І знову ж таки, ви ніколи не зможете прорахувати всі деталі і не упустити нічого.
Можливо, ця модель має сенс у маленьких проектах: короткотермінових та з командою в 1–2 людини, але розробляти щось більше у такій моделі нереально.
Якщо глянути на статтю, де описана модель Waterfall, ви зможете побачити рекомендації як її покращити. Всі ці рекомендації зводяться до повернення на попередні етапи. Тобто, якась подоба ітерації з’являється.
З цього всього, я готовий зробити висновок, що Waterfall як модель є мертвою і не може реально використовуватись у проектах.
Ітеративна модель
Розробляти будь що ітераціями виглядає логічною ідеєю. На завершення ітерації ми маємо робочу частину продукту. Маючи такий продукт, його можна показувати клієнтам та користувачам. Після оцінки клієнтами ми можемо бачити чи рухаємось у правильну сторону і зробити зміни у напрямку. Така модель використовується не лише у розробці ПЗ.
В одній ітерації ми проходимо всі етапи SDLC. І так кожної ітерації. Саме на базі ітеративної моделі базуються популярні методології, — такі як Scrum, де ітерація — спринт; RUP , де ітерація — це ітерація :) . І також Kanban, де ітерація — це швидше шлях однієї задачі від першої колонки до останньої.
Ітеративна модель використовується на проектах будь якої складності. Насправді, іноді ми неочевидно її використовуємо, розбиваючи завдання на підзавдання.
Власний досвід з Waterfall
Мені довелось працювати у компанії, яка за основу взяла модель Waterfall. Звісно, там можна побачити і щось від ітераційної моделі, але в основному був Waterfall. Це був десктопний додаток. Процес виглядав наступним чином: спочатку відділ маркетингу писав вимоги,- це було десь 60 сторінок. І я би не сказав, що це були вимоги. Швидше 60 сторінок, не дуже детального опису продукту. Пізніше розробники розробляли продукт на основі цих вимог. Вимоги не були чіткі, було багато незрозумілостей. І важливим моментом було те, що одразу хотіли розробити все, але протягом етапу розробки декілька разів змінювали технологію UI. І доводилось багато переробляти. Пізніше, це все мало йти на тестування. Уявляєте, просто в один день приходить великий білд, у якому потрібно тестувати абсолютно все. Те, що баги будуть ніхто не врахував і вони довго висіли відкриті і накопичувались.
Продукт випустили у світ. Десь після третього перенесення дати релізу я покинув команду, тому не можу сказати як було далі. Звісно, тут були не лише проблеми через саму модель, а й через консерватизм компанії та інженерів, брак комунікації. І це все призводило до фінансових втрат, які можна було уникнути розробляючи продукт ітераціями.
А що там Agile ?
Agile software development не є ні моделлю, ні методологією. Для мене це швидше філософія, але про це буде у окремій статті. Soon…
Summary
Якщо ваш проект пробує працювати у стилі Waterfall — змінюйте щось. Якщо не зміните, то з великою ймовірністю будете страждати часовими та фінансовими втратами.
P.S.
Дякую, що ви прочитали цю статтю. Я хочу бути максимально корисний Вам і тому, витратьте ще 1 хв на заповнення форми фідбеку. За це вам плюсик у карму !
