Недавно на стол директору по информационной безопасности доставили личный дневник одного разработчика, найденный возле недопитого смузи в кафе рядом с московским офисом. Записки оказались в отделе ИБ из-за того, что в них было много чувствительной информации. Но помимо этого в дневнике было и кое-что интересное о жизни фронтендера — этим мы решили поделиться с вами.

Дейли

13 февраля, 10:58 — Начало рабочего дня

Проснулся после бурных выходных за две минуты до начала дейли и судорожно пытался вспомнить, какими задачами я сейчас занят и в каком они состоянии. Хорошо, что команда работает по Kanban: так я могу в любой момент зайти на нашу доску и выяснить, что же я все-таки успел сделать в пятницу. Этим, пожалуй, и стоит заняться. Доска эпиков, доска историй… Вот, доска с сабтасками, отлично. Стоп, что это за задача занимает теперь почетное первое место на нашей доске? И откуда на задачах бэка взялись флаги?

13 февраля, 11:00 — Дейли

Как обычно, собрались в Зуме на дейли. Большая часть сотрудников компании работает на удаленке, многие распределены по разным городам, так что по-другому поддерживать постоянную связь сложно. Приятным бонусом к созвонам идут домашние животные коллег: у одного парня кот сидит на плече на каждом дейлике — видимо, следит за выполнением задач. Кстати, о задачах… 

У меня большая продуктовая команда из 13 человек: 8 разработчиков, 2 QA-инженера и 3 менеджера. Рассказ каждого о себе и своих делах неэффективен, поэтому на дейликах мы говорим о задачах в порядке приоритета. Такая методика давно доказала свою эффективность: наши дейли длятся не больше 15 минут, за которые все участники встречи успевают осознать общий прогресс работ. 

Сегодня мы начали разговор с новой задачки наверху доски: оказалось, что на проде вылез критичный баг и приложение крашится. Наш android-разработчик оставил другие задачи, чтобы все починить.

Постепенно спустились по доске ниже. Оказалось, моя сабтаска прошла ревью и мне осталось передать ее на тестирование QA, которая подхватила ее заодно и рассказ по задачкам. И хотя по правилам Kanban нужно говорить о задачах справа налево, иногда мы забываемся и делаем наоборот.

Когда добрались до задачи стажера, поняли, откуда взялись сабтаски с флагами. Они оказались заблокированы из-за внезапного обновления API другой команды, которое сломало запросы нашего приложения к их сервису. Стажеру достаточно было подсветить это на дейли — и вот уже тимлид идет вместе с ним к другой команде,чтобы решить проблему с блокировкой.

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

Дейли закончился, и, если я сам не хочу стать чьим-то блокером, пора двигать дальше наше колесо прогресса по задачам и браться за работу.

Процесс работы — TBD, ревью

13 февраля, 11:45 — Кофе-брейк

Я считаю, что уже достаточно долго работал в поте лица над новой задачей — пора организовать себе третью за утро чашку кофе и небольшой перерывчик.

13 февраля, 12:00 — За дело

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

14 февраля, 13:28 — Корректирую оценку задачи

Вроде изян.

15 февраля, 14:32 — Работа, работа, еще раз работа

Как же я люблю TBD и все, что с ним связано… 

При трудоустройстве мне рассказали, что большинство команд работают в соответствии с этим самым Trunk Based Development — маленькие MR, частые релизы, быстрое тестирование. Все звучало просто как сказка. 

Мы и правда релизим в несколько раз чаще, чем те немногие команды, в которых еще не внедрена практика TBD, а тестирование задач занимает не больше дня. Но не бывает же все просто идеальным…

Вот и я, закопавшись в одной из практик TBD — Branch by abstraction, не смог придерживаться второй — маленького объема кода, отправленного на ревью. Казалось бы, этот самый Branch by abstraction несет здравую мысль: вводить изменения несколькими маленькими шагами вместо одного большого. 

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

Вот тот самый план по шагам:

1. Ввести абстракцию. Тут все верно: я давно создал и слил новый интерфейс в основную ветку, ведь изменение-то небольшое и абсолютно безопасное.

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

3. Выключить эту реализацию для всех, кроме себя, — сделали вместе с предыдущим пунктом при помощи фича-флагов.

4. Итеративно делать новую реализацию… Так… Читаю: «Работать над новой реализацией нужно мелкими шагами: по возможности отдельно делать бизнес-логику, рефакторить, писать тесты. Главное, чтобы при этом ваш проект проходил тестирование и сборку на CI». 

А я забыл про то, что с итеративным подходом можно было и тесты писать отдельно, и рефакторить не все сразу. Забыл — и получил в результате огромный MR, где переписал львиную долю нашего кода по работе с аналитикой и сразу же тесты на все это накрутил! 

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

5. Удалить старую реализацию и при необходимости абстракцию.

Вот она, сила замены колес прямо на ходу, да еще и за пять шагов! Но переделывать свой уже открытый MR я, конечно, не буду.

15 февраля, 16:04 — Ревью

Кажется, это было ошибкой.

15 февраля, 16:58 — Все еще ревью

