(java || kotlin) && devOps
И последнее по SDD. Последнее, но важное.
SDD - это упор на актуальную спецификацию. Т.е. на аналитику.
Из 5-10 шагов по SDD workflow к чистой разработке относится один - /opsx:apply и /speckit.implement соответственно.
Достаточно ли этого?
Для простых фичей, но при этом имеющих свою аналитику - да.
А для более сложных есть superpowers) С TDD, параллельной разработкой в разных worktree, с расширенным код-ревью и отладкой
И в обоих случаях он отлично ложится в workflow, заменяя собой упомянутые выше шаги. И ложась т.об. в середину процесса.
Два нюанса:
1) brainstorming из superpowers в такой схеме становится ненужным и заменяется аналогами из SDD фреймворков
2) writing-plans (из superpowers) нужно оставить, так как это разная детализация.
В SDD таски написаны на уровне аналитика, а writing-plans пишет классы, импорты, тесты, команды запуска скриптов.
По сути из плана, созданного через superpowers, написать код может любой джун. И ему даже скучно будет)
Или самая дешевая модель.
Тогда может возникнуть другой вопрос - а нужен ли план, созданный SDD фреймворком?
В целом не обязателен. Но если он создается одной командой с другими артефактами - можно и оставить. Или подтюнить соответствующий скил.
Еще одно важное замечание. Я встречал случаи, когда superpowers тоже относят к SDD.
Нет, ну формально конечно спека по итогу brainstorming создается, как и план по итогу writing-plans.
Но это спека и план с деталями реализации, т.к. superpowers прям заточен под разработку.
Поэтому на мой взгляд по факту это не SDD фреймворк. Ну или как минимум - не SDD для команд, где есть явная роль аналитика.
И последний момент - нужно ли использовать два фреймворки - OpenSpec + superpowers - в связке?
А точнее когда нужно их использовать?
Ответ в общем очевиден - для достаточно больших фичей, когда в репозитории по итогу разработки фичи должна остаться спецификация. Либо это требование организации, либо решение команды.
#ai #ai_harness #dev_workflow
122 ·