Многие скажут, что Agile предоставляет превосходный подход к разработке, и они будут правы. Но Agile идеально подходит, когда одна целая команда работает над 1 проектом с полным погружением и эмпатией, что в конечном итоге получается хорошо, но очень дорого, и в основном это актуально для продуктовых компаний: свой продукт, свои пользователи, один бэклог.
Процесс разработки это последовательная формализация требований. От очень высокоуровневых и неформальных, к конечному коду.
Вы предлагаете инструмент, который сдвигает границу ответственности разработчиков и авторов ТЗ (аналитиков). Для аналитиков потребуется писать более формальные требования, чем они привыкли. А для разработчиков на вход будут поступать менее формальные.
По сути мы снижаем когнитивную нагрузку на разрабов путем снижения абстракции для них на вход, но повышаем нагрузку на авторов ТЗ - аналитиков, продактов или кто там их будет делать.
Если посмотреть, что это значит для бизнеса, то это не инструмент улучшения производительности команды, а инструмент для увольнения дорогих разработчиков и замены их на более дешевых :) Которые не справляются на высоких уровнях абстракции, зато справятся на низких. Дальше им можно нарубить задачек, посадить в жесткие рамки и работать. См. микротаскинг имени Бугаенко. https://www.youtube.com/watch?v=VLaGrUsCbYo
Интересный подход, имеет право на жизнь сам по себе. Но если прямо попробовать внедрить в сложившийся коллектив, то неизбежны конфикты, т.к. сдвиг рамки ответственности их вызывает всегда.
PS Если реально получится инструмент для микротаскинга, то будет интересно попробовать.
Прям для совсем микротаскинга не могу не посоветовать свой pet-проект(бесплатный):
https://greentask.in/
Сделал уже лет 5 назад. Удобно быстро набросать ТЗ, и по ссылке дать.
Есть разные плюшки вроде комментов, доступов и тд.
Сорри если не совсем в тему, может кому пригодится
а инструмент для увольнения дорогих разработчиков и замены их на более дешевых
Но это будет работать только с действительно опытными ПМ, аналитиком, дизайнером и техлидом. И то им следовало бы вырабатывать требования совместно, а не последовательно.
PM не пишет API или модель, а только требования, спека создается самими разработчиками на этапе планирования реализации фичей, перед уходом в код - что полезно, например ревью лидером команды (как самому опытному). Ответственность не сдвигается, каждый занимается своим делом и все формализовано и актуально.
По опыту работы над проектами, мы сделали вывод, что достаточно одному сильному разработчику поставить проект на "рельсы", а все остальное успешно могу "реализовать подмастерья" если задачи нормально описаны.
Вы для чего-то перепридумали Gherkin и BDD. Но такие спеки это всегда overhead и описание функциональности можно донести в гораздо более в удобном и понятном виде.
По поводу схем, их главное назначение - это дополнительный контекст или новое представление требований для разработчика. Не нужно тупо следовать всем стандартам UML (для описания бизнес-процессов лучше смотрите в BPMN) просто чтобы было.
Ну а по поводу "разработчик не хочет погружаться в контекст" - жаль ваших разработчиков. Это же просто конвеер получается, менеджеру тогда можно сразу условный UML2Code использовать.
Плюсую
Разработчики могут получать задачи в разных проектах, и у них нет времени погружаться в проект — им нужно четко выполнить, что написано в задании
Техническое решение без понимания контекста, и сделанное строго по заданию, вероятнее всего будет более низкого качества, так как оно может не учитывать интересы бизнеса и продукта, или вовсе оказаться неправильным.
Спасибо за развернутый отзыв. Как раз таки следующим этапом мы хотели внедрить описание сценариев на Gherkin для фичей с последующим экспортом их в GIT проекта.
Менеджеру не нужно ничего комиттить, он просто работает в сервисе. И в нем же видит результаты прохода тестов и покрытия его бизнес требований в коде.
По поводу "разработчик не хочет погружаться в контекст" не вижу тут ничего плохого например для бекенд программиста, которому нужно просто реализовать API. Если задача описана подробно, тогда просто сделай. Лучше сделать нормальное описание, чем потом утонуть в уточнениях и "митинагах".