И так, твой первый рабочий день начинается и... какие-то дейлики, планирование, спринты, сторипоинты/эстимейты, ретроспектива (wtf?)

Когда-то и я был в такой ситуации, поэтому сегодня расскажу, что тебе надо знать о рабочих процессах. и знать это желательно перед тем, как попасть на работу, особенно если ты крутишь и залетаешь на middle/senior-уровень)

Как только ты попадаешь на работу, тебя ожидают взаимодействия с командой: дейлики, планирования, демо/ретро, 1х1 встречи:

Дейлик — это ежедневный созвон, на котором ты рассказываешь, чем ты занимался вчера и чем ты собираешься заниматься сегодня. В порядке очереди или тимлид называет твоё имя (у кого как) и ты говоришь что-то типа: 

Потом ты будешь ещё N минут ждать, пока ответят другие, и потом вы разойдётесь работать работу. В это время в идеале слушать, о чём говорят твои коллеги, но если ты не хочешь, то можешь писать код или что-то изучать, но если ты новенький, то всё же послушай умных коллег, может что-то новое подчерпнёшь для себя. Если ты задаёшься вопросом а зачем это вообще надо, то по сути дейли — это способ менеджера/тимлида вообще узнать, а чем занимается команда. Никто ли не простаивает и тому подобное. Глобально коллегам зачастую без разницы, чем ты конкретно занимаешься, поэтому это нужно лишь тем, кто в целом менеджерит командой.

Планирование — это созвон, на котором вы планируете задачи. Обычно менеджер заранее подготавливает задачи, которые пойдут в этот спринт — некий временной промежуток, в который должны выполниться задачи (как правило 1-2 недели). Тебе показывают новые задачи и ты должен сказать, сколько времени ты будешь их делать. Но есть нюанс: почему-то не везде используются часы, где-то используются никому до конца не понятные сторипоинты или эстимейты. Я был на целой лекции, где люди пытались объяснять, че такое сторипоинт, но я так и не понял до конца, лол. Короче будем считать, что это некая абстрактная штука, которая как-то коррелирует с часами работы. Если у тебя на работе используют такое, то просто уточни их соотношение к часам и считай, исходя из этого оценивай задачи.

А как какать оценивать задачи? Очевидно, что когда ты видишь задачу первый раз, то ты не сможешь точно сказать, поэтому используй верхнюю планку. Например, задача сделать новый платёжный сервис (бэкенд часть). И ты такой:

На сколько ты оценишь задачу? на три дня? ответ неправильный: надо оценить на 4 дня, потому что могут быть какие-то подводные камни, из-за которых написание кода будет на один день, а два. так что всегда оценивай по верхней планке, не ошибёшься, в лучшем случае — отдохнёшь лишний день, в худшем — сдашь вовремя, хотя если совсем плохо пойдёт, то конечно сроки будут просраны и тебе надо будет оправдать это.

Упомяну ещё про покер планирование — это когда твою задачу оцениваешь не только ты, но и твои коллеги. Здесь главное оценивать так, как именно ты считаешь нужным, и не боятся аргументировать свою точку зрения коллегам.

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

Демо — это когда ты просто показываешь то, что сделал за спринт. То есть буквально показываешь свою работу и говоришь «вот тут у нас новая кнопка появилась, она делает вот это». Здесь тебе могут задавать вопросы, поэтому будь готов отвечать) Вопросы по типу «А вот если такой юзер-кейс рассмотреть, то что будет?»

Ретро повеселее — оно у каждого индивидуально. Кто-то разбирает ошибки текущего спринта, а кто-то любит поныть о каких-то проблемах в команде, например, отсутствие коммуникации или «а вот тестирование у нас полное говно, можно куда лучше тестировать, вот так и так» или «а вот у нас постановки задач через чат гпт пишутся, это вообще нормально? мы потом допускаем кучу неточностей из-за этого в разработке»

1х1 встречи — опциональная штука. Это встречи с твоим прямым руководителем (тимлид или менеджер), который спрашивает у тебя фидбэк по команде, по спринту и тд. Тут можно высказывать свои боли и говорить, что не устраивает. В ответ ты получишь фидбэк по тебе от тимлида или от других коллег и подумаешь на тем, что можно улучшить в себе. Здесь стоит подготовить вопросы заранее, чтобы было что обсуждать, а иначе вы будете скипать, а скип таких созвонов не очень хорошая идея, потому что как минимум покажет твою невовлечённость и нежелание)

Базовый процесс любого разработчика. Когда твой коллега выкатывает PR/MR, то ты должен вникнуть в его задачу, посмотреть его код и дать фидбэк. Здесь сильно помогут нейросети: переключаешься на ветку, пишешь промпт ИИшке, что должно быть сделано, и она в целом проверит на всякие мелочи и даст тебе анализ. Ты уже исходя из своего опыта, поймёшь, фигня это или нет. И оставишь комментарии коллеге) Лично я так и ревьюю на новой работе, и тебе советую, ИИ экономит время в этом плане.

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

Если хочется дальше углубляться в это, можно почитать статью, я лишь дал базы