Ревью задач что это

Ревью требований аналитиков: что, как, зачем. Качественные требования

Привет!
В статье поговорим о тестировании требований.
Наверняка назревает вопрос : а что это за слово странное такое «ревью»? Все очень просто — для корректной постановки задач на разработку необходима проверка требований и согласование их внутри команды. Об этом и поговорим в сегодняшнем посте. Погнали!

4.4K открытий

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

Ревью требований — по сути обычная проверка того, что написал аналитик. Как вы знаете, аналитик — тоже человек (неожиданно), и ему свойственно где-то допускать неточности, так как зачастую приходится описывать несколько задач за спринт параллельно. Это очень важный этап в работе аналитика: согласовать ФТ лучше не только с заказчиком, но и командой, так как она отвечает за реализацию задачи.

Зачем проверять требования?

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

Второе. От корректно проведенного ревью зависит развитие продукта: уменьшение количества багов/лишних вопросов на этапе реализации и так далее.

Как проводить ревью?
Я описываю в статье то, какой опыт у меня на работе.
Процесс ревью проходит следующим образом: как только требования зафиналены, я передаю их на проверку другому аналитику, QA, тимлиду и PM. Вы скажете — дофига что-то. На самом деле, это стоит того. Каждый их них просматривает требования по следующим характеристикам:

1) Декомпозиция. Одна страничка на Confluence — одна функциональность. Если вы смотрите на сплошной текст и не видите ему конца и края, требования лучше разбить на подразделы.

2) Однозначность. Всем понятно, для чего используется тот или иной термин, нет двусмысленности в понятиях. Для специфичных терминов заведен глоссарий.

3) Непротиворечивость. Сложно справляться с тем, чтобы поддерживать актуальную информацию, например, если какое-то условие встречается в тексте несколько раз(пример: какое-то поле в интеграции с сервисом указано в табличке и где-то в контракте. оно поменялось, а аналитик уже мыслью улетел куда-то в далекие края и не поправил. на выходе получаем сложности в поддержке инфы) . Скажу честно — с таким пока мне сложно, часто совершаю ошибки именно в этом месте, но буду пробовать различные подходы к хранению уникальных значений на фичу: макрос, выделение на отдельную страницу и другое.

4) Тестируемость. Можно ли протестировать функционал? Чтобы помочь QA автоматизировать тест-кейсы, прикладываем в требования пару сценариев использования. Тогда и проверять новую задачу будет легче.

5) Осуществимость. Если тут возникли вопросы, хочется сказать только: «Жалко конечно, этого добряка 🙁 »
Оценку реализации лучше делать до постановки задачи аналитику, но если вопросы возникли на данном месте, когда требования уже написаны, прямая дорога к заказчику на продумывание нового решения. (или, если нам повезло, решение формируется внутри команды)

6) Полнота. Не написано лишнего, но есть все, что нужно. Кратко и желательно сухо: функционал, сценарии, состав данных(и что вам еще надо) . Я люблю прикладывать к требованиям схему процесса в нотации BPMN.

После того, как требования прочитаны (да-да, читать не любит никто, даже аналитик иной раз) , команда либо проговаривает замечания, либо утверждает документацию и она переходит на ревью заказчиком. Вот и все! Вы прекрасны и замечательны, а еще предотвратили возможные сложности в реализации задачи.

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

Код-ревью: Как в KazanExpress контролируют качество кода?

Наши разработчики постоянно работают над новыми проектами и совершенствуют IT-процессы, чтобы продукты были качественнее, а работа над ними — эффективнее. Но новые функции не сразу внедряются в проект. Сначала код отправляется на код-ревью, то есть на проверку.

Поговорили с Тимуром Боргалиновым, разработчиком KazanExpress, и узнали, что такое код-ревью, в чем особенности этого процесса и как добиться более качественного результата.

Что такое код-ревью и зачем он нужен?

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

Перед тем как заняться внедрением или улучшением код-ревью, нужно задать своей команде пару вопросов:

1. Сколько в среднем времени занимает ревью кода?
2. Как у вас в команде понимают, что ревью было сделано правильно?
3. Пытаетесь ли вы уменьшить время ревью? Если да, то как?

