Разные методологии для разных доменов?

Одним словом, нет. Не для каждого домена.

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

Многие другие домены / приложения не могут оправдать такие расходы.

Даже в пределах одного домена вы найдете разные ответы (рабочие компьютеры в самом космическом шаттле или ноутбуки, которые астронавты берут с собой).

Как обычно, на подобный вопрос ответ будет: «Это зависит» ... слишком много факторов поставлено на карту, чтобы дать общий ответ по каждой области.

Я разговаривал с людьми, которые помогали программировать космические миссии, такими как «Кассини» и марсоходы. Каждая строка кода проверяется всей командой. Все практики гибкой разработки работают как итерационные циклы. В конце каждого цикла владельцы продуктов выбирают следующий модуль, который они хотят видеть следующим из журнала, или они могут вставить что-то совершенно новое. В критических системах, где нет права на ошибку, все необходимые функции и правила системы четко устанавливаются довольно рано. Это означает, что гибкие методы, вероятно, не подойдут.

Я думаю, что многим людям комфортно с методологиями, которые они используют, и они закрыты для новых методологий. Даже для крайних проблемных областей есть явные преимущества TDD и других методов Agile. Очевидно, что в подобных пространствах должен быть проведен значительный объем тестирования, особенно по сравнению с менее важными приложениями.

Независимо от того, в какой области вы находитесь, предварительные разработки, как правило, приводят к серьезным сбоям, которые значительно изменятся в процессе разработки. Внедрение Agile-практик (возможно, даже их гибридов или Waterfall и Agile), безусловно, принесет мне пользу.

Как и при использовании правильного инструмента для работы, я говорю, что используйте правильную методологию для работы. Нет вообще правильных ответов / парадигм / инструментов / и т. Д. ... все должно быть помещено в контекст.