Почему я не верю в SDD После перерыва на обстрелы продолжаем хот тейки про AI Прежде всего давайте определимся с терминами, потому что сколько я привожу этот тейк - столько выясняется что люди под SDD понимают что-то своё. Вот рандомная первая статья из гугла ibm.com/think/topics/spec-dr… которая определяет три уровня SDD: * Spec-first: пишем спеку - по ней имплементим, после этого спека не мейнтейнится. считается "входной точкой SDD" С этим подходом мне ок, кроме того что я подхода тут не вижу. Нужно ставить понятные требования? Мы это все знали и без волшебного SDD, нужны понятные Acceptance criteria - так же. Какой-то стандарт "постановки задач" - так тысячи их существовало и до SDD. То есть в целом это ребрендинг "нормальной постановки задач" в моей голове. Но даже тут есть целая пачка проблем и нюансов (я больше всего работал со Spec-Kit и BMAD, поэтому если другие реализации SDD здесь имеют отличия то поправьте меня: 1. Глубокая декомпозиция. Самый-самый проблемный момент, или как я говорю "как за деревьями перестать видеть лес". Принудительная детальная декомпозиция (которая часто избыточна для современных мощных моделей) приводит к тому, что наши узлы системы обретают контракт слишком рано и любая обнаруженная ошибка на этапе реализации часто каскадно проростает в другие декомпозированные узлы-задачи, разрушая стройную идею SDD. Знаете что это напоминает? Waterfall. Если вы поднимете историю этой методологии, то обнаружите что кроме причины "бизнесу надо часто делать пивоты", еще одна причина была именно неспособность даже супер-крутых экспертов грамотно декомпозировать задачу на составляющие, так чтобы план не устаревал. 2. Ревью плана. Это проблема не только SDD, но и в целом - но именно из-за пункта 1 проявляется особенно жестко - либо ты ревьювишь кучу детальных шагов и держишь их в голове (ад и очень легко упустить детали на стыках) либо ревьювишь гига-план 3. Этап конституции в SpecKit (который считается фундаментальным) предполагает огромное словесное описание того, что должно быть Quality Gate и способность гигачад-инженера сразу определить все необходимое * Spec-anchored: спецификация становится живым документом, отражающим текущее состояние системы. Часто мы строим тулинг синхронизации код- спека Я помогал с парой проектов построенных на подобном принципе и ничего кроме поднятия брови он у меня не вызывает: 1. синхронизация спеки и кода является болью. Делаем это ИИ - получаем галлюцинации. Делам это руками - ощущается как гига-боль трекать "какие спеки изменить" 2. теряется один источник истины и тогда зачем это все? * Spec-as-source: спека остается актуальной на весь срок жизни преокта, в случае чего "перегенерируем по спеке" Вот здесь у меня полное недоумение и на основании опыта и на основании рассказов. Кодирование требований челоческим языком" несет в себе кучу проблем, которые исследованы десятки лет - именно поэтому хорошие спецификации всегда ближе были к математическому языку чем к нормальному. Идея транс(пи)ляции спеки в код приводит к аду, когда спецификации начинают пересекаться по зонам ответственности (условно спецификации обслуживают вертикальный слайс, что приводит к конфликту спецификаций на каком-то горизонтальном уровне) - отслеживать такие конфликты даже c LLM сложно, поэтому я видел не раз уже как на проекте с таким подходом нарастают конфликтующие спецификации (как и в любом другом подходе - просто здесь это критично). Видел как люди пытаются избегать этого создавая горизонтальные спецификации (спека-на-слой или даже спека-на-модуль), но они начинают страдать ровно от того же с чего я начал твит - с потери "леса" (бизнес ценность лежит в вертикальных слайсах) за "деревьями" (горизонтальными слайсами архитектуры) Резюмируя: в разрезе "хайпануть что надо нормально писать требования" SDD наверное хороша. Как методология на длинное дистанции - я вижу больше тормозящих факторов чем позитивных И еще один критерий для меня "что что-то здесь не так": когда у каждой команды "свое SDD". Здесь уже улыбнутся сторонники Agile с историей "у нас свой аджайл-скрам-и-т.д." - если так происходит, то стоит задуматься почему приходится отклоняться от "буквы". Конечно же не существует "one-size-fits-it-all" подхода, но рабочего "чистого" SDD уровня выше чем "spec-first" (который я, повторюсь, и SDD-то считать отказываюсь) где-то кроме первых 6 месяцев greenfield-проекта я не видел Лайк-шер, если стоит продолжать свои мысли :)