Ну, не исчезли, но да, их как-то совсем мало стало. Сейчас зашёл на агрегатор, и там для PCIe звуковух всего 5 вариантов: $60, $150, $250, $1000 и $1800. К профессиональным, надо полагать, относятся последние две.
Тесты проверяют на наличие любых изменений - а в новой версии изменения есть по определению, так что падение части тестов это норма. На совместимость должны проверять совершенно отдельные тесты, заточенные под это специально - что потребует, для начала, определить само понятие "совместимость" для конкретного продукта, а потом ещё и научиться его надёжно тестировать. На данный момент такого типа тесты если и встречаются, то это большая редкость.
Обычно "совместимость" контролируется либо формальными инструментами (которые проверяют только техническую совместимость API библиотеки или .proto-файла но не семантику/поведение этого API) либо вообще вручную (напр. для REST/OpenAPI мне такие линтеры как для proto пока не встречались). Тесты на семантику API написанные именно с целью контроля совместимости попадались редко и не были выделены в отдельную группу тестов совместимости, а были размазаны среди прочих (т.е. было крайне сложно понять что тестируется в этом плане, а что нет).
подбирать кабели на звук и менять ЦАПы ради едва уловимой разницы в тембре, которую остальные никогда не услышат даже при всем желании
В золотые кабели со стрелочками я лично не верю, но вот что касается "остальные никогда не услышат" - это сильно зависит как от того, на каких колонках/наушниках слушать, так и от собственно слуха. Если слуха нет либо колонки/наушники относительно дешёвые - разницу действительно услышать не получится, разве что чисто психологически она там померещится. Но если слух нормальный и колонки/наушники достаточно крутые, то разницу между встроенным в материнку звуком и отдельной звуковой картой услышать достаточно легко (особенно если слушать не mp3, а любой lossless формат).
Через час после всех тестов в ci получить ошибку типов при билде очень больно
Больно, да. Но все гошники дофига лет с этим жили, и, в целом, были довольны своим ЯП. Ну т.е. больно, но не так чтобы очень. Где это было неприемлемо - вендорили.
не все перешли
Честно, не знаю таких примеров. Есть устаревшие, не поддерживаемые проекты, которые никто не обновлял - это да. А вот актуальные, поддерживаемые, и продолжающие жить в GOPATH без версий - я не сталкивался. Наверное, пару исключений найдётся, если специально искать, но на фоне общего количества проектов на го - это погрешность, а не статистика.
и это всё равно ничего не доказывает
Почему не доказывает? Как по мне - это идеальное доказательство. Потому что у людей не просто был свободный выбор между несколькими вариантами (без версий, вендоринг, с версиями), но ещё и за много лет сформировавшаяся привычка жить без версий. Если в этой ситуации все дружно переходят на версионирование - это очень громкое и вполне однозначное заявление, как по мне.
Но в результате мы получаем Легаси, то есть откладываем последствия и накапливаем ошибки
По-моему общий консенсус в том, что лучше так, чем получать внезапные отличия в поведении просто из-за пересборки старой версии на CI через неделю после предыдущей, либо вообще сломанную сборку. Недостатки есть у всех подходов, но подход позволяющий обеспечить повторяемость сборки определённо выигрывает.
Так пакеты не всегда имели последнее состояние и не обновлялись сами. Например при билде
Если не учитывать использование локального кеша - то всегда. Локально у разработчиков кеш обычно присутствовал, но вот на CI - наоборот. А поскольку сборка на CI обычно важнее - именно её результат релизится - то вполне корректно считать это version less, разве нет?
Мне кажется, не доказывает что "лучше". Для больших компаний более применимо скорее
На версионирование перешли абсолютно все, не только большие компании, но и индивидуальные разработчики опенсорса, которых никто не принуждал. Так что, как по мне, это вполне доказывает.
На Go все писали без поддержки версий пакетов примерно 9 лет (до 2018). В целом, как ни странно, это было не так страшно, как выглядит на первый взгляд. Изредка использовали вендоринг, но большинство проектов и библиотек нормально жило без управления версиями - достаточно поддерживать стабильную работу в ветке master и избегать (по возможности) несовместимых изменений. Это доказывает, что без версий - жить можно. Но как только в 2018 появилась встроенная поддержка версионирования - все тут же начали её использовать. Это доказывает, что с версиями - жить лучше. ;-)
А это уже культура разработки, которой может не быть, человеческий фактор, не проставил, или проставил не то, не та версия инкрементнулась.
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
В этом плане календарное версионирование решает проблему.
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
После выпуска новой мажорной версии библиотеки предыдущая ветвь развиваться не будет.
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
В такой ситуации разработчик вынужден переходить, даже если нет в этом необходимости, либо копить техдолг.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.
А если уровень сервиса локального решения не будет отличаться от иностранного - как будто все только выиграют и пострадавших не будет.
К сожалению, уровень сервиса решения, которое продвигается не рыночными методами а давлением государства и зарабатывает не на пользователях а из бюджета - всегда будет на порядок хуже "иностранных" (а точнее честно выигравших на рынке, вне зависимости от страны происхождения). Просто потому, что владельцы этого локального решения никак не зависят от удовлетворённости пользователей.
Для начала - не нужно поддерживать сомнительные инициативы. Даже частично или косвенно (что вполне себе прозвучало в Вашем предыдущем комментарии).
Нужно ли вообще защищать детей от информации - вопрос на который нет однозначного ответа (и нет никаких адекватных научных исследований доказывающих явную пользу или вред такой защиты). В таких ситуациях самое адекватное решение - оставить этот вопрос на ответственности родителей.
Распространение ограничения информации с детей на вообще всё население без возможности отказаться - ну очевидно же, что тут дело не в том, кто достаточно взрослый и ответственный, а кто ещё ребёнок.
Власть могла честно заявить населению "вы - быдло, которое должно молча делать что сказано и не пытаться думать самостоятельно и ставить наши распоряжения под сомнение, поэтому мы ограничиваем вам доступ к любой информации не соответствующей текущей политике". Но они вместо этого сказали "мы это делаем для защиты ваших детей от педофилов и суицидов". Зачем нужно это наглое враньё? А вот как раз затем, чтобы такие как Вы начали сомневаться и частично соглашаться с тем, что что-то делать надо, ведь бедные дети совершенно беззащитны, может не совсем таким образом, но ведь что-то надо же делать… и на этом месте любой протест тупо тонет в сомнениях и колебаниях.
Роль государства - выделить человека, который сможет выработать решение на некоторый вопрос, которому должны будут следовать остальные граждане. Просто потому, что В МАССЕ СВОЕЙ граждане не разбираются практически ни в чём.
С таким подходом государство будет регулировать вообще всё, что ему захочется - хотя это совершенно тупое оправдание для вмешательства. Государство - это не абстракция заботящаяся о населении, а вполне конкретные люди, действующие в первую очередь в своих личных интересах. Более того, полно очевидных примеров, когда "государство" назначает вырабатывать решения людей, у которых даже нет профильного образования и которые разбираются в заданном вопросе не больше, чем все остальные - просто потому, что государству не нужен качественный, правильный и работающий на пользу населению ответ на этот вопрос, ему нужен вполне конкретный ответ соответствующий текущей политике/интересам конкретной властной группировки. Не стоит верить всему, что Вам в школе рассказали. Да, где-то в идеальном мире может или даже должно быть так - но мы живём не в нём.
Вмешательство государства оправдано там, где ущерб для всего социума от невмешательства будет больше, чем ущерб от вмешательства. Хорошие примеры - наличие полиции и ПДД, потому что без них всё было бы намного хуже, даже с учётом того, насколько паршиво и избирательно они работают. Защита детей от информации в инете явно в эту категорию не попадает, не говоря уже о распространении этой "защиты" на взрослых.
Если считать всех взрослых несамостоятельными незрелыми идиотами нуждающимися в опёке, то возникает вопрос: а кто их опекает тогда? Такие же нуждающиеся в опёке "взрослые"? Зрелость мышления что, наступает в момент избрания в депутаты или получения должности чиновника? Простите, но Вам просто насрали в голову на школьной скамье, вот и всё.
Да, несколько раз заказчику "приходил аппетит во время еды", который трансформировался в допсоглашения с допТЗ.
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.
Ну, не исчезли, но да, их как-то совсем мало стало. Сейчас зашёл на агрегатор, и там для PCIe звуковух всего 5 вариантов: $60, $150, $250, $1000 и $1800. К профессиональным, надо полагать, относятся последние две.
Тесты проверяют на наличие любых изменений - а в новой версии изменения есть по определению, так что падение части тестов это норма. На совместимость должны проверять совершенно отдельные тесты, заточенные под это специально - что потребует, для начала, определить само понятие "совместимость" для конкретного продукта, а потом ещё и научиться его надёжно тестировать. На данный момент такого типа тесты если и встречаются, то это большая редкость.
Обычно "совместимость" контролируется либо формальными инструментами (которые проверяют только техническую совместимость API библиотеки или .proto-файла но не семантику/поведение этого API) либо вообще вручную (напр. для REST/OpenAPI мне такие линтеры как для proto пока не встречались). Тесты на семантику API написанные именно с целью контроля совместимости попадались редко и не были выделены в отдельную группу тестов совместимости, а были размазаны среди прочих (т.е. было крайне сложно понять что тестируется в этом плане, а что нет).
В золотые кабели со стрелочками я лично не верю, но вот что касается "остальные никогда не услышат" - это сильно зависит как от того, на каких колонках/наушниках слушать, так и от собственно слуха. Если слуха нет либо колонки/наушники относительно дешёвые - разницу действительно услышать не получится, разве что чисто психологически она там померещится. Но если слух нормальный и колонки/наушники достаточно крутые, то разницу между встроенным в материнку звуком и отдельной звуковой картой услышать достаточно легко (особенно если слушать не mp3, а любой lossless формат).
Больно, да. Но все гошники дофига лет с этим жили, и, в целом, были довольны своим ЯП. Ну т.е. больно, но не так чтобы очень. Где это было неприемлемо - вендорили.
Честно, не знаю таких примеров. Есть устаревшие, не поддерживаемые проекты, которые никто не обновлял - это да. А вот актуальные, поддерживаемые, и продолжающие жить в GOPATH без версий - я не сталкивался. Наверное, пару исключений найдётся, если специально искать, но на фоне общего количества проектов на го - это погрешность, а не статистика.
Почему не доказывает? Как по мне - это идеальное доказательство. Потому что у людей не просто был свободный выбор между несколькими вариантами (без версий, вендоринг, с версиями), но ещё и за много лет сформировавшаяся привычка жить без версий. Если в этой ситуации все дружно переходят на версионирование - это очень громкое и вполне однозначное заявление, как по мне.
По-моему общий консенсус в том, что лучше так, чем получать внезапные отличия в поведении просто из-за пересборки старой версии на CI через неделю после предыдущей, либо вообще сломанную сборку. Недостатки есть у всех подходов, но подход позволяющий обеспечить повторяемость сборки определённо выигрывает.
Если не учитывать использование локального кеша - то всегда. Локально у разработчиков кеш обычно присутствовал, но вот на CI - наоборот. А поскольку сборка на CI обычно важнее - именно её результат релизится - то вполне корректно считать это version less, разве нет?
На версионирование перешли абсолютно все, не только большие компании, но и индивидуальные разработчики опенсорса, которых никто не принуждал. Так что, как по мне, это вполне доказывает.
На Go все писали без поддержки версий пакетов примерно 9 лет (до 2018). В целом, как ни странно, это было не так страшно, как выглядит на первый взгляд. Изредка использовали вендоринг, но большинство проектов и библиотек нормально жило без управления версиями - достаточно поддерживать стабильную работу в ветке master и избегать (по возможности) несовместимых изменений. Это доказывает, что без версий - жить можно. Но как только в 2018 появилась встроенная поддержка версионирования - все тут же начали её использовать. Это доказывает, что с версиями - жить лучше. ;-)
Тема тестовых так и не раскрыта! Очевидно, сегодня просить такие тестовые смысла мало. Чем будем их заменять?
Это решаемо. Например, утилита https://git-cliff.org/ позволяет вручную корректировать такие "плохие" описания коммитов. В ней это сделано для генерации ChangeLog из коммитов, но она и SemVer отлично вычисляет (и её удобно использовать для определения версии на CI).
И CalVer и EvoVer - это просто альтернативные/красивые способы записи BuildID. Никакой проблемы помимо увеличения номера версии они не решают.
Вполне свободный: обновиться сейчас или позднее, отказаться от обновления, перейти на другую библиотеку…
Зависит от библиотеки, некоторые продолжают поддерживать багфиксами предыдущий мажорный релиз ещё какое-то время. Особенно если по объективным причинам многие пользователи не хотят обновляться на последний мажор.
Отказ от перехода на новый мажор - это не всегда техдолг.
Но в общем и целом - всё это незначительные мелочи. Важно то, что SemVer даёт ключевую информацию необходимую для принятия таких решений, а другие схемы - не дают.
Не совсем так. SemVer оперирует понятием "совместимое изменение". И это ключевой фактор: чтобы определить является ли изменение совместимым нужно иметь возможность как-то эту совместимость оценивать. Если продукт это библиотека, то способ оценить совместимость очевиден: по API. Но если продукт это CLI/GUI приложение, то понятие совместимость становится крайне туманным. Например для CLI можно считать совместимостью формат аргументов/флагов, но является ли совместимым изменением незначительное отличие в формате выводимых данных - уже не так очевидно.
Ещё один ключевой момент SemVer, который упустил автор статьи - задача SemVer коммуницировать ключевую информацию чтобы пользователь мог определиться нужно ли ему (полезность) и когда лучше (сложность) обновляться. Это полезно только в ситуации, когда время обновления выбирается пользователем. Что, очевидно, не так для микросервисов и для веб-фронта - и то и другое обновляется централизованно компанией, а не вразнобой пользователями.
При отсутствии любого из этих двух факторов пропадает смысл использовать SemVer.
SemVer прекрасно рассчитывается автоматически на базе префиксов коммитов (feat!:, feat:, fix:, etc.).
Это совсем не так просто. Потому что дальше понадобится обмен данными между разными юзерами (те же скачанные в браузере файлы). А потом и между разными приложениями (ссылку из телеги открыть в браузере, ссылку из браузера в zoom, etc.). Доступ к буферу обмена. Обеспечить визуальное отличие этих двух браузеров, чтобы понимать в каком сейчас работаешь. В общем, я соглашусь с тем, что в Linux есть все или практически все необходимые механизмы, но активировать их достаточно сложно и делать это нужно ручками - что для среднего десктопа равно отсутствию этой фичи.
Сам я этим пользуюсь, в т.ч. и для ограничения доступа AI-агента исключительно кодом рабочих проектов, но на сегодня это скорее исключение, чем норма. И, кстати, рекомендую для таких целей присмотреться к firejail - эта утилита сильно упрощает изоляцию разных приложений, избавляя от необходимости заводить кучу отдельных юзеров, и многое даже работает из коробки.
В целом верно, за исключением пассажа про "информационное сжатие кода". AI-агент выполняющийся на устройстве пользователя защищён ровно так же, как и все остальные локальные приложения. Ключевое отличие - крайне сложно контролировать какие именно данные пользователя он считает и отправит в интернет. Что с отправленными данными будет происходить дальше - ровно так же невозможно узнать, как и в отношении любых других данных отправленных в интернет любыми другими локальными приложениями.
По большому счёту, все десктопные ОС (исключая разве что малоизвестные вроде Qubes OS) совершенно не защищены от атак типа "любое локальное приложение может считать и отправить в интернет любые данные текущего пользователя". Есть попытки защитить отдельные приложения (полагаю, Signal, KeePass, etc.) на уровне ОС от, например, автоматических скриншотов, но это реально капля в море.
Просто если в отношении других локальных приложений доверие держится на уровне банальной надежды, что приложение не будет делать того, чего от него не ожидает пользователь (например читать не относящиеся к этому приложению файлы и отправлять их в интернет), то в отношении ИИ-агентов такой надежды изначально нет, потому что от них как раз ожидается что они сами найдут любую полезную для них информацию и обработают как посчитают нужным, без особых/явных ограничений.
К сожалению, уровень сервиса решения, которое продвигается не рыночными методами а давлением государства и зарабатывает не на пользователях а из бюджета - всегда будет на порядок хуже "иностранных" (а точнее честно выигравших на рынке, вне зависимости от страны происхождения). Просто потому, что владельцы этого локального решения никак не зависят от удовлетворённости пользователей.
Для начала - не нужно поддерживать сомнительные инициативы. Даже частично или косвенно (что вполне себе прозвучало в Вашем предыдущем комментарии).
Нужно ли вообще защищать детей от информации - вопрос на который нет однозначного ответа (и нет никаких адекватных научных исследований доказывающих явную пользу или вред такой защиты). В таких ситуациях самое адекватное решение - оставить этот вопрос на ответственности родителей.
Распространение ограничения информации с детей на вообще всё население без возможности отказаться - ну очевидно же, что тут дело не в том, кто достаточно взрослый и ответственный, а кто ещё ребёнок.
Власть могла честно заявить населению "вы - быдло, которое должно молча делать что сказано и не пытаться думать самостоятельно и ставить наши распоряжения под сомнение, поэтому мы ограничиваем вам доступ к любой информации не соответствующей текущей политике". Но они вместо этого сказали "мы это делаем для защиты ваших детей от педофилов и суицидов". Зачем нужно это наглое враньё? А вот как раз затем, чтобы такие как Вы начали сомневаться и частично соглашаться с тем, что что-то делать надо, ведь бедные дети совершенно беззащитны, может не совсем таким образом, но ведь что-то надо же делать… и на этом месте любой протест тупо тонет в сомнениях и колебаниях.
С таким подходом государство будет регулировать вообще всё, что ему захочется - хотя это совершенно тупое оправдание для вмешательства. Государство - это не абстракция заботящаяся о населении, а вполне конкретные люди, действующие в первую очередь в своих личных интересах. Более того, полно очевидных примеров, когда "государство" назначает вырабатывать решения людей, у которых даже нет профильного образования и которые разбираются в заданном вопросе не больше, чем все остальные - просто потому, что государству не нужен качественный, правильный и работающий на пользу населению ответ на этот вопрос, ему нужен вполне конкретный ответ соответствующий текущей политике/интересам конкретной властной группировки. Не стоит верить всему, что Вам в школе рассказали. Да, где-то в идеальном мире может или даже должно быть так - но мы живём не в нём.
Вмешательство государства оправдано там, где ущерб для всего социума от невмешательства будет больше, чем ущерб от вмешательства. Хорошие примеры - наличие полиции и ПДД, потому что без них всё было бы намного хуже, даже с учётом того, насколько паршиво и избирательно они работают. Защита детей от информации в инете явно в эту категорию не попадает, не говоря уже о распространении этой "защиты" на взрослых.
Если считать всех взрослых несамостоятельными незрелыми идиотами нуждающимися в опёке, то возникает вопрос: а кто их опекает тогда? Такие же нуждающиеся в опёке "взрослые"? Зрелость мышления что, наступает в момент избрания в депутаты или получения должности чиновника? Простите, но Вам просто насрали в голову на школьной скамье, вот и всё.
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Я такого за последние 36 лет работы с кодом не видел ни разу, а Вы?
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.