Как происходит спецификация задач

Что проверяют

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

Как отвечать

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

• постановка: продакт или аналитик формулирует пользовательскую историю и критерии приёмки. Удобный формат «Дано, Когда, Тогда», его потом можно превратить в сценарии Reqnroll, преемника SpecFlow;
• рефайнмент: разработчики и тестировщик разбирают задачу до спринта, задают вопросы, отмечают риски. Задача готова к работе по Definition of Ready: понятны критерии, есть макеты, известны зависимости;
• техническая спецификация: для .NET-бэкенда это контракт API (DTO и схема OpenAPI из Swashbuckle или встроенного Microsoft.AspNetCore.OpenApi), изменения модели EF Core и миграции, коды ошибок, права и требования к производительности;
• декомпозиция и оценка: история режется на подзадачи, оценка в стори-поинтах или часах, неясное выносится в спайк;
• изменения: новые требования не дописываются молча в текущую задачу, а оформляются отдельной или идут через продакта с переоценкой.

Приведите пример своей задачи: что было в исходной постановке, какие вопросы вы задали и что поменялось после них. Если спецификаций в команде почти не было, так и скажите и расскажите, как добирали требования сами: созванивались с аналитиком, писали контракт первым и отдавали на согласование.

Где спотыкаются

Перечисляют Agile, Scrum и Jira вместо рассказа о том, как задача реально выглядела. Названия методологий ничего не говорят о вашем участии.

Описывают себя исполнителем, который ждёт полного ТЗ. От мидла и выше ждут, что вы сами найдёте дыры в постановке.

Забывают про нефункциональные требования и критерии приёмки. Без них нельзя сказать, закончена ли задача, и спор начинается уже на ревью.