Как происходит процесс передачи задачи от аналитика к разработчику и тестированию
Что проверяют
Понимаете ли вы, что передача задачи это не момент, когда тикет перетащили в другую колонку, а договорённость, после которой разработчик и тестировщик понимают одно и то же. Следом спрашивают, что делать, когда требования меняются посреди спринта, и кто принимает задачу в конце.
Как отвечать
Опишите процесс своей команды, опираясь на реальный опыт. Каркас:
- что лежит в задаче: пользовательская история или use case, критерии приёмки, удобнее в виде Given/When/Then, нефункциональные требования (время ответа, права доступа, объёмы). У системного аналитика ещё контракт API в OpenAPI, модель данных, диаграммы последовательности, маппинг полей между системами;
- Definition of Ready: условия, без которых задача не берётся в работу. Он защищает разработчика от сырой постановки, а аналитика от споров «мы же договаривались»;
- совместный разбор: груминг или встреча трёх ролей (аналитик, разработчик, тестировщик) до начала разработки. Тестировщик уже здесь спрашивает про граничные случаи, и многие дыры в требованиях закрываются до кода;
- во время разработки: аналитик на связи, ответы на вопросы фиксируются в задаче или в документе требований, а не в личной переписке. Изменение требований идёт через обновление спецификации с историей версий и оповещением команды;
- тестирование и приёмка: тест-кейсы строятся от критериев приёмки, несоответствия разбираются втроём. Принимает задачу аналитик или владелец продукта, иногда на демо.
Добавьте свои примеры: какой был шаблон задачи, сколько занимал груминг, какой случай показал пользу раннего подключения тестирования. Если вы видели процесс только с одной стороны, скажите об этом прямо и расскажите, что наблюдали со своей позиции и что бы улучшили.
Где спотыкаются
Описывают водопад: аналитик написал документ, отдал разработке и ушёл на следующую задачу. Интервьюер услышит, что после передачи вы из процесса выпадаете.
Не подключают тестирование до начала разработки, и тест-кейсы появляются, когда код уже написан и переделывать дорого.
Хранят уточнения в чате. Через месяц никто не может объяснить, почему сделано именно так, и спор выигрывает тот, кто лучше помнит.