Работаете ли вы по Scrum

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

Как устроен процесс у вас и понимаете ли вы, что в мобильной разработке спринт не равен релизу. Отвечая, вы показываете не знание терминов, а то, как команда доводит задачу до пользователя, когда сборку проверяет внешняя сторона.

Как отвечать

Сначала общий каркас, коротко: спринт фиксированной длины, планирование, ежедневная синхронизация, обзор, ретроспектива; владелец продукта, скрам-мастер и разработчики; бэклог продукта, бэклог спринта и инкремент с общим пониманием готовности.

Дальше самое ценное, специфика мобильной команды:

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

Если классического Scrum у вас нет, скажите как есть: поток задач и релизы по расписанию раз в две или три недели.

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

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

Второе: путают скрам-мастера с руководителем, который раздаёт задачи. Задачи разработчики разбирают сами, а скрам-мастер отвечает за процесс и снятие препятствий.

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