Ответив на эти вопросы, вы сможете оптимизировать код-ревью конкретно для вашей команды.

Чем грозит некачественный код-ревью?

1. Снижается скорость работы над проектом. Не все быстро отвечают на запросы из-за обилия задач, и это тормозит работу команды. Исправления замечаний могут затянуться на недели.
2. Медленные ревью препятствуют рефакторингу (изменению кода, облегчающему понимание) и дальнейшим улучшениям.
3. Разработчики начинают выступать против код-ревью. Если ревьювер (тот, кто проводит код-ревью) отвечает только через несколько дней, но каждый раз запрашивает существенные изменения, — это неприятно. Начинаются жалобы на то, что ревьювер слишком «строг». При этом, если он запрашивает те же изменения, но реагирует быстро, жалобы исчезают. А значит, проблема кроется не в «строгости», а в скорости ответа.

Что поможет выполнять код-ревью быстрее?

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

Что поможет улучшить качество код-ревью?

1. Командное владение кодом

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

2. Переиспользование кода

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

3. Обмен знаниями внутри команды

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

4. Выявление ошибок

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

5. Единообразие и простота проекта

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

6. Рефлексия или self-review

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

7. Чек-листы и автоматизация

Запоминайте вопросы, которые часто возникают у команды на ревью, и заносите их в чек-лист. Главное — не давать документу разрастаться. Думайте о способах автоматизации каждой из перечисленных там проверок. Если приложить достаточно усилий, большую часть вопросов вы сможете закрыть сами. Есть огромное количество инструментов, которые могут помочь в этой работе: линтеры, статические анализаторы, детекторы дублирующегося кода — например, SonarQube помогает с непрерывным анализом и измерением качества программного кода.

8. Архитектурные встречи

Код-ревью — не самое подходящее место, чтобы спорить по поводу глобальных архитектурных решений. Код уже написан, решение выкачено, задача почти доделана. Переписывать с нуля — слишком затратно и часто не оправдано. Такие вещи нужно не оставлять на потом, а обсуждать заранее. Например, можно провести архитектурную встречу с защитой и аргументацией своего решения перед командой — либо на словах, либо в виде схемы. Иногда, когда кого-то осеняет уже во время ревью и предложение оказывается ценным, стоит задокументировать идею в issue-трекере (системе поиска ошибок, — прим. ред.) и вернуться к ней при необходимости.

Как общаться с разработчиками во время код-ревью, чтобы не раздуть конфликт?

• Будьте вежливы.
• Объясняйте свои рассуждения.
• Позволяйте разработчику решать проблемы самому.
• Поощряйте разработчиков упрощать код.

Хороший пример коммуникации: «Использование этой библиотеки тут лишнее, так как она добавляет слишком много функционала, которым мы пока не пользуемся. Думаю, в этом случае было бы целесообразнее взять только нужную часть и использовать ее в новом модуле».

Плохой пример коммуникации: «Зачем ты запилил эту либу? Где вообще нашел ее? Переделывай все».

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

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

Когда разработчик не согласен с вашим комментарием как ревьювера, найдите время рассмотреть его позицию. Он ближе вас к коду, у него действительно может быть более объективное представление. Есть ли смысл в его аргументе с точки зрения качества кода или бизнес-решения? Если да, то признайте его правоту, и вопрос отпадет.

Но разработчики правы не всегда. Тот, кто проводит ревью, должен объяснить, почему его предложение верное. Хорошее объяснение демонстрирует понимание ответа разработчика и содержит дополнительную информацию о том, почему требуется изменение. Когда ревьювер считает, что его предложение улучшит качество кода и полученное улучшение качества оправдывает дополнительную работу, он должен настаивать на решении.

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

Главное правило код-ревью — не бежать за идеалом

Не бывает идеального кода, бывает только код «получше». Не стоит требовать от автора полировать каждый крошечный кусок. Команда должна стремиться не к идеалу, а к непрерывному улучшению кода.

Жизненный цикл задач

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

Постановка задачи

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

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