Мое счастье, что такой большой MR вообще согласились посмотреть. Но количество комментариев… Мама, забери меня на ручки, погладь по голове и скажи, что я все сделал правильно.

Конечно, все комментарии справедливые и даже полезные. Инициатива с кросс-командным ревью — хороший способ обмена экспертизой и получения нового опыта и насмотренности. Но палка о двух концах: комментарии-то, может, и полезные, но ради аппрува разработчика из другой команды нужно тратить время на доработки. А бывает, что ребята заняты и не могут посмотреть MR в ближайшее время и он так и висит.

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

Может, поставить себе такую индивидуальную задачку на развитие — звучит как возможность сильно повлиять на процессы внутри компании, а инициатива у нас награждается отлично. Если инициатива хорошая, естественно.

А мой MR на 600 строк к таковым пока не относится, поэтому пойду дальше читать комментарии к нему и исправлять их… 

15 февраля, 17:04 — ████████████ комментарии

В смысле «это можно было уложить в две строки вместо 50»?! [ДАННЫЕ УДАЛЕНЫ]

3 амиго

20 февраля, 14:00 — Три амиго по [фиче]

Почти закончили текущую фичу, а значит, пришло время обсуждать спецификацию по следующей. А это значит…

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

Встречи проходят так часто, что если бы каждый «три амиго» мы ходили бы пить пиво, я бы уже отрастил пивной животик. Такая встреча помогает не разложиться фиче на стадии ее проработки и держит в форме нашу спеку. На этом этапе вносится много корректировок и поэтому часто встречи в формате «три амиго» проходят не за один раз и составом гораздо больше трех. 

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

Пока я размышлял о высоком, дизайнер опять решил, что я рожден красить кнопки и не увижу, что его █████████ нереализуем. Настало время заняться конструктивной критикой…

Дежурства

22 февраля, 15:17 — Алерт! Алерт! Алерт!

Сидел, писал код, никого не трогал... Вдруг — бум! Прод немного взорвался, и посыпались алерты к нам в канал. 

Знаю-знаю, «фронтендер на дежурстве» — звучит как начало какого-то анекдота. Но я и в самом деле должен буду разобраться с этими алертами. 

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

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

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

Что сейчас и требуется доказать.

22 февраля, 15:50 — ЧТД

Просмотрел инциденты, удостоверился по графикам, что они действительно случились, и полез в логи нашего бэкенда. Исследовал несколько запросов, по самым длинным начал искать причину проблем на проде. Из логов нашел URL, ответы с которого были самыми долгими, сопоставил его с сервисами других команд и выяснил виновную систему. Сходил к ребятам в [другую команду] и надавал им по шее эскалировал проблему. 

Словом, чуть больше 20 минут моего времени — и проблема решена. Делов-то.

Планирование

24 февраля, 13:00 — Планирование

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

Чтобы планировать регулярно и всей командой, мы создали под этот процесс встречу. Пожалуй, эта встреча из тех, пропустить которые будет не очень хорошо для кого угодно. Если ее пропустит разработчик — не будет точно знать, что делать дальше. Если продакт — все будут счастливы сам потом не поймет, что именно и когда мы взяли или возьмем в работу. QA — не увидит, какие задачи мы хотим прорабатывать дальше, не успеет написать критерии приемки для новых фич и в очередной раз напомнить о незакрытых багах. Короче, работа может встать.

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

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

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

Ретроспектива

27 февраля, 16:00 — Нытинг

Древние пророчества из архивных каналов Слака гласили: «Придет век Зума и Конфлюенса, век Задач в Джире. Придет Час Вечернего Созвона и Доски на Miro, Час Безумия и Час Презрения, Час Конца. [Команда] умрет, погруженная в задачи, и возродится вместе с новым разработчиком». 

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

От слишком горького кофе в офисе до непроработанных требований к последней задаче — каждый из нас всегда найдет что обсудить. Поэтому на этой встрече никогда не бывает тихо, а скорее даже наоборот: часто разгораются жаркие дебаты на самые разные темы. 

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

Например, на прошлом ретро мы поняли, что сильно затормозили поставку фичи из-за команды, с которой совместно разрабатывали апишку. Вроде это была простая жалоба от одного из бэкендеров, но нет — наш менеджер услышал тревожный звоночек и передал эти слова второй команде в чуть более тактичной форме. Мы удивились, но тимлид ███████ поблагодарил нас за качественную обратную связь и показал, что они учли наши замечания в своем плане по ускорению поставки. Вот что я называю действительно командной работой.

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

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

А если есть какая-то тайная личная боль — можно провести что-то похожее на микроретро, один на один со своим руководителем. Но об этом как-нибудь в другой раз — сейчас мне пора исполнить свой геройский долг и двинуть команду в светлое будущее.

Вместо заключения

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

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

Заглядывайте в наш блог почаще, открывайте для себя новые горизонты или присоединяйтесь к нашей команде — и узнайте все тонкости работы внутри Тинькофф сами. Мы рассказываем о жизни команды в телеграм-канале и публикуем вакансии в формате дайджеста.