Чи методологія розробки програмного забезпечення Waterfall все ще є життєздатною?

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

Чи є методологія розвитку водоспадів все-таки життєздатною для забезпечення програмних систем з урахуванням часу, витрат та якості?

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

Зі статті Вікіпедії:

Перший офіційний опис моделі водоспаду часто цитується як стаття Вінстона У. Ройса 1970 року, хоча Ройс у цій статті не використовував термін "водоспад". Ройс представив цю модель як приклад хибної, непрацюючої моделі.

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

Я вірю в цю концепцію, але реалізація, описана вище, є ризикованою і запрошує провал.

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

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

Люди не користуються підручником моделі водоспаду, і, мабуть, ніколи цього не мають.

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

Незважаючи на те, що це скоріше спосіб мислення, ніж процес, все-таки багато хто - напевно, більшість організацій ідуть на створення програмного забезпечення (або будинків, або підводних човнів, або будь-чого іншого ...).

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

Для Agile Snobs (TM) все добре і добре дивитися вниз на "старомодних" розробників та їх вигадливу, непрацездатну методологію водоспаду, але справа в тому, що Agile теж не панацея. Деякі проекти не можна побудувати за допомогою Agile, і багато команд, які вважають, що вони Agile, насправді просто неохайні та неорганізовані.

Методика не в цьому суть. Сенс полягає в тому, щоб подумати про те, що ви робите, і чому ви це робите саме так - і отримати максимальну цінність для замовника в найкоротші розумні терміни.

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

Можливо, кращий спосіб запитати, до чого ви стикаєтесь, "коли менш ітеративний і формально кращий?"

Є ситуації, коли це так:

• Коли вимоги не зміняться.

• При дотриманні нових вимог менш важливо, ніж потрапляння на 100% від початкових.

• Коли всі компоненти технології зрілі та добре зрозумілі.

У певному сенсі ти можеш сприймати протилежне тому, що може змусити тебе бути спритним.

Дуже мало техніки застосовується скрізь. Дуже мало хто не має користі.

Так, він дуже живий, хоча сьогодні це звичайніша " V модель ", яка використовується.

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

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

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

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

Кому? Більшість менеджерів, з якими я мав справу, досі використовують процес розробки програм водоспаду для планування, і вище рівня, схоже, він подобається для легкого планування.

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