Техническое ревью — зачем и как проводить ======================================================================================================= :::success **Техническое ревью — обсуждение задачи перед разработкой** ::: Состоит из 4 шагов: ------------------- 1. **Выясняем ценность задачи** 2. **Находим техническое решение** 3. **Декомпозируем задачу** 4. **Оцениваем сроки** Зачем?! Можно ведь просто сделать задачу быстрее ------------------------------------------------------------------------------------------- - **Понимание ценности задачи** и уверенность в необходимости =&gt; мотивация делать - Одна голова хорошо, а две — лучше: находим **более качественные решения** - **Находим препятствия и опасности** на раннем этапе — сразу придумываем, как их избежать - **Минимум прокрастинации**. Чёткие шаги в описании — бери и делай - **Задача понятна новичку**, если подробно и хорошо описана - **Легко делать code-review:** понятно, какую задачу и как решал автор ПР - **Точная оценка** Как провести техническое ревью ------------------------------ <h3> 1. Выбери и подготовь задачи </h3> <p>В идеале, задача поставлена по чеклисту<br /> Но <strong>базовое требование одно —</strong> описана решаемая проблема.<br /> Без описанной проблемы — нечего и незачем обсуждать.<br /> Также будут полезны: возможное решение, макеты, документация, затронутые багом пользователи.</p> **Зачем** - Написано в чеклисте - Без описанной проблемы — нечего и незачем обсуждать. <h3> 2. Назначь встречу, определи участников </h3> - Напиши в канал сообщение: список задач, время встречи. Можно пользоваться ботом Jake (/techreview). Для настройки бота пиши #dev-shared-team (нужно указать названия проектов в Jira, людей которые смогут триггерить техревью и статус задач которые будут падать в голосование) - Попроси проголосовать за задачи тех, кто хочет участвовать в обсуждении. - Из проголосовавших выбери не больше 3-4 человек. Если людей будет больше, то встреча не пройдет конструктивно. - Если заранее известно, что нужен человек не из команды (продакт, разработчик и т.д), нужно заранее его пригласить. <strong>Пример сообщения:</strong> <div><pre><code>*Понедельничный Tech-Review — сегодня в 11.00* :one: :boom: *Проблема с выплатами Paypal* https://JIRA/browse/BILL-xxxx :two: :scroll: *Починить лейблы в платежных периодах* https://JIRA/browse/BILL-xxxx :three: :scroll: *Импорт платежных ведомостей* https://JIRA/browse/BILL-xxxx голосуй за те задачи, где твое участие *поможет* обсуждению ^ после того, как проголосовал, *прочитай задачу* и подумай над решением </code></pre></div> Перед обсуждением попроси каждого ответить для себя на вопросы: :::success **Зеленый чеклист** <br/> <ul> <li>понимаю ли я, что вообще написано в тикете?</li> <li>как сейчас работает бизнесово и технически? почему так?</li> <li>как должно работать? почему так? каких целей добьемся? (с точки зрения бизнеса)</li> <li>согласен ли я с тем, что это важно и нужно делать?</li> <li>чью проблему мы решим? все ли пользователи будут довольны?</li> <li>есть ли решения проще? можно ли совсем обойтись без разработки?</li> </ul> ::: В начале встречи еще раз вернитесь к этим вопросам. Публиковать голосование нужно заранее, не меньше чем за 8 часов, чтобы все успели запланировать время. Если никто не проголосовал за задачу, можно сообщить об этом на дейли команде, обсудить почему. **Зачем** - чтобы ограничить кол-во участников (не тратить лишнее время) - чтобы все подготовились, прочитали задачи - чтобы запланировали своё время - чтобы заранее задать вопросы, если кому-то задача не понятна - чтобы заказчики видели, что их задачи скоро будут обсуждать <h3> 3. Опубликуй план встречи </h3> <p>За пару часов напиши в канал порядок ревью задач и участников.<br /> Так каждый будет знать, когда придет его очередь.<br /> Если ревью затягивается, можно отправлять в канал апдейты.<br /> </p> <strong>Пример сообщения:</strong> <div><pre><code>План технического ревью, начнем сегодня в 11:00 :rocket:   • *Разобрать мусор в #billing-warnings* https://JIRA/browse/BILL-xxxx @deusdeorum @andrey @Oleg <br/> • *Составить список с актуальностью таблиц в базе billing* https://JIRA/browse/BILL-xxxx @deusdeorum @andrey @Oleg @igor <br/> • *Перезачет минусовых корпоративных уроков из обычных уроков* https://JIRA/browse/BILL-xxxx @deusdeorum @andrey @igor </code></pre></div> Желательно делать расписание с меньшим количеством перестановок участников, чтобы не дёргать каждого по 2-3 раза (есть скрипт, заточенный под Jake, чтобы такое делать). "Подготавливает" - выбираем одного человека. Ему надо: открыть релевантный код, документацию, подготовить SQL запросы, ... . Не должно быть больше одной задачи для подготовки на одного человека. **Зачем** - Так каждый будет примерно знать, когда придет его очередь. <h3> 4. Проведи встречу </h3> 1. Создай комнату, включи запись 2. Позови участников 3. Обсудите проблему: смотри зеленый чеклист выше * Если непонятно, зачем делать задачу — зови на встречу продакта, заказчика * Если решение плохое — зови продакта * Если есть другие продуктовые вопросы — зови продакта и проводите допрос 4. Придумайте техническое решение и подробно его опишите * Если непонятно, как делать — сделайте задачу "попробовать, потыкать, разобраться" — и отложите ревью * Детализация решения — на ваше усмотрение, но мы ни разу не видели "слишком подробного решения" 5. Декомпозируйте! Желательно, чтобы каждая часть была независима для разработки и выкатки 6. Ответьте на вопросы * Понимаю ли я, что конкретно нужно сделать? * Все ли мы учли? Вижу ли я потенциальные проблемы при решении? * Не блокирует ли что-то задачу? (дизайн, верстка, другая команда, тестовые данные, доступы) * Что мы сломаем? Например, переименование таблицы сломает аналитику, изменение АПИ / виджета сломает их клиентов. 7. Оцените задачу * Оценивайте каждый пункт отдельно: схема + миграция, новый метод API, графический интерфейс. * Каждый участник дает свою оценку в часах (например, пишет в чат на счет раз-два-три), в задачу запишите среднее * Если оценки сильно разошлись: 5h и 15h — среднее писать нельзя. Нужно разбираться глужбе или делать research. * Сделайте лимит по оценке: например, 16 часов. Если не уложились, декомпозируйте или проводите research. **Зачем** - запись видео может пригодиться, если задача сложная и было отброшено много альтернативных решений. Лучше всегда включать - Декомпозируйте, чтобы более точно оценивать и быстрее выкатить независимые части. А также это позволит нескольких людям одновременно делать более простые задачи <h3> 5. Поделись результатами </h3> Вся команда и бизнес будут знать: что решили, во сколько часов оценили. <strong>Пример сообщения:</strong> <div><pre><code>*Tech-review итоги сегодняшнего сложного дня!* :green_apple: *Выпилить обращения к таблице `order` в CRM из billing* _разобрали миллион кейсов, сейчас согласовываем с командой CRM_ :green_apple: *Добить историю с новой оплатой на лендингах* — *13.5h* _все неплохо, мелкие ошибки тут и там, разобрали, @maxim будет доделывать_ :green_apple: *Импорт платежных ведомостей* _импорт из google doc заменили на импорт .csv, @andrey уже взял_ </code></pre></div> Советы для ведущего ------------------- - Зафиксировать дни и время ТР. Это позволит привыкнуть к расписанию и не пропускать. - Иногда требуется research: покопаться в данных, сделать отчет, разобраться в технологии. Не стоит делать это вчетвером. Сделайте дополнительную задачу на исследование и вернитесь к ревью после. - Следи, чтобы обсуждение шло по алгоритму и не превращалось в срач. Часто участники начинают обсуждать важные и интересные вещи, которые не относятся к задаче и не приближают встречу к завершению. - Старайся дать высказаться каждому: "Петя, ты согласен?", "Сережа, что думаешь?". Иначе решать будут те, кто громче кричат. - Критерии хорошего ревью - проходит живо и энергично - не затягивается: чем быстрее результат — подробно описанная задача, тем лучше - на выходе крутое решение Шаблон задачи ------------- ``` Проблема: <Решаемая проблема> Решение: <...> Дополнительная информация: <...> ================= Техническое решение: 1. Делаем раз 2. Делаем два 3. Делаем три Обсуждение в слаке: <ссылка на тред в слаке> Ревьюили: @Вася @Петя Запись ревью: <ссылка на запись> ``` А что после ревью? ------------------ - Желательно, чтобы задачу делал один из участников обсуждения - Если в процессе разработки выяснились важные подробности, лучше обсудить задачу еще раз - Не забывай обновлять описание задачи, если изменились требования. Лучше делать это через UPD, а не исправляя старое.