Как происходит оценка требований
Что проверяют
Умеете ли вы взять требование от аналитика или бизнеса, найти в нём дыры до начала разработки и дать оценку, на которую можно опереться. Следом обычно спрашивают, что вы делаете, когда оценка не сошлась с фактом или требования поменялись посреди спринта.
Как отвечать
Опирайтесь на свой процесс и реальный пример из проекта. Каркас:
- понять задачу: какую проблему бизнеса решаем, кто пользователь, что считать готовым. Если критериев приёмки нет, первое действие это вопросы к аналитику;
- нефункциональные требования: их забывают чаще всего. Ожидаемая нагрузка в RPS, допустимая латентность, объём данных, доступность, аудит и безопасность. Эндпоинт на 10 запросов в минуту и на 5000 в секунду это разные задачи;
- влияние на систему: какие сервисы и контракты затронуты, нужны ли миграции базы, меняется ли API для других команд, сохраняется ли обратная совместимость;
- декомпозиция: разбить на куски, которые оцениваются отдельно, включая тесты, ревью, миграции и выкатку, а не только написание кода;
- оценка: в story points через planning poker или в днях, как принято в команде. При большой неопределённости берут короткий спайк, например день на прототип или изучение чужого API, и только потом оценивают;
- фиксация: договорённости записываются в задачу, чтобы изменение требований было видно и пересчитывалось явно.
Хорошо звучит пример с цифрами: где ваша оценка разошлась с фактом, почему и что вы поменяли в подходе. Если опыта оценки мало, скажите честно и опишите, как оценивали свои задачи и что поняли на ошибках.
Тот же вопрос полезно задать работодателю: кто оценивает, есть ли в команде аналитик, как часто оценка превращается в дедлайн.
Где спотыкаются
Оценивают только время на код. Тесты, ревью, исправления после QA и выкатка легко удваивают срок.
Молча принимают размытое требование, а потом делают не то. Вопросы на старте обходятся дешевле переделки.
Называют точную цифру там, где много неизвестного. Сильнее выглядит диапазон с оговоркой, что его уточнит спайк.