Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Как то вы слишком фривольно манипулируете цифрами.
Если протестировать RAM disk, для i7-5820K @ 4GHz, G.Skill 2133 DDR4
Sequential Read: 7407.388 MB/s
Sequential Write: 11478.855 MB/s
Random Read 512KB: 7218.039 MB/s
Random Write 512KB: 11622.896 MB/s
Для Samsung 950 Pro 512 Gb
Sequential Read: 2599 MB/s
Sequential Write: 1530 MB/s
Random Read 512KB: 1216 MB/s
Random Write 512KB: 1513 MB/s
Разницу на один порядок между оперативной памятью и SSD видно.
по IOPS разница: ~554 373 IOPS против ~44 9000 по чтению примерно в 10 раз
и
~468 428 IOPS против ~13 516 по записи примерно в 30 раз.
Можно, конечно заморочиться с ECC и размером кеша для серверов, но еще в 10 раз мы не натянем ну никак.
При интенсивной записи, станет колом что IMDB что DiskDB на записи журанала. Но это граничные условия, можем их опустить.
А вы утверждаете о разнице на 4 порядка (10 тыс раз!!!) между RAM и SSD!
Как то не аккуратно :)
This model makes all programmatic locks unnecessary: cooperative multitasking ensures that there will be no concurrency around a resource, no race conditions, and no memory consistency issues
и
box.begin() Begin the transaction. Disable implicit yields until the transaction ends. Signal that writes to the write-ahead log will be deferred until the transaction ends. In effect the fiber which executes box.begin() is starting an “active multi-request transaction”, blocking all other fibers. box.commit() End the transaction, and make all its data-change operations permanent. box.rollback() The requests in a transaction must be sent to the server as a single block. It is not enough to enclose them between begin and commit or rollback. To ensure they are sent as a single block: put them in a function, or put them all on one line, or use a delimiter so that multi-line requests are handled together.
И судя по тому, что в документации написано, что все попадает в один исполнительный поток на сервере, ждет! асинхронного подтверждения на запись на диск, а в случае проблемы откатывает все, что было изменено после операции вызвашей проблему.
До полноценной RDMS ей как до границы раком.
Безусловно, много там интересных вещей и ребята проделали большую работу, но это по факту Key-Value массив «на стероидах» в памяти, с обвязкой для репликации и самовосстановления из сохранных на диске данных.
т.е по факту, как только латентность постоянной памяти, будет сопоставима с оперативной памятью, ваше решение перестанет быть «крутым».
если делать не на hdd а на ssd с pcie/NVMe то недостатки в виде «рандомное обращение к диску» перестануть быть весомым фактором.
судя по упоминаемому выше серверу супермикро.
Может у вас есть какие-то сравнительные тесты?
будучи профи, должны выцепить из заказчика все эти детали
Зубами, пытками, дубиной, сладкой вкусной сахарной ватой — да как угодно.
Но выцепить все детали.
Были интересные задачи:
система оценки кредитных рисков для банков. Ее приемка идет по тестовым сценария. подготовленным банком. и если банк накосячит — на выходе будет фигня. Это секретная информаци и я не могу никак ее выцепить.
Работа с госсистемами, которые имеют «гриф». Суровые люди тебе просто говорят — должно быть вот так. Хотя с точки зрения здравого смысла/ опыта это бред сумашедшего.
Нафига мне знать обороты Большой Компании и через кого идет работа с офшорами? движуха по счетам ?
Я вынужден доверять тому, что мне сказано Клиентом, если он отказывает мне в проверке предоставленных им данных. А что бы «не попасть» вынужден защищаться юридически.
Вы в больнице подписываете форму, на что у вас есть аллергия. Если вы солгали и вам ввели опасное вам вещество, вы можете умереть. Подписанная форма снимает ответственность с врача. Люди это понимают и говорят правду. А в ИТ — нифига. Зачем ?!
Вам пломбу поставили и предупредили не есть орешки? Вы начали щелкать грецкие орешки и отрывать пиво и зуб под удаление? Вы сам себе злой буратино. А в ИТ? А зачем ?!
Мы спецы, у нас дохрена опросников и чеклистов, как не накосячить, но я не могу заставить клиента их прочитать, потому что «5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.»
Я могу только в контрате написать «что не оговорено в ТЗ и критериях приемки, делается за отдельную плату».
И если мне Клиент солгал или не знал или не захотел сказать когда я его спрашивал, что вместо 10 человек запланированных, у него будет работать 100 — я с чистой совестью, выкачу ему счет за решение возникшей проблемы:)
Ваша маржа, нафиг никому не сдалась :) Это друга форма отношений.
Вы покупатете сервис, что вы будете с ним делать — это только ваша проблема.
Купили и хвастаетесь своему коту, или продаете через него аламазы — это только ваша проблема и заслуга.
Если вы получили услугу с отсрочкой платежа, вам фактически сделали «товарный кредит». Кредит стоит денег :) Хотя бы курсовые риски и инфляцию, которые будут заложены, на ваш платеж, который пойдет на оплату облака Гугл/Амазон/ и т.д. :) А еще добавят вам зарплату того парня, что будет спрашивать у вас когда заплатите.
А поскольку вы не показали серьезность намерений, то вам могут сделать «вот прямо сейчас» не заложив никаких точек расширения или роста и дальнейшие доработки вам будут стоить не 5 часов, а 10.
Если вы сделали по предоплате: вам могут сделать скидку просто потому, что вы показали серьезность ваших намерений к работе.
Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
Ну почему?
Просто пишутся маркеры: начало звонка, конце звонка. двумя записями.
Потом проходит обработка ETL и приведение в более удобоваримую аналитическую форму/кубики.
Именно что причем.
Есть куча проблем, которые следует согласовать с заказчиком, до того как…
Например:
политики безопастности. Например, он бится что украдут базы клиентов.
юридические политки. требует, что бы все разработчики были в штате.
бизнес-политики. никакого итеративного подхода, только хардкор! только за одну ночь и в одном контракте!
А если у клиента уже есть какие-то ИТ решения? Тогда ты должен под них «подстроиться», что бы было Клиенту удобно.
Например: у клиента инфраструктура Оракл, а ты ему предлагаешь решения на стеке Микрософт, потому что он тебе просто не сказал про Оракл.
Один аж пищат хочет облака, другие он них шарахаются.
Третьи хотят только OpenSource решения,
У Клиента есть свои представления, как он хочет развернуть инфраструктуру.
У него уже закуплено и развернуто оборудование со специфическими конфигами, а тебя просто не допускают до него.
Я у него «гость» и я не могу ломиться в «закрытые» двери.
Например:
В одном проекте предупредили клиента письменно:
Перед развертыванием решения или внесением изменений, мы вас извещаем. Вы делаете резервную копию (нам прав не дали), и после вашего подтверждения мы разворачиваем.
Клиент подтверждает: ОК.
Развернули решение. Через два месяца звонит и требует «ремонта по гарантии». Полезли разбираться. Оказалось, что Клиент поменял менее 24 часов назад конфигурацию решения, потеряв часть своих данных. Позвонили клиенту через минут 30 и известили. Сказали что бы срочно откатил из резевной копии потому что…
Клиент сказал: ОК. буду делать.
Через два дня звонок от пользователя — что за хрень ?! почему все сломано ?!
Проверили: клиент нифига не откатил.
Начали разбираться, оказалось что клиент просто не делал резервные копии… @#@$
Вот нафига был врать «парни все ок, у нас все есть»?
Вы не уловили сути:
Квалифицированный — будет сотрудничать, будет слушать что ему говорят, спрашивать что непонятно, докупит нужный сервис если нету. Например: Мы не умеем, сколько будет купить у вас или кого рекомендуете.
Не квалифицированный тупо забьет, на то что ему говорят пофиг платно или бесплатно. А когда получит граблями в лоб, еще и обижаться будет что ему бесплатно не исправляют и не заставили! прочитать руководтво по эксплуатации перед тем как 200 человек посадить на новую систему.
Вроде как очевидно.
Если сервер А упал, запросы должны на серевер Б. Сервер А обязан содержать данные, подтвержденные сервером Б (фактически двухфазный комит). Этот двухфазный комит стоит какие-то ресурсов.
В противном случае, если Сервер А подтвердил данные, а сервер Б еще не подтвердил их,
то после момента переключения Клиент будет пытаться оперировать данными, подтвержденными ТОЛЬКО сервером А о которых сервер Б еще не знает.
К сожалению, это проблема. Отсутсвие квалификации проявляется следующим образом:
Если вы внедряете такое решение извещаете Клиента:
Вам нужно сделать следующее, что бы не было проблем (к примеру):
Разработать политику резервирования и восстановления
Этапы внедрения решения настоятельно! рекомендуем следующие… потому-что…
У вас должны быть готовы справочные данные по следующим правилами потому-что
Квалифицированный клиент:
Ок парни. вот мы тут сваяли политику. гляньте? может чего рекомендуете
Ок парни. вот мы тут сваяли график внедрение. гляньте? может чего рекомендуете
Ок парни. вот мы тут справочные данные. гляньте? может чего обсудим
НЕ Квалифицированный клиент:
Фигня. у нас все есть.!
Не ваша проблема! не первый раз.
Да у нас 1С/ CRM / ERP. Выгрузим-загрузим. 5 минут делов. Не баитесь!
не говоря о том, что бы получить встречу с кем-то из других участников проекта клиента, огранизовать тестирование у себя и т.д.
Угадайте, в каком случае наступит #@&% когда придет время раскатывать на сервер?
И кому будут выносить мозг и как, когда у клиента сложится рабочая система?
Что есть ТЗ? Одна задача «Поменять надпись на кнопке» — это ТЗ?
Есть формализованное представление ТЗ. есть рекомендации к формулировке:
Атомарность требования.
Система должна формировать отчет Х. форма отчета см приложение № (правильно)
Система должна формировать отчет Y. форма отчета см приложение № (правильно)
Система должна формировать отчеты. (не правильно)
Проверямость требования.
Система должна обеспечить время формирования отчета не более чем за ### при нагрузке в ### запросов. (это правильно)
Система сохранять отчет. (это НЕ правильно)
Непротиворечивость требований.
Система должна работать на микропроцессорах с системой комманд MIPS под операционной системой Windows 10 Pro
Кто должен писать ТЗ, заказчик или исполнитель со слов заказчика?
Это СОГЛАШЕНИЕ двух сторон, которе после закрепляется юридически. значит требуется участие двух сторон.
Какие возможны критерии качества ТЗ, чтобы определить хорошее оно или плохое? И насколько эти критерии разнятся между заказчиком и исполнителем? Можно ли одним ТЗ удовлетворить обе стороны?
Есть формализованные трбования:
Юридические
технологические. см страндарты ISO
Кому предназначается ТЗ? Кто те люди (роли), кто должны его читать?
Читают все участники проекта — это ПУБЛИЧНЫЙ документ :)
Со стороны Подрядчика — согласно требуемых ролей в проекте (Hr, менеджеры, юристы, UI/UX спецы, архитекторы, разработчики для связанных задач, QA, развертывание, сопровождение ...)
Каков процесс изменения ТЗ? Ведь, если мы начали работу по уже написанному ТЗ, то любое его изменение вероятнее всего повлияет на оценку проекта. Почти всегда отклонение оценки будет не в пользу исполнителя (нужно больше усилий, времени, денег).
Стандартная процедура Change Management. Так и есть. каскадные изменения.
Не является ли ТЗ (как увесистый документ), чаще всего лишь, не совсем удачным способом описания юридической ответственности сторон? И по сути, обеспечивает процесс продажи и заключения сделки, а не исполнения проекта?
Нет. Не является. Если подрядчик идиот, то ему просто выстявят неустойку за неисполнение проекта, плюс упущенную прибыль :) Про репутацию лучше и не заикаться :)
Почему считается, что БИЗНЕС-аналитики должны писать ТЕХНИЧЕСКОЕ задание? Каков должен быть вклад бизнес-аналитика в ТЗ?
Это не являтся обязательным. Но если специфическая область (банки, таможня, здравохранение и т.д.) то владение терминологией значительно упрощает и ускоряет написание ТЗ, заодно устраняет явные косяки при его написании. Если стороны не владеют в полной мере нюансами предметной области, его могут отдать на резензирование третьей стороне на условиях NDA.
Может ли документация (user manual) на готовый проект, считаться его ТЗ? Насколько тесно связаны документация и ТЗ
Может ли йогурт считаться молоком? Мануал — это результат исполения ТЗ. При корректном процессе исполнения, ТЗ будет являться «оглавлением» мануала :)
Не могли бы Вы как-то отметить пункты, которые по Вашему мнению не соотносятся с реальным миром? может быть добавите свои сценарии из реального мира?
это не подколка, а просьба поделиться опытом :)
А за чей счет банкет? вы сделали «свою камеру», а потом вас попросили переделать.
Откуда бюджет на черновик и переделку? если Т&M — то риски на клиенте/инвесторе.
Кроме сервиса разработки, вы добавили сервисы. Вы все равно как-то «на бумажке» зафиксировали ожидания Клиента, под них сделали Решение.
Вот теперь все сошлось :) Видать пропустил что-то из описанного.
Спасибо :)
Предположу, что дурацкие «работаем без документации» проистекают из этих трех строчек:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
и попыткам следовать им буквально. На мелких проектах это прокатывает…
Называется научи дурака молиться, он и лоб расшибет.
Пытался выяснить, обсудить. Все упиралось в «написано!» Прямо как религиозная секта :)
Позволю себе предположить, что то, о чем вы говорите это «сервисный подход». В данном случае вы просто предоставли ресурсы под уже готовый проект. Все этапы планирования, аналитики — были на стороне Клиента. У вас же не спрашивали: Warehousing или нет. ETL или нет.
Вам просто сказали: будет Warehousing. Есть ресурсы? Сколько стоит? То, что вам позволили сначала сделать кубик А вместо кубика B — это не ваша заслуга, не ваши риски. Не взлетел кубик? ну и фиг с ним, все равно уплачено.
Если мое предположение корректно, то у вас был иной сценарий. А тут больше идет обсуждение в контекстве разработки и поставки Решения (Продукт под заказчика), причем он может его еще и не оплатить :)
Это не вопрос ТЗ. Это вопрос выбора метологии выполнения проекта.
То, что вы описали в «пессимистичном случае» — это классический недостаток водопада.
То, что вы описали в «оптимистичнос случае» — это классическое достоиство Agile методологий.
Что служит выбором между методологиями? тоже что и всегда: время-ресурсы-деньги.
Но ни одна из этих метологий не исключает ТЗ. Просто она перепихивает их на разных участниках. И всегда! присутсвует связка — Хотелка-Приемка. Даже в врырожденном случае «без ТЗ» экстремального программирования — у вас будут карточки, а за спиной стоять «носитель знания» который тут-же показывает «пальцем» как сделать или поправить (причем риски накосячить лежат полностью на «носителе знания»).
Считайте что РИСК + ТЗ =100% Увеличив одно, вы понимажете другое.
Как то вы слишком фривольно манипулируете цифрами.
Если протестировать RAM disk, для i7-5820K @ 4GHz, G.Skill 2133 DDR4
Для Samsung 950 Pro 512 Gb
Разницу на один порядок между оперативной памятью и SSD видно.
по IOPS разница: ~554 373 IOPS против ~44 9000 по чтению примерно в 10 раз
и
~468 428 IOPS против ~13 516 по записи примерно в 30 раз.
Можно, конечно заморочиться с ECC и размером кеша для серверов, но еще в 10 раз мы не натянем ну никак.
При интенсивной записи, станет колом что IMDB что DiskDB на записи журанала. Но это граничные условия, можем их опустить.
А вы утверждаете о разнице на 4 порядка (10 тыс раз!!!) между RAM и SSD!
Как то не аккуратно :)
По сути документации:
и
И судя по тому, что в документации написано, что все попадает в один исполнительный поток на сервере, ждет! асинхронного подтверждения на запись на диск, а в случае проблемы откатывает все, что было изменено после операции вызвашей проблему.
До полноценной RDMS ей как до границы раком.
Безусловно, много там интересных вещей и ребята проделали большую работу, но это по факту Key-Value массив «на стероидах» в памяти, с обвязкой для репликации и самовосстановления из сохранных на диске данных.
если делать не на hdd а на ssd с pcie/NVMe то недостатки в виде «рандомное обращение к диску» перестануть быть весомым фактором.
судя по упоминаемому выше серверу супермикро.
Может у вас есть какие-то сравнительные тесты?
Думаю грамотнтый так и скажет «вот Коробочка, вот ее цена». пользуйтесь :)
Были интересные задачи:
Я вынужден доверять тому, что мне сказано Клиентом, если он отказывает мне в проверке предоставленных им данных. А что бы «не попасть» вынужден защищаться юридически.
Вы в больнице подписываете форму, на что у вас есть аллергия. Если вы солгали и вам ввели опасное вам вещество, вы можете умереть. Подписанная форма снимает ответственность с врача. Люди это понимают и говорят правду. А в ИТ — нифига. Зачем ?!
Вам пломбу поставили и предупредили не есть орешки? Вы начали щелкать грецкие орешки и отрывать пиво и зуб под удаление? Вы сам себе злой буратино. А в ИТ? А зачем ?!
Мы спецы, у нас дохрена опросников и чеклистов, как не накосячить, но я не могу заставить клиента их прочитать, потому что «5 откликнувшихся компаний предлагают мне заполнить ТЗ (читать как — работать с нашей компанией большая честь, вам для работы следует: 1… 2… 3...) — опять в корзину.»
Я могу только в контрате написать «что не оговорено в ТЗ и критериях приемки, делается за отдельную плату».
И если мне Клиент солгал или не знал или не захотел сказать когда я его спрашивал, что вместо 10 человек запланированных, у него будет работать 100 — я с чистой совестью, выкачу ему счет за решение возникшей проблемы:)
Вы покупатете сервис, что вы будете с ним делать — это только ваша проблема.
Купили и хвастаетесь своему коту, или продаете через него аламазы — это только ваша проблема и заслуга.
Если вы получили услугу с отсрочкой платежа, вам фактически сделали «товарный кредит». Кредит стоит денег :) Хотя бы курсовые риски и инфляцию, которые будут заложены, на ваш платеж, который пойдет на оплату облака Гугл/Амазон/ и т.д. :) А еще добавят вам зарплату того парня, что будет спрашивать у вас когда заплатите.
А поскольку вы не показали серьезность намерений, то вам могут сделать «вот прямо сейчас» не заложив никаких точек расширения или роста и дальнейшие доработки вам будут стоить не 5 часов, а 10.
Если вы сделали по предоплате: вам могут сделать скидку просто потому, что вы показали серьезность ваших намерений к работе.
Вам могут просто предложить решение, которое будет, например, в облаке процентов на 10% меньше жрать ресурсов. доработка будет делать не 10 часов, а 5, потому что человек вам бесплатно заложил «точки расширения».
Сделал на последней версии движка БД, а не на том, который через год просто не будет поддерживаться и т.д.
Просто пишутся маркеры: начало звонка, конце звонка. двумя записями.
Потом проходит обработка ETL и приведение в более удобоваримую аналитическую форму/кубики.
Есть куча проблем, которые следует согласовать с заказчиком, до того как…
Например:
А если у клиента уже есть какие-то ИТ решения? Тогда ты должен под них «подстроиться», что бы было Клиенту удобно.
Например: у клиента инфраструктура Оракл, а ты ему предлагаешь решения на стеке Микрософт, потому что он тебе просто не сказал про Оракл.
Один аж пищат хочет облака, другие он них шарахаются.
Третьи хотят только OpenSource решения,
У Клиента есть свои представления, как он хочет развернуть инфраструктуру.
У него уже закуплено и развернуто оборудование со специфическими конфигами, а тебя просто не допускают до него.
Я у него «гость» и я не могу ломиться в «закрытые» двери.
Например:
В одном проекте предупредили клиента письменно:
Перед развертыванием решения или внесением изменений, мы вас извещаем. Вы делаете резервную копию (нам прав не дали), и после вашего подтверждения мы разворачиваем.
Клиент подтверждает: ОК.
Развернули решение. Через два месяца звонит и требует «ремонта по гарантии». Полезли разбираться. Оказалось, что Клиент поменял менее 24 часов назад конфигурацию решения, потеряв часть своих данных. Позвонили клиенту через минут 30 и известили. Сказали что бы срочно откатил из резевной копии потому что…
Клиент сказал: ОК. буду делать.
Через два дня звонок от пользователя — что за хрень ?! почему все сломано ?!
Проверили: клиент нифига не откатил.
Начали разбираться, оказалось что клиент просто не делал резервные копии… @#@$
Вот нафига был врать «парни все ок, у нас все есть»?
Квалифицированный — будет сотрудничать, будет слушать что ему говорят, спрашивать что непонятно, докупит нужный сервис если нету. Например: Мы не умеем, сколько будет купить у вас или кого рекомендуете.
Не квалифицированный тупо забьет, на то что ему говорят пофиг платно или бесплатно. А когда получит граблями в лоб, еще и обижаться будет что ему бесплатно не исправляют и не заставили! прочитать руководтво по эксплуатации перед тем как 200 человек посадить на новую систему.
Если сервер А упал, запросы должны на серевер Б. Сервер А обязан содержать данные, подтвержденные сервером Б (фактически двухфазный комит). Этот двухфазный комит стоит какие-то ресурсов.
В противном случае, если Сервер А подтвердил данные, а сервер Б еще не подтвердил их,
то после момента переключения Клиент будет пытаться оперировать данными, подтвержденными ТОЛЬКО сервером А о которых сервер Б еще не знает.
К сожалению, это проблема. Отсутсвие квалификации проявляется следующим образом:
Если вы внедряете такое решение извещаете Клиента:
Вам нужно сделать следующее, что бы не было проблем (к примеру):
Квалифицированный клиент:
НЕ Квалифицированный клиент:
не говоря о том, что бы получить встречу с кем-то из других участников проекта клиента, огранизовать тестирование у себя и т.д.
Угадайте, в каком случае наступит #@&% когда придет время раскатывать на сервер?
И кому будут выносить мозг и как, когда у клиента сложится рабочая система?
Есть формализованное представление ТЗ. есть рекомендации к формулировке:
Это СОГЛАШЕНИЕ двух сторон, которе после закрепляется юридически. значит требуется участие двух сторон.
Есть формализованные трбования:
Читают все участники проекта — это ПУБЛИЧНЫЙ документ :)
Со стороны Подрядчика — согласно требуемых ролей в проекте (Hr, менеджеры, юристы, UI/UX спецы, архитекторы, разработчики для связанных задач, QA, развертывание, сопровождение ...)
Стандартная процедура Change Management. Так и есть. каскадные изменения.
Нет. Не является. Если подрядчик идиот, то ему просто выстявят неустойку за неисполнение проекта, плюс упущенную прибыль :) Про репутацию лучше и не заикаться :)
Это не являтся обязательным. Но если специфическая область (банки, таможня, здравохранение и т.д.) то владение терминологией значительно упрощает и ускоряет написание ТЗ, заодно устраняет явные косяки при его написании. Если стороны не владеют в полной мере нюансами предметной области, его могут отдать на резензирование третьей стороне на условиях NDA.
Может ли йогурт считаться молоком? Мануал — это результат исполения ТЗ. При корректном процессе исполнения, ТЗ будет являться «оглавлением» мануала :)
это не подколка, а просьба поделиться опытом :)
Откуда бюджет на черновик и переделку? если Т&M — то риски на клиенте/инвесторе.
Вот теперь все сошлось :) Видать пропустил что-то из описанного.
Спасибо :)
и попыткам следовать им буквально. На мелких проектах это прокатывает…
Называется научи дурака молиться, он и лоб расшибет.
Пытался выяснить, обсудить. Все упиралось в «написано!» Прямо как религиозная секта :)
Вам просто сказали: будет Warehousing. Есть ресурсы? Сколько стоит? То, что вам позволили сначала сделать кубик А вместо кубика B — это не ваша заслуга, не ваши риски. Не взлетел кубик? ну и фиг с ним, все равно уплачено.
Если мое предположение корректно, то у вас был иной сценарий. А тут больше идет обсуждение в контекстве разработки и поставки Решения (Продукт под заказчика), причем он может его еще и не оплатить :)
То, что вы описали в «пессимистичном случае» — это классический недостаток водопада.
То, что вы описали в «оптимистичнос случае» — это классическое достоиство Agile методологий.
Что служит выбором между методологиями? тоже что и всегда: время-ресурсы-деньги.
Но ни одна из этих метологий не исключает ТЗ. Просто она перепихивает их на разных участниках. И всегда! присутсвует связка — Хотелка-Приемка. Даже в врырожденном случае «без ТЗ» экстремального программирования — у вас будут карточки, а за спиной стоять «носитель знания» который тут-же показывает «пальцем» как сделать или поправить (причем риски накосячить лежат полностью на «носителе знания»).
Считайте что РИСК + ТЗ =100% Увеличив одно, вы понимажете другое.