Какой у вас опыт работы с методологиями разработки, например Scrum
Что проверяют
Работали ли вы в процессе на самом деле или знаете Scrum по названиям встреч. Интервьюеру важно понять, как вы впишетесь в команду: берёте ли задачи сами, говорите ли о блокерах, участвуете ли в оценке. Следом почти всегда спрашивают, что в вашем Scrum работало плохо и что вы с этим делали.
Как отвечать
Коротко опишите, как был устроен процесс у вас, и привяжите его к мобильной разработке. Каркас:
- рамка: длина спринта, состав команды, кто был Product Owner и был ли отдельный Scrum Master. По Scrum Guide 2020 зон ответственности три: Product Owner, Scrum Master и Developers;
- события: планирование, Daily Scrum, Sprint Review, ретроспектива. Скажите, что на них делали вы лично, а не как они называются;
- артефакты: Product Backlog, Sprint Backlog, инкремент и Definition of Done. Для Android в DoD обычно входят код-ревью, зелёные unit и UI-тесты в CI, сборка для QA через Firebase App Distribution;
- релизы: инкремент спринта не равен выкладке. Приложение уходит в Google Play поездом релизов с поэтапным раскатом (staged rollout) и проверкой магазина, и хорошо, если вы объясните, как это сочеталось со спринтами;
- ваш вклад: одна история, где вы что-то изменили. Например, предложили на ретро договориться о фиче-флагах, чтобы недоделанная функция не блокировала релиз.
Проценты роста продуктивности не называйте, если не можете показать, как их считали. Конкретные выпущенные фичи и пойманные до релиза проблемы звучат честнее.
Если Scrum не было, так и скажите: работали по Kanban или без формального процесса. Объясните, как планировали и как узнавали о проблемах, и покажите, что понимаете, чем Scrum отличается.
Где спотыкаются
Пересказывают Scrum Guide. Список ролей и событий интервьюер знает, ему нужен ваш опыт.
Путают Scrum с Agile вообще и называют Scrum любые ежедневные созвоны плюс доску в Jira.
Жалуются на процесс без выводов. Критика нормальна, если вы говорите, что предложили исправить и получилось ли.