Команда Трекера, как и весь Яндекс, работает в Трекере — это не секрет. Мы взяли интервью у Игоря Лепёшкина, руководителя нашей команды разработки. Игорь рассказал, как настроены процессы команды в Трекере, какие инструменты он ценит больше всего и как эффективно настроить Трекер для разработки.
Сколько нужно очередей
Мы разделили все задачи на четыре очереди:
- Общая очередь разработки, в ней все продуктовые задачи
- Очередь поддержки для внешних пользователей
- Очередь поддержки для внутренних пользователей
- Очередь для поддержки разработчиков, где мы отвечаем на сложные технические вопросы.
В целом, количество очередей зависит от того, насколько изолирована работа над разными частями сервиса. Если ваша команда делает все части вместе, и любой сотрудник может взяться за любую работу, то можно обойтись одной очередью.
Если разработчики не пересекаются в работе, можно создать под них выделенные очереди — так будет нагляднее, и у каждой очереди будет настроен оптимальный процесс. Если вы заранее понимаете, что работа над разными компонентами требует разных процессов, то задумайтесь об отдельных очередях. Но тут нет универсального плана и неправильных решений: просто в случае с одной очередью придётся выполнять чуть больше мелких настроек.
Разработка и Agile
Мы уже около двух лет работаем по методологии SCRUM. Начинать было непросто: команда не понимала, зачем встречаться так часто и отвлекаться от работы. Потом стало ясно, что эти встречи помогают лучше разобраться в задачах, избежать ошибок в написании кода. Все члены команды могут повлиять на то, как всё организовано, настроить удобный процесс. На встрече может оказаться, что не хватает какого-то макроса или триггера — тогда кто-то из команды после встречи его настроит. Доступ к настройкам очереди есть у всех.
Мы ежедневно проводим стендап, на котором проверяем доску и смотрим на диаграмму сгорания задач.
Это помогает приоритизировать задачи и понять, что тормозит и где надо помочь. Каждые две недели мы проводим ретроспективу, на которой вся команда подводит итоги спринта: что было хорошо, что не очень, как это исправить. Каждые три месяца проходит стратегическая сессия, обсуждаем, как сделать совместную работу комфортнее. На таких встречах появляются идеи, как оптимизировать рабочий процесс. Например, так мы ввели в команде роль фича-лида (feature lead) — разработчика, который помогает продакт-менеджеру прорабатывать новые крупные функциональности.
До скрама мы никак не измеряли скорость разработки и эффективность. Брали в работу то, что приносили менеджеры. Теперь мы больше отвечаем за процесс разработки. Фича-лид дорабатывает идею с менеджером, затем обсуждает новую функциональность с командой. Мы делим её на задачи, распределяем по спринтам и ставим исполнителей. Задачи отображаются на досках и видно, что нужно сделать в этом спринте, а что запланировано на следующий.
Доска задач в Трекере
Как мы стали эффективнее
До скрама задача могла висеть в статусе «в работе» очень долго. Задачи застаивались, не было жёстких сроков. Теперь разработка доходит до продакшена за 10 дней. Это позволяет получать предсказуемый результат уже сейчас.
Мы стали подробнее описывать задачи, оценивать их в покере, настроили автоматизацию через API — в целом готовимся к выполнению задач дольше. Мы поставили SLA на код-ревью, это позволяет отслеживать выполнение код-ревью в срок.
Ещё поднимаем стенды на каждую задачу. Раньше тестирование проводилось на виртуальных машинах, нужно было либо тестировать по одному изменению за раз (это медленно), либо все одновременно (на ВМ это неудобно). Мы написали небольшой код, и теперь ссылка на стенд автоматически прикрепляется к задаче — в комментариях или в отдельном поле.
Сейчас мы пробуем отслеживать цикл-тайм фичей, а не отдельных задач. Мы получаем статистику по задачам через API — там видим, что тормозит процесс запуска фичи.
В чем ценность Трекера для команд разработки
Самая полезная часть Трекера для разработки — автоматизация. Она сильно упрощает жизнь команды. Мы создали триггеры, чтобы автоматически назначать исполнителей на некоторые задачи, настроили уведомления о статусе код-ревью в Slack. Это освобождает руки разработчиков, и они могут заняться написанием кода, а не созданием задач и их заполнением. Мы написали дополнительный код, благодаря которому в зависимости от результата код-ревью в задаче меняется статус: либо «нужна доработка», либо «можно тестировать».
Иногда появляются задачи без описания, с одним заголовком. В такие моменты приходится писать автору и просить подробности, это отнимает время. Мы настроили триггер: в любой задаче без описания появляется картинка с котиком и шаблон, по которому надо описать задачу: общее описание бага, шаги, ожидаемое действие, фактическое действие. Теперь не нужно никого призывать, все сами приходят и дают описание по пунктам.
Задача в Трекере
Как мы избегаем рисков при разработке
Плохо настроенный релизный процесс может сильно мешать. Раньше у нас было так, что из-за одной плохой задачи не выкатывался весь релиз. Релизный процесс изменился: теперь мы пересобираем релизную ветку в репозитории, чтобы доработать тормозящую задачу.
Также плохое код-ревью — бомба замедленного действия. На тестировании может всё работать, но качество кода может оказаться плохим, и исправлять эту функциональность в будущем будет слишком дорого. Мы стараемся избежать этого: подключили репозиторий, и теперь для код-ревью случайно выбираются два разработчика. Мы дописали код, чтобы статус «завершили код-ревью» появлялся в Трекере автоматически.
На что обратить внимание при настройке Трекера
Завести доску. На ней просто отслеживать задачи. Настройте процесс вместе с продакт-менеджером, определите, как и по каким критериям задачи попадают на доску, как их ранжировать.
Настроить поднятие стендов на каждую задачу. Важно максимально изолировать работу над каждой задачей, чтобы тестировать, проводить код-ревью и выкатывать задачи независимо друг от друга.
Собирать всю связанную с задачей информацию в самой задаче. Важно, чтобы в комментариях была ссылка на стенд, в связанных задачах — вся нужная информация и релизная задача. В таком случае всегда можно отследить последовательность действий, если что-то пошло не так, и понять, в чём проблема.
Объяснить команде важность описания задач. Чтобы в описании было подробно рассказано о том, что нужно сделать, а в комментариях — как это было сделано и как задача выкатилась в продакшн. Отписываться в комментариях по результатам встреч и обсуждений — полезная привычка.
Настроить интеграцию с репозиторием, чтобы быстро видеть, какие коммиты делались по той или иной задаче. Мы также пишем номер задачи в коммитах, чтобы было легче найти задачу в Трекере и понять, зачем делали коммит и какую проблему решали.
Обратная связь
Нам важно, чтобы материалы о Трекере были для вас полезны. Поделиться вашим мнением и пожеланиями можно здесь.
Полезные ссылки
Как настроить создание задач из формы
Как настроить интеграцию с репозиторием
Полезные видео