Техническое ревью — зачем и как проводить
Техническое ревью — обсуждение задачи перед разработкой
Состоит из 4 шагов:
- Выясняем ценность задачи
- Находим техническое решение
- Декомпозируем задачу
- Оцениваем сроки
Зачем?! Можно ведь просто сделать задачу быстрее
- Понимание ценности задачи и уверенность в необходимости => мотивация делать
- Одна голова хорошо, а две — лучше: находим более качественные решения
- Находим препятствия и опасности на раннем этапе — сразу придумываем, как их избежать
- Минимум прокрастинации. Чёткие шаги в описании — бери и делай
- Задача понятна новичку, если подробно и хорошо описана
- Легко делать code-review: понятно, какую задачу и как решал автор ПР
- Точная оценка
Как провести техническое ревью
1. Выбери и подготовь задачи
В идеале, задача поставлена по чеклисту. Но базовое требование одно — описана решаемая проблема. Без описанной проблемы — нечего и незачем обсуждать. Также будут полезны: возможное решение, макеты, документация, затронутые багом пользователи.
2. Назначь встречу, определи участников
Напиши в канал сообщение: список задач, время встречи. Попроси проголосовать за задачи тех, кто хочет участвовать в обсуждении. Из проголосовавших выбери не больше 3-4 человек. Если людей будет больше, то встреча не пройдет конструктивно.
Зеленый чеклист:
Перед обсуждением попроси каждого ответить для себя на вопросы:
- понимаю ли я, что вообще написано в тикете?
- как сейчас работает бизнесово и технически? почему так?
- как должно работать? почему так? каких целей добьемся? (с точки зрения бизнеса)
- согласен ли я с тем, что это важно и нужно делать?
- чью проблему мы решим? все ли пользователи будут довольны?
- есть ли решения проще? можно ли совсем обойтись без разработки?
В начале встречи еще раз вернитесь к этим вопросам.
3. Опубликуй план встречи
За пару часов напиши в канал порядок ревью задач и участников. Так каждый будет знать, когда придет его очередь. Если ревью затягивается, можно отправлять в канал апдейты.
4. Проведи встречу
- Создай комнату, включи запись
- Позови участников
- Обсудите проблему: смотри зеленый чеклист выше
- Если непонятно, зачем делать задачу — зови на встречу продакта, заказчика
- Если решение плохое — зови продакта
- Если есть другие продуктовые вопросы — зови продакта и проводите допрос
- Придумайте техническое решение и подробно его опишите
- Если непонятно, как делать — сделайте задачу “попробовать, потыкать, разобраться” — и отложите ревью
- Детализация решения — на ваше усмотрение, но мы ни разу не видели “слишком подробного решения”
- Декомпозируйте! Желательно, чтобы каждая часть была независима для разработки и выкатки
- Ответьте на вопросы
- Понимаю ли я, что конкретно нужно сделать?
- Все ли мы учли? Вижу ли я потенциальные проблемы при решении?
- Не блокирует ли что-то задачу? (дизайн, верстка, другая команда, тестовые данные, доступы)
- Что мы сломаем? Например, переименование таблицы сломает аналитику, изменение АПИ / виджета сломает их клиентов.
- Оцените задачу
- Оценивайте каждый пункт отдельно: схема + миграция, новый метод API, графический интерфейс.
- Каждый участник дает свою оценку в часах (например, пишет в чат на счет раз-два-три), в задачу запишите среднее
- Если оценки сильно разошлись: 5h и 15h — среднее писать нельзя. Нужно разбираться глужбе или делать research.
- Сделайте лимит по оценке: например, 16 часов. Если не уложились, декомпозируйте или проводите research.
5. Поделись результатами
Вся команда и бизнес будут знать: что решили, во сколько часов оценили.
Советы для ведущего
- Иногда требуется research: покопаться в данных, сделать отчет, разобраться в технологии. Не стоит делать это вчетвером. Сделайте дополнительную задачу на исследование и вернитесь к ревью после.
- Следи, чтобы обсуждение шло по алгоритму и не превращалось в срач. Часто участники начинают обсуждать важные и интересные вещи, которые не относятся к задаче и не приближают встречу к завершению.
- Старайся дать высказаться каждому: “Петя, ты согласен?”, “Сережа, что думаешь?”. Иначе решать будут те, кто громче кричат.
- Критерии хорошего ревью
- проходит живо и энергично
- не затягивается: чем быстрее результат — подробно описанная задача - тем лучше
- на выходе крутое решение
Шаблон задачи
Проблема: <Решаемая проблема>
Решение: <...>
Дополнительная информация: <...>
=================
Техническое решение:
1. Делаем раз
2. Делаем два
3. Делаем три
Обсуждение в слаке: <ссылка на тред в слаке>
Ревьюили: @Вася @Петя
Запись ревью: <ссылка на запись>
А что после ревью?
- Желательно, чтобы задачу делал один из участников обсуждения
- Если в процессе разработки выяснились важные подробности, лучше обсудить задачу еще раз
- Не забывай обновлять описание задачи, если изменились требования. Лучше делать это через UPD, а не исправляя старое.