Относительно недавно ко мне обратились и попросили рассказать про то, как работается в команде. У меня было видео на эту тему, но я решил ответить на конкретные вопросы детальнее.

## Как проходила подготовка к спринтам?

Обычно подготовка представляет собой созвон с командой, тимлид, ПМ, аналитик и разработчики. На этом созвоне обговариваются предстоящие задачи, даётся оценка по времени, закладываются риски. Обычно это занимает от часа, всё зависит от количества задач.

## Что делают тестировщики?

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

## Как проходил код ревью?

Когда задача выполнена, отправляется MR/PR (Merge request / Pull reauest) тим лиду или другому разработчику, ответственному за ревью кода. Иногда можно попросить в личных сообщениях, чтобы данной задаче и данному МР уделили больше внимания, побыстрее посмотрели. Само ревью происходит обычно так, просматривается код, на очевидные ошибки: опечатки, неправильные названия переменных, плохая логика, дублирование кода. Чем опытнее разработчик, тем больше он может предложить вариантов решений той или иной задачи. Плюс смотрят на оптимальность кода.

## Перфоманс ревью?

Обычно проходит раз в полгода, но возможно если попросить, то могут устроить и по запросу. Обычно проходит 1 на 1 (one to one). Вы общаетесь с человеком, с HR или c тимлидом. У вас спрашивают как дела, как общение с коллегами, собирают о других коллегах обратную связь. Рассказывают, что коллеги говорят о тебе и как ты прогрессируешь в плане выполнения задач и обязанностей. Если есть успехи - хвалят, если нет - спрашивают в чём проблема и как могут помочь. Могут повысить зп и грейд. А могут и не повысить, тут надо проявлять активность.

## Как относишься к юнит тестам?

Положительно. Не пишу) Т.к. не хватает времени и не ставятся такие задачи от заказчика. К сожалению бизнес зачастую заинтересован, чтобы задачи делались быстро, а написание тестов это трата времени и денег.

## Как происходило общение?

Обычно в переписке, если надо уточнить или показать что-то, то лучше устроить созвон на 10-15 минут и обговорить устно.

## Приходилось ли ревьюить?

Приходилось, обычно это не так сложно, если ПР не большого размера. Но иногда требуется посмотреть чуть шире, узнать контекст задачи. Лучше не откладывать в долгий ящик ревью, т.к. ПРов может скопиться очень много.

## Как взаимодействовал с дизайнером / бэкендом / тестировщиками?

Обычно есть макет, по нему возникают вопросы, плюс можно предложить улучшение или упрощение (на коде).

Постоянно происходит общение и часто приходится взаимодействовать по конкретным задачам. Например какие поля должны приходить и уходить от и на бекенд. И т.д.

Обычно по поводу багов. Или то, что они не воспроизводятся. Можно задавать уточняющие вопросы.

Таски описываются в Jira.

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

Если баг, то описывают в чём он заключается и добавляют:

**сравнение ожидаемых результатов (ОР) и фактических результатов (ФР)**

Задачи оценивают по времени на грумминге или на дейли митинге. Обычно если ты уже делал похожую задачу, ты премерно представляешь сколько времени уйдет на ёё решение. Если ещё не решал, закладывается время на аналитику задачи, на решение и риски (обычно от 30%). В итоге получается, определенное количество часов. Можно заложить время на дев тестирование, когда ты проверяешь, работает ли код на демо стенде.

Обычно разработчики приходят уже на всё готовое. В каждой компании по разному.

Есть общий чат разрабов, чат проекта, чат тестировщиков и чат дизайна. Их может быть огромное количество.