Метод «Водопад», безусловно, является жизнеспособным и столь же философски обоснованным, как и любой другой подход. Помните, что Waterfall существует намного дольше, чем Agile, но обратите внимание, что это не аргумент, чтобы утверждать, лучше ли одна методология, чем другая.
Вы используете метод «Водопад», когда имеете четкое представление обо всей проблемной области и о том, чего хочет достичь клиент в программном пакете. Возможно, вы указали фиксированную цену при заключении договора, и ваш клиент понимает, что он не может отклоняться от любых согласованных требований. Ваш процесс строго такой, который проходит через серию подписей между различными этапами разработки, и часто бывает так, что каждый этап завершается другой командой - иногда даже другой компанией - каждая из которых не обязательно может быть в связаться с остальными. Вы часто видите, что Водопад имеет хорошие результаты в военных и государственных проектах, когда они предлагаются внешним подрядчикам. Когда Waterfall и другие подобные подходы получают плохую репутацию, это когда разработчики сталкиваются с проблемами, такие как плохая оценка, графики, запланированные без непредвиденного времени, или плохое или неполное понимание проблемной области. Проблема никогда не является ошибкой методологии, а заключается в ее применении.
Сравнение Agile и любой методологии является ложным. Agile - это не методология, это философия, или, возможно, было бы лучше сказать, что это общий термин, который представляет другой взгляд на то, как вы занимаетесь разработкой программного обеспечения. Методология - это всего лишь инструмент, и поэтому ее ценность всегда будет меньше, чем у отдельных людей и взаимодействий, которые лежат в основе того, что значит быть гибким .
Кто-нибудь действительно думает, что минимизация изменений в программном обеспечении является жизнеспособным вариантом для тех, кто желает предоставить ценное программное обеспечение?
Любая возможность минимизировать изменения ценна как для разработчика, так и для заказчика. Изменения могут привести к сбою расписания или отсутствию функций для его соответствия. Именно как вы управляете последствиями изменений, которые влияют на стоимость ваших проектов.
Или действительно вопрос о том, какие методы лучше всего работают в наших ситуациях для управления неизбежными изменениями?
Ваша практика может помочь в управлении изменениями, или они могут полностью игнорировать изменения. Важным является сочетание ваших методов разработки и управления вашими отношениями с клиентами, а также то, насколько эффективно эти вещи работают вместе для всех вовлеченных сторон.
Те из нас, кто для всех намерений и целей Agile, понимают, что вы выбираете метод, который работает для вас. Если вам нравится определенный подход, следуйте ему. Если это не совсем соответствует вашим потребностям, измените его. То, как вы занимаетесь созданием программного обеспечения, сводится к тому, чтобы максимально эффективно использовать имеющиеся у вас ресурсы и свести к минимуму те практики, которые могут привести ваш проект к провалу, и вы часто обнаруживаете, что вам нужно изменить свой метод в соответствии с конкретный проект под рукой.
Одно дело сказать: «Хорошо, теперь мы Agile», и совсем другое - жить и работать по философии Agile. Используете ли вы водопад, инкрементный, спиральный, SCRUM, XP, FDD или любой другой метод, вы в основном Agile, где вы цените:
- Индивидуумы и взаимодействия над процессами и инструментами
- Рабочее программное обеспечение над всеобъемлющей документацией
- Сотрудничество с заказчиком в процессе переговоров
- Реагирование на изменения в соответствии с планом
и где вы объединяете свои инструменты, метод и ваш опыт для успешного применения этих ценностей.