Проработка легенды - как не проколоться? Часть 1 При проработке опыта многие вопросы возникают из-за плохого понимания стандартного рабочего процесса и ежедневных рутин, которые составляют 90 процентов всех событий на работе в принципе. Чтобы уверенней чувствовать себя при рассказе о своем опыте и перестать бояться разоблачения, предлагаю ознакомиться со стандартным флоу работы разработчика по Scrum процессу (инфа будет наиболее актуальна для Android). 1. Начало новой недели и нового спринта. Тебе повезло - ты работаешь удаленно, поэтому никуда ехать не нужно. Встаешь с кровати, приводишь себя в порядок, завтракаешь (лучше делать это до митинга, чтобы показать свое улыбчивое лицо менеджеру - так ты кажешься более вовлеченным в работу). 2. За 10 минут до планирования открываешь свой классный корпоративный макбук, заходишь в Slack/Telegram и проверяешь сообщения в чатах - нужен ли ты уже кому-то в начале недели (чаще всего нет, и это хорошо). Немного аутируешь в ожидании встречи, затем с чувством выполненного долга подключаешься в очередному планированию. 3. Ты подключился, поздоровался со всеми (кроме Васи - он опять опаздывает, наверняка выгорел и скоро уволится). Когда все собрались (а на встрече присутствует вся наша кросс-функциональная команда - менеджер, андроидеры, ios-еры, бэкендеры, тестировщики, дизайнер), твой менеджер шарит экран с вашей scrum доской и бэклогом с приоритезированными задачами. 4. Начинаем проходить по задачам бэклога (они уже оценены) и набираем таски, исходя из производительности команды. Обозначаем цель спринта (задачу, которая команда кровь из носу должна выполнить), желаем всем удачи и хорошей рабочей недели, отключаемся. 5. Списываешься с коллегами по Android - кто и какую задачу хочет взять (а кто какую вообще не хочет). Когда решили, кто и что возьмет - начинаем выполнять нашу таску. 6. Открываем тикет с задачей - обязательно прокликиваем все ссылки (figma, swagger), чтобы через пару дней внезапно не выяснилось, что к дизайну у тебя нет доступа, а ты уже успел зарепортить, как усердно верстаешь экраны. 7. Если вдруг чего-то нет - идешь к нужному человеку в личку. Нет ссылки на дизайн - стучишься к дизайнеру, на api - к бэкендеру, нет описания аналитики - к аналитику. 8. Все есть? Отлично. Создаем новую ветку от develop-a - в ней мы будем работать над нашей задачей. 9. Работаем. Да, уже можно. Возникают вопросы - спрашиваем в личке у тех, кто с большей вероятностью может знать ответ. Что-то непонятное происходит в коде? Смотрим по истории в git, кто там набезобразил и доебываемся до него. 10. Да, мы будем постоянно докапываться до людей - потому что ни одна задача не описана идеально, корнер кейсы не всегда обозначены, какой-то компонент в дизайн системе обязательно выглядит не так, как дизайнеру хочется и тд. 11. Каждый последующий день спринта для тебя будет начинаться с дэйли (daily) митинга - это встреча, которая чаще всего проходит утром и на которой каждый член команды рассказывает, чем он занимался вчера, чем планирует заниматься сегодня и есть ли у него какие-то блокеры (то, что блокирует работу - например, не готов дизайн). 12. Часто вы совершенно не в контексте того, чем занимаются другие люди - и это нормально. Просто умно киваете и ждете своей очереди. 13. Все рассказали, какие они молодцы, пожелали хорошего дня, отключились. 14. Опять работа. До конца недели это все наше флоу - работаем и ходим на дейлики. 15. Как только мы решили что закончили нашу задачу (нужно как минимум собрать проект и протестировать на базовых кейсах, что все работает), нам нужно запушить наши апдейты и открыть merge request (иногда называют pull request). 16. Как мы это делаем? Коммитим все изменения, пушим. Рекомендую сразу проверить на возможные конфликты и зафиксить их. Выполняем последовательность git команд - сначала fetch, затем - находясь на рабочей ветке, делаем rebase на develop. Если у вас есть конфликты - студия предложит их зафиксить в специальном интерфейсе. Затем коммитим изменения и пушим. 🦝 • Менторство