Метод Водоспаду, безумовно, життєздатний і такий же філософськи, як і будь-який інший підхід. Пам’ятайте, що Водоспад існує набагато довше, ніж Agile, але зауважте, що це не аргумент, щоб стверджувати, що одна методологія краща за іншу.
Ви використовуєте метод Водоспад, коли маєте чітке розуміння всієї проблемної області та того, що клієнт хоче досягти в програмному пакеті. Ви, ймовірно, цитували фіксовану ціну, приймаючи контракт, і ваш клієнт розуміє, що він не може відхилятися від будь-яких узгоджених вимог. Ваш процес суворо такий, який проходить через ряд підписань між різними етапами розвитку, і часто трапляється так, що кожен етап завершується різною командою - іноді навіть іншою компанією - кожен з яких не обов'язково повинен контакт з іншими. Ви часто бачите, як Водоспад застосовується з хорошим ефектом у військових та урядових проектах, коли вони подаються на сторонні підрядники. Коли Водоспад та інші подібні підходи отримують погану репутацію, коли розробники стикаються з проблемами, наприклад, погана оцінка, графіки, заплановані без надзвичайного часу, або неякісне або неповне розуміння проблемної області. Питання ніколи справді не є виною методології, а в її застосуванні.
Порівняння Agile та будь-якої методології є помилковим. Agile - це не методологія, це філософія, або, можливо, було б краще сказати, що це парасольовий термін, який представляє інший спосіб поглянути на те, як ви займаєтесь розробкою програмного забезпечення. Методологія - це лише інструмент, і як така її цінність завжди буде меншою, ніж індивіди та взаємодії, які лежать в основі того, що означає бути спритним .
Хтось насправді вважає, що мінімізація змін у програмному забезпеченні є життєздатним варіантом для тих, хто хоче поставити цінне програмне забезпечення?
Кожна можливість мінімізувати зміни цінна як для розробника, так і для замовника. Зміни можуть спричинити ковзання розкладу або залишити функції, щоб відповідати розкладу. Це як ви управляєте наслідками змін, які впливають на цінність ваших проектів.
Або справді виникає питання про те, які види практики найкраще працюють у наших ситуаціях для управління неминучими змінами?
Ваша практика може допомогти в управлінні змінами, або вони можуть повністю ігнорувати зміни. Важливим є поєднання вашої практики розвитку та управління вашими стосунками з вашими клієнтами, а також, чи ефективно ці справи працюють для всіх зацікавлених сторін.
Ті з нас, хто з усіма намірами та цілями Agile розуміють, що ви вибираєте метод, який працює для вас. Якщо вам подобається певний підхід, дотримуйтесь його. Якщо це не зовсім відповідає вашим потребам, змініть це. Як ви працюєте з розробкою програмного забезпечення, дійсно зводиться до того, щоб намагатися якнайкраще використовувати наявні у вас ресурси та мінімізувати ті практики, які можуть призвести ваш проект до провалу, і ви часто виявляєте, що вам потрібно змінити свій метод відповідно до відповідних конкретний проект під рукою.
Дійсно сказати "Ок, тепер ми спритні", і зовсім інше - насправді жити і працювати за філософією, що Agile є. Якщо ви використовуєте Водоспад, Інкрементальний, Спіраль, SCRUM, XP, FDD або будь-який інший метод, ви в основному Agile, де цінуєте:
- Індивіди та взаємодія над процесами та інструментами
- Працює програмне забезпечення над всеосяжною документацією
- Співпраця з клієнтами щодо укладання договорів
- Відповідаючи на зміни протягом наступного плану
і де ви разом переносите свої інструменти, метод та досвід, щоб успішно застосувати ці значення.