Одно из важных отличий разработчика от LLM - он сохраняет опыт взаимодействия и работы над другими задачами. Поэтому все хотят опытных разработчиков - а лучше с релевантным опытом из бизнес-отрасли. А LLM - пока к сожалению опыт не накапливает и не рефлексирует...
Да, все так. Поэтому для эффективного встраивания LLM в процесс разработки нужно еще больше внимания уделять этому процессу, и в частности сбору рабочих продуктов генерируемых в процессе.
Это самое раздувание спек о котором вы говорите отчасти для того и нужно: спецификации со статусом "outdated" или "superseded" говорят о том, что было (но прошло, о-о-о), т.е. достраивают контекст.
Скорее всего в ближайшее время появятся и новые подходы здесь, будем следить
Разница заключается в том, что документы BA/SA не предназначены для генерации кода по ним. Они интерпретируются разработчиком, который имеет в голове плюс-минус тот же контекст. А LLM - нет.
Вы знаете как работает какая-нибудь цессия или своп? Как правильно перемещать товарные остатки с локального склада на региональный? Много разработчиков это знают? Мне кажется, что у LLM как раз больше контекста чем у разработчиков, которые пишут по спекам которые им дали.
Поэтому если я им принесу ворох того, что openspec наделало в процессе fast-forward - они покрутят пальцем у виска, и скажут что им такое читать - времени нет. Значит придется вычитывать мне (инициатива - сношает инициатора!).
Так у вас и с людьми же процесс не так построен — по fast forward "человеческие" спецификации тоже не пролетают. Аналитики тоже делают ревью, согласование и т.д. своих спецификаций прежде чем нести их в разработку. Но вы почему-то этого не делаете, а ждете какой-то магии.
Соответственно, после нескольких попыток - я пытаюсь понять, нафига - а главное, зачем нам SDD при живых разработчиках?!
У меня скорее вопрос, зачем вообще нужны кодеры если можно аналогичный процесс построить на spec-driven/openspec/plan-act? Быстрее, дешевле, не нужна большая команда и т.д.
Но есть и симметричный ответ — без содержательного понимания программирования далеко не факт, что c LLM получится что-то хорошее. И совершенно точно нельзя будет оценить насколько результат хороший или нет.
беда всех писателей спецификаций, требований и технических заданий заключается в том, что они предполагают (явно или неявно), что решение задачи уже известно ДО НАЧАЛА РАБОТЫ, и надо только задать правильным людям правильный вопрос чтобы это знание извлечь.
Нет конечно, это беда тех, кто говорит "дайте четкое ТЗ, без него мы работать не будем", т.е. по опыту как раз программистов и сисадминов уровня middle-минус, либо менеджеров или вообще нетехнических людей типа юристов или закупщиков.
Не понимаю. Вы только что сказали, что это наша главная задача. Сейчас говорите, что ответов не вытянуть. Не можете определиться, целенаправленно вводите в заблуждение, или просто не знаете предмет?
И соответственно - наша главная задача - это отвернуться от стены, найти нужных людей хранящих внутри истину, и пряником ли, верно ли составленным опросником, или под пыткой - вытянуть из них правильные ответы.
А какой артефакт получится в итоге? Как его назвать? Не "спецификация", случайно?
TDD это не проектирование испытательного стенда, а проектирование поведения системы. Возможно более корректно будет сказать не TDD, а BDD, чтобы более явным был переход между двумя фазами "проектирование поведения" и "разработка под эти спеки".
Свойство testability не нужно само по себе, оно нужно исключительно для того чтобы можно было выполнять проверки что написано то что нужно, т.е. опять же указывает на первичность спек.
Что до пользы spec-driven development — очень просто. У вас получается код:
с хорошей подробной документацией
с подробными тестами
протестированный
без неучтенной функциональности (такое по-моему в принципе не было возможно до SDD)
И это все еще за те же (или чуть меньшие) сроки разработки и силами одного человека, а не команды.
По моему одни плюсы, если смотреть на это не глазами программиста из финтеха пишущего по спекам, а более широко.
Мне кажется, становится гораздо понятнее, если попробовать разобрать по ключевым альфам одну фичу с доски. - Кому она нужна? (и выясняется, что разным людям и возможно это будут разные фичи, хоть и похожие) - В чем выгода от реализации? - Как фича будет выглядеть после реализации? (сценарий, набор требований и т.д.) - Какое состояние реализации сейчас? (концепт -> архитектура -> код -> релиз прошедший проверки -> релиз выведенный в прод) - Какие шаги реализации этой фичи? - Когда ее будут делать с учетом разбиения на шаги (например, бэклог->запланирована->в процессе->сделана) - Кто ее будет делать?
Аналогично для более крупных элементов.
Интуитивно это всем понятно, особенно если процесс работы в компании поставлен хорошо, но не всегда это так
Так вы здесь внутренние системные решения почему-то в требования вписали. Вы как архитектор при проектировании системы вероятно реализуете калькулятор как "компонент для вычислений" и "пользовательский интерфейс", но это ж ваши решения по реализации, это не требования к самому приложению.
"User story" и подобные продуктовые инкременты можно представить в виде ЧТЗ.
Есть ТЗ на систему в целом, и ЧТЗ на отдельные функции.
Проблема "продуктов" в том, что на момент разработки продукта либо функции мы сами далеко не всегда понимаем что именно мы хотим разработать, а поэтому мы не можем прописать требования. И проектирование сценариев и разработка часто идут одновременно со сбором требований.
По этой причине и суть ТЗ, кажется превращается из собственно задания на разработку в некий чеклист, который нужно так или иначе учесть при разработке.
Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование. Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.
Тоны учатся за полгода и дальше просто естественным образом начинают использоваться и пониматься, даже без специального интонирования. В плане произношения гораздо более сложны шипящие, которых штук 6 похожих друг на друга как две капли воды.
А в плане изучения самое большое отличие от западных языков - огромный объём домашней самостоятельной работы без которой язык не выучишь - писать и читать иероглифы и т.д. Какой-нибудь английский можно изучить чисто в процессе очных занятий с преподавателем/группой. С китайским такое невозможно.
Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).
Да, все так. Поэтому для эффективного встраивания LLM в процесс разработки нужно еще больше внимания уделять этому процессу, и в частности сбору рабочих продуктов генерируемых в процессе.
Это самое раздувание спек о котором вы говорите отчасти для того и нужно: спецификации со статусом "outdated" или "superseded" говорят о том, что было (но прошло, о-о-о), т.е. достраивают контекст.
Скорее всего в ближайшее время появятся и новые подходы здесь, будем следить
Вы знаете как работает какая-нибудь цессия или своп? Как правильно перемещать товарные остатки с локального склада на региональный? Много разработчиков это знают? Мне кажется, что у LLM как раз больше контекста чем у разработчиков, которые пишут по спекам которые им дали.
Так у вас и с людьми же процесс не так построен — по fast forward "человеческие" спецификации тоже не пролетают. Аналитики тоже делают ревью, согласование и т.д. своих спецификаций прежде чем нести их в разработку. Но вы почему-то этого не делаете, а ждете какой-то магии.
У меня скорее вопрос, зачем вообще нужны кодеры если можно аналогичный процесс построить на spec-driven/openspec/plan-act? Быстрее, дешевле, не нужна большая команда и т.д.
Но есть и симметричный ответ — без содержательного понимания программирования далеко не факт, что c LLM получится что-то хорошее. И совершенно точно нельзя будет оценить насколько результат хороший или нет.
Т.е. BA, SA и QA просто языком болтают и ничего не пишут?
Или в чем разница между их документами (которые эволюционируют со временем точно так же как и код), и "промежуточными планами и спецификациями" AI?
Они их честно сидят и пишут, а потом вычитывают, но с этим проблем вроде бы нет. В чем отличие в случае с AI? Есть ли оно вообще?
Теперь напишите 3 отличия этого подхода от Spec-Driven/Openspec.
А также как здесь разрешаются проблемы описанные тут: https://habr.com/ru/companies/X5Tech/articles/995466/comments/#comment_29519784 (первый коммент к посту)
Нет конечно, это беда тех, кто говорит "дайте четкое ТЗ, без него мы работать не будем", т.е. по опыту как раз программистов и сисадминов уровня middle-минус, либо менеджеров или вообще нетехнических людей типа юристов или закупщиков.
Где фиксируются ответы респондентов до начала работы и в процессе ее?
Где фиксируются все промежуточные решения?
Где фиксируется финальное решение?
Где описана архитектура?
Где описаны тесты?
Где описан сценарий демо (или проверки сдачи-приемки)?
Что из этого фиксируется в коде?
Как называются документ, в которых фиксируется все кроме кода?
Не понимаю. Вы только что сказали, что это наша главная задача. Сейчас говорите, что ответов не вытянуть. Не можете определиться, целенаправленно вводите в заблуждение, или просто не знаете предмет?
А какой артефакт получится в итоге? Как его назвать? Не "спецификация", случайно?
TDD это не проектирование испытательного стенда, а проектирование поведения системы. Возможно более корректно будет сказать не TDD, а BDD, чтобы более явным был переход между двумя фазами "проектирование поведения" и "разработка под эти спеки".
Свойство testability не нужно само по себе, оно нужно исключительно для того чтобы можно было выполнять проверки что написано то что нужно, т.е. опять же указывает на первичность спек.
Что до пользы spec-driven development — очень просто.
У вас получается код:
с хорошей подробной документацией
с подробными тестами
протестированный
без неучтенной функциональности (такое по-моему в принципе не было возможно до SDD)
И это все еще за те же (или чуть меньшие) сроки разработки и силами одного человека, а не команды.
По моему одни плюсы, если смотреть на это не глазами программиста из финтеха пишущего по спекам, а более широко.
В спеках мы описываем что хотим получить и в каком виде. Это примерно как TDD.
Попросить "сверь спеки с кодом и опиши функциональность, которая есть в коде, но которой нет в спеках"?
Поправить спеку (или попросить робота это сделать) и сказать "сверь спеки с кодом, точка правды в спеках" ?
Мне кажется, становится гораздо понятнее, если попробовать разобрать по ключевым альфам одну фичу с доски.
- Кому она нужна? (и выясняется, что разным людям и возможно это будут разные фичи, хоть и похожие)
- В чем выгода от реализации?
- Как фича будет выглядеть после реализации? (сценарий, набор требований и т.д.)
- Какое состояние реализации сейчас? (концепт -> архитектура -> код -> релиз прошедший проверки -> релиз выведенный в прод)
- Какие шаги реализации этой фичи?
- Когда ее будут делать с учетом разбиения на шаги (например, бэклог->запланирована->в процессе->сделана)
- Кто ее будет делать?
Аналогично для более крупных элементов.
Интуитивно это всем понятно, особенно если процесс работы в компании поставлен хорошо, но не всегда это так
Так вы здесь внутренние системные решения почему-то в требования вписали.
Вы как архитектор при проектировании системы вероятно реализуете калькулятор как "компонент для вычислений" и "пользовательский интерфейс", но это ж ваши решения по реализации, это не требования к самому приложению.
Спасибо за разбор, интересно!
Есть причины почему для дописывания не добавить пару классов в саму структуру Rails-приложения? Кажется это было бы проще чем писать обвязку на go? .
"User story" и подобные продуктовые инкременты можно представить в виде ЧТЗ.
Есть ТЗ на систему в целом, и ЧТЗ на отдельные функции.
Проблема "продуктов" в том, что на момент разработки продукта либо функции мы сами далеко не всегда понимаем что именно мы хотим разработать, а поэтому мы не можем прописать требования. И проектирование сценариев и разработка часто идут одновременно со сбором требований.
По этой причине и суть ТЗ, кажется превращается из собственно задания на разработку в некий чеклист, который нужно так или иначе учесть при разработке.
Почему просто не взять asciidoc?
Всем привет, я решил свой прогноз развернуть подробнее, выложил его сюда: http://timurb.ru/kb/kuda-idet-devops/
Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование.
Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.
Если я не ошибаюсь, это конспект доклада рассказанного на одном из недавних DevOpsConf.
Тоны учатся за полгода и дальше просто естественным образом начинают использоваться и пониматься, даже без специального интонирования. В плане произношения гораздо более сложны шипящие, которых штук 6 похожих друг на друга как две капли воды.
А в плане изучения самое большое отличие от западных языков - огромный объём домашней самостоятельной работы без которой язык не выучишь - писать и читать иероглифы и т.д. Какой-нибудь английский можно изучить чисто в процессе очных занятий с преподавателем/группой. С китайским такое невозможно.
Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).