Обсуждение задачи

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

Прежде чем перевести задачу в следующий статус, стоит рассказать о ней как можно большему количеству участников команды. В идеале, задачу должен одобрить каждый, но в реальной жизни — это не всегда возможно. И мы решаем эту проблему так: пишем о новой идее в чате Telegram, обсуждаем и формируем общее представление о задаче. Если кто-то не участвовал в этом обсуждении, автор идеи спрашивает мнение оставшихся участников лично. Задача переходит в следующий статус только спустя некоторое время после обсуждения (обычно на это уходят сутки).

После того, как задача получила описание она может:

• Получить статус Won’t Fix: мы закрываем задачу и не собираемся её делать. Это лучший исход для задачи, она не усложнит наш проект. Ради этой задачи не придётся идти на компромиссы, мы станем ближе к пользователям, даже если потеряем часть аудитории, оно того стоит. Вместе с этим лейблом нужно указать причину отказа от реализации, чтобы была возможность вернуться и пересмотреть своё решение.
• Стать замороженной (Freezed). Мы обсудили задачу, решили, что она реально важна нашему проекту и нашим пользователям, но её время ещё не пришло. Может быть, её реализация станет значительно проще после выполнения какой-то другой задачи. Может быть, это просто напоминание о том, как сделать проект лучше. При переводе в этот статус важно позаботиться о разморозке этой задачи (поставить напоминание и описать процесс разморозки).
• Получить статус To Do. В этом списке находятся задачи, которые будут реализованы командой. На данном этапе мы ставим лейблы к задаче, то есть решаем, каких областей она касается, а также оцениваем трудность выполнения и возможные проблемы, с которыми придётся столкнуться при реализации.

Выполнение задачи

Задачи в состоянии To Do присваиваются исполнителям и переходят в статус In Progress. В этом статусе происходит вся магия. Несмотря на то, что задача присвоена одному человеку, её реализация — это дело всей команды. Исполнитель — это человек, который будет писать историю этой задачи и у которого будут спрашивать, почему сделано так, а не иначе. Мы любим помогать друг другу и не боимся просить совета или помощи в реализации.

Долгий путь под названием Review

Из статуса In Progress задача попадает в In Review. Исполнитель создаёт Pull Request, то есть просьбу перенести коммиты (изменения) из ветки этой задачи в рабочую ветку, код из которой работает на сервере. Перед тем как одобрить одобрить пул реквест, нужно удостовериться в том, что задача сделана хорошо. Для этого, исполнитель назначает ревьюеров, ему нужно выбрать по крайней мере двух участников команды, которые имеют разное количество опыта в этом проекте. Часто бывает, что простые вопросы человека, плохо разбирающегося в технологии, сильно улучшают уровень исполнения.

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

После Review задача попадает в статус Done.

Это ещё не всё

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

Почему так сложно?

Многие из наших решений направлены на развитие чувства ответственности и свободы у каждого из членов команды. Задачи структурированы так, что каждый может найти что-то себе по душе и узнать, чем занимаются коллеги. Таким образом, в любое время у нас есть список задач в состоянии To Do, которые с уверенностью можно присвоить себе, перевести в статус In Progress и начать делать. Задачи с меткой Discussion можно обсуждать в свободное время и предлагать свои идеи по реализации. А также постоянно есть пища для ума в виде задач, находящихся в In Review. Мы считаем, что анализ чужих работ и поиск идей по их улучшению — это отличный способ развития навыков и креативности.

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

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

If you like this article, share a link with your friends

Read more

We talk about interesting technologies and share our experience of using them.

Code Review – зачем и как использовать в команде?

Code Review — это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.

Зачем нужен Code Review

Code Review может являться частью процесса выполнения задачи (частью workflow). Может показаться, что ревьювить должен только тимлид или старший разработчик, но хорошей практикой является если в процессе ревью задач участвуют все разработчики. Таким образом можно не только распределить нагрузку от ревью, но и составить у команды более широкое представление о выполняемых задачах. Также это помогает делиться best practices внутри команды.

Положительные эффекты в команде от Code Review:

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

• при разработке задачи на реализацию тратится чуть больше времени
• в задаче задействованы как минимум два разработчика (тот, кто делал задачу и тот, кто ее ревьювил)

Рекомендации по организации Code Review

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

• Избегать рутинных проверок Code Style людьми: автоматизировать такие проверки. Можно использовать для этого любые подходящие вам инструменты для автоматической проверки code style используемого вами языка программирования. Например, для PHP это может быть PHP Coding Standards Fixer https://cs.symfony.com/ Не нужно тратить время разработчиков на то, что можно автоматизировать. Также обратная связь по поводу code style от людей воспринимается как “придирки” и может создать не очень позитивную атмосферу в команде.
• Code Review должен проводиться для каждого участника команды, вне зависимости от уровня. Не должно быть такого, что ревьювят только задачи, которые сделали Junior разработчики, тем временем Senior разработчики не отдают свои задачи на ревью. Необходимо, чтобы ревью проводилось для задач всех разработчиков.
• Code Review является частью процесса и необходим каждой задаче. Это правило избавляет от лишних споров и холиваров насчет небольших задач. Ревью проходят все задачи без исключений.
• Code Review проводится перед релизом задачи и перед передачей ее в тестирование. Это помогает избегать повторного тестирования, а также соблазна оставить все как есть, ведь “и так работает”. К задачам, которые уже на бою, никто не захочет повторно возвращаться.
• Избегать слишком больших объемов кода в одном Code Review. Если задача большая, то необходимо отправлять ее на ревью частями. Есть рекомендуемое число 200-400 строк в одном ревью. При увеличении количества строк, эффективность и продуктивность ревью резко падает.
• Если нет возможности внести какие-то правки после ревью, то необходимо завести задачу в трекере задач, а в коде оставить ToDo с ее номером

Чего следует избегать:

• Если Code Review непостоянная часть процесса разработки, то это приведет к нестабильному ревью, его будут откладывать и команда не получит всех плюсов этого процесса.
• Старшие разработчики рвьювят новых и младших разработчиков. Это создает плохую культуру в команде, а также не позволяет младшим разработчикам увидеть какие-то решения старших разработчиков, на которых они могли бы поучиться и узнать что-то новое.
• Не автоматизировать процесс ревью и не использовать сторонние инструменты для ревью. Никто не любит заниматься рутинными процессами. Нужно автоматизировать все, что можно автоматизировать.

На что обращать внимание во время Code Review

Чеклист для разработчика перед отправкой на ревью:

• Проверить, что реализация соответствует всем указанным в исходной задаче условиям
• Проверить соответствие Code Style и другим принятым в команде гайдлайнам, например, наличию unit-тестов и документации
• Протестировать задачу локально и убедиться, что она работает, как нужно
• Подготовить описание для ревьювера, если какой-то информации в задаче не хватает
• Проверить, нужны ли какие-то комментарии в самом коде и добавить при необходимости

Чеклист для ревьювера:

• Ознакомиться и понять цель и суть задачи
• Проверить общую архитектуру и подход к решению
• Проверить реализацию
• Проверить мелкие детали (имена функций и переменных и т.д.)
• Проверить наличие тестов и документации по необходимости

• Список ToDo: изменения, которые необходимо внести в код после ревью
• Вопросы: обозначить свои вопросы по частям кода, которые непонятны после ревью
• Предложения по улучшению: внести свои предложения и пожелания по коду задачи и/или связанных задач. Например, договориться о создании задачи по обновлению старого метода в других участках кода на новый и завести на это ToDo и задачу в трекере задач и поставить ее в тех. долг команды.

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

Инструменты для Code Review

Поищите инструменты для вашего языка программирования. Используйте тот, который больше всего подойдет вашей команде.

• GitHub Code Review https://github.com/features/code-review/
• Upsource https://www.jetbrains.com/ru-ru/upsource/
• Crucible https://www.atlassian.com/ru/software/crucible
• Collaborator https://smartbear.com/product/collaborator/overview/
• Beanstalk https://beanstalkapp.com/

• код ревью
• code review
• процессы разработки