Spec Projector — сервис по разработке технического задания на программные продукты

О том, как разработать техническое задание для вашего ИТ-продукта, навести порядок в процессах разработки и автоматически создавать описание задач для программистов.

7070

Вы для чего-то перепридумали Gherkin и BDD. Но такие спеки это всегда overhead и описание функциональности можно донести в гораздо более в удобном и понятном виде.

По поводу схем, их главное назначение - это дополнительный контекст или новое представление требований для разработчика. Не нужно тупо следовать всем стандартам UML (для описания бизнес-процессов лучше смотрите в BPMN) просто чтобы было.

Ну а по поводу "разработчик не хочет погружаться в контекст" - жаль ваших разработчиков. Это же просто конвеер получается, менеджеру тогда можно сразу условный UML2Code использовать.

7

Плюсую
Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании

Техническое решение без понимания контекста, и сделанное строго по заданию,  вероятнее всего будет более низкого качества, так как оно может не учитывать интересы бизнеса и продукта, или вовсе оказаться неправильным.

2

Спасибо за развернутый отзыв. Как раз таки следующим этапом мы хотели внедрить описание сценариев на Gherkin для фичей с последующим экспортом их в GIT проекта.

Менеджеру не нужно ничего комиттить, он просто работает в сервисе. И в нем же видит результаты прохода тестов и покрытия его бизнес требований в коде.

По поводу "разработчик не хочет погружаться в контекст" не вижу тут ничего плохого например для бекенд программиста, которому нужно просто реализовать API. Если задача описана подробно, тогда просто сделай. Лучше сделать нормальное описание, чем потом утонуть в уточнениях и "митинагах".

1

Дополню сам себя: при это Gherkin выгодно использовать, если вы покрываете весь код автотестами. Но в нем описывается бизнес-логика приложения, у вас же я вижу требования, в том числе, к интерфейсу.