История изменений

Причин много. Расплывчатые причины: нехватка кадров, нехватка квалифицированных кадров, нехватка времени.

Можно попытаться каждый раз строить идеальный хрустальный дворец архитектуры, и затратить на это 10 лет, но кто все эти 10 лет будет оплачивать офисы, электричество, и платить зарплату. И из каких средств? И где гарантия, что за эти 10 лет получится адекватный результат, который будет удовлетворять заказчика?

По опыту, долгое проектирование и разработка чаще приводит только к раздуванию сроков и созданию излишней сложности. Что-то вроде «эффекта второй системы», описанного Бруксом (книгу читал более 15 лет назад, поэтому могу переврать название), когда создаётся очень долго «идеальная» система, в которой слишком много функций, на которые было затрачено слишком много труда, и которые в реальной жизни оказываются не нужны или не тем, что нужно заказчику.

Дополнительная сложность: каждый кто работал с заказчиками (людьми вообще), быстро узнаёт, что люди не понимают свои потребности и не могут внятно их изложить. Поэтому подход «давайте быстро сделаем минимальную версию, покажем заказчику, уточним требования, сделаем следующую итерацию» оказался наиболее подходящим к реалиям жизни.

В общем, мир несовершенен, не существует какого-либо метода, который гарантированно даёт хороший результат. Со временем просто набираешься опыта, начинаешь лучше понимать, что работает хорошо, что работает плохо, как-то использовать эти эвристики (сильно упрощенный пример — принципы SOLID).

Если создать какую-то всеобъемлющую методологию, в которой будет чётко прописано:

1. Сначала рисуем архитектуру используя все методы документирования UML и C4
2. Затем делаем прототип
3. Затем делаем проект, учитывая опыт, полученный при создании прототипа.

То всё равно получим кучу точек отказа. На первом этапе архитекторы могут оказаться не такими хорошими и придумать плохую или неподходящую архитектуру. Или нереализуемую из-за ограничений реального мира. Между вторым и третьим этапом может смениться команда, и опыт, полученный при реализации прототипа, будет утерян, в итоге получим просто два прототипа. И т.д. и т.п.

Не существует гарантированных способов чего-то добиться в этом мире.

Причин много. Расплывчатые причины: нехватка кадров, нехватка квалифицированных кадров, нехватка времени.

Можно попытаться каждый раз строить идеальный хрустальный дворец архитектуры, и затратишь на это 10 лет, но кто все эти 10 лет будет оплачивать офисы, электричество, и платить зарплату. И из каких средств? И где гарантия, что за эти 10 лет получится адекватный результат, который будет удовлетворять заказчика?

По опыту, долгое проектирование и разработка чаще приводит только к раздуванию сроков и созданию излишней сложности. Что-то вроде «эффекта второй системы», описанного Бруксом (книгу читал более 15 лет назад, поэтому могу переврать название), когда создаётся очень долго «идеальная» система, в которой слишком много функций, на которые было затрачено слишком много труда, и которые в реальной жизни оказываются не нужны или не тем, что нужно заказчику.

Дополнительная сложность: каждый кто работал с заказчиками (людьми вообще), быстро узнаёт, что люди не понимают свои потребности и не могут внятно их изложить. Поэтому подход «давайте быстро сделаем минимальную версию, покажем заказчику, уточним требования, сделаем следующую итерацию» оказался наиболее подходящим к реалиям жизни.

В общем, мир несовершенен, не существует какого-либо метода, который гарантированно даёт хороший результат. Со временем просто набираешься опыта, начинаешь лучше понимать, что работает хорошо, что работает плохо, как-то использовать эти эвристики (сильно упрощенный пример — принципы SOLID).

Если создать какую-то всеобъемлющую методологию, в которой будет чётко прописано:

1. Сначала рисуем архитектуру используя все методы документирования UML и C4
2. Затем делаем прототип
3. Затем делаем проект, учитывая опыт, полученный при создании прототипа.

То всё равно получим кучу точек отказа. На первом этапе архитекторы могут оказаться не такими хорошими и придумать плохую или неподходящую архитектуру. Или нереализуемую из-за ограничений реального мира. Между вторым и третьим этапом может смениться команда, и опыт, полученный при реализации прототипа, будет утерян, в итоге получим просто два прототипа. И т.д. и т.п.

Не существует гарантированных способов чего-то добиться в этом мире.