[Перевод] Как эффективно работать с тикетами (issues) на GitHub30.04.2020 14:33

Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.

Содержание:

Что такое тикет?

Для многих команд «тикет» — это общий термин, который может означать:

Запрос на реализацию фичи.
Отчёт об ошибке.
Жалобу клиента.
Оповещение системы безопасности.
Ретроспективу для команды.

Публичный или приватный?

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

Для публичных тикетов

Акцентируйте внимание на итоге.
Подчёркивайте, что можно сделать.
Не публикуйте конфиденциальную информацию.

Для приватных тикетов

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

Оценка

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

Оценка по приоритетности

Пример: Приоритетность 1 (сделать в первую очередь), Приоритетность 2 (сделать во вторую очередь), Приоритетность 3 (сделать в третью очередь) и т. д.
Аналогия: список дел, в котором Приоритетность 1 является главным приоритетом.
Достоинства: легко понять, в какой очерёдности команда будет выполнять задачи. Совместимо со многими системами отслеживания ошибок, приложениями для ведения списков дела и инструментами для управления задачами.
Не рекомендуется: некоторые команды используют Приоритетность 0 (P0), например, для обозначения экстренных ситуаций или помехи релиза.

Оценка по степени влияния

Пример: от Опасность 1 (минимальное влияние) до 5 (катастрофическое влияние).
Аналогия: возможные последствия ураганов оцениваются по шкале Саффира-Симпсона в диапазоне 1 (минимальный), 2 (умеренный), 3 (значительный), 4 (огромный), 5 (катастрофический).
Достоинства: легко понять с точки зрения влияния на бизнес. Хорошо подходит для цветового кодирования от зелёного до красного. Каждый может выставить оценку в соответствии со своей точкой зрения, без учёта приоритетности.
Не рекомендуется: некоторые команды переворачивают шкалу и используют диапазон от Опасность 0 (катастрофическое) до 5 (минимальное). Мы не рекомендуем так делать, потому что возникает диссонанс.

Оценка по степени ущерба

Пример: от Ущерба 1 (минимальный ущерб) до 10 (катастрофический ущерб).
Аналогия: шкала Рихтера оценивает ущерб от землетрясений в диапазоне от 1 (минимальные разрушения) до 10 (полные и необратимые разрушения).
Достоинства: легко понять с точки зрения влияния на клиентов. Можно использовать аналогии из реального мира. Хорошо подходит для кодирования по степени яркости в диапазоне от светлого до тёмного. Каждый может выставить оценку в соответствии со своей точкой зрения, без учёта приоритетности.

Оценка по размеру

Пример: по увеличению размера — «Маленькое», «Среднее», «Большое».
Аналогия: размеры одежды.
Достоинства: легко прикинуть, сколько потребуется сделать работы.

Оценка по критерию MoSCoW

Пример: MoSCoW — это мнемоническое сокращение от «must», «should», «could», «won’t». Фича «должна быть», «желательна», «может быть», «не будет».
Аналогия: любая беседа, посвящённая планированию, в ходе которой кто-то говорит: «Мы должны это сделать» или «Нам следует это сделать».
Достоинства: англоязычное кодирование категорий помогает говорить о тикетах с заинтересованными лицами. Система широко используется специалистами по пользовательскому взаимодействию.
Примечание: мы предпочитаем использовать слово «would» вместо «won’t», потому что, исходя из нашего опыта, «would» говорит о том, что есть вероятность реализовать тикет в будущем, если что-нибудь изменится: «фича была бы реализована, если …».

Оценка по частоте

Пример: «Частота 1%» означает, что затронут 1% случаев, «Частота 100%» — затронуты все случаи.
Аналогия: частота возникновения чего-либо или повторения в течение заданного периода или в рассматриваемом образце.
Достоинства: позволяет оценить, насколько часто возникает проблема. Можно преобразовывать в оценки вроде »20 раз в день». Можно подытоживать в виде «всегда», «часто», «иногда», «редко», «никогда». Можно выражать в процентах: «Затронуто 80% случаев».

Совокупная оценка

Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.

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

Продавцы сначала задают тикету Приоритетность 1.
Продуктологи задают Опасность 1 (минимальное влияние), потому что опечатка тривиальна и не влияет на других клиентов.
Маркетологи задают Ущерб 3 (средний), потому что опечатка сказалась на предоплате.
Менеджер проекта задал «маленький» размер, потому что объём работ невелик.
Проектировщики задали MoSCoW «должна быть», потому что это необходимо исправить.
Команда по качеству задала Частоту 2%, потому что проверка выявила опечатки в 2% наименований клиентов.

Обсуждение оценок

Здесь приведены примеры обсуждения оценок тикетов.

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

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

— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.

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

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

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

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

— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).

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

Шаблон тикета

Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.

В нем могут использоваться:

Главный жалобщик: общая характеристика проблемы, данная столкнувшимся с ней человеком.
Участники: кто вовлечён в ситуацию — пользователи, сотрудники, партнёры, конкретные люди и т. д.
Симптомы: очевидные признаки проблемы — мнения пользователей, триггеры, оповещения и т. д.
История: вторичная информация, имеющая отношение к ситуации — аналогичные случаи, отчёты, ссылки и т. д.
Диагноз: что происходит под капотом — исходные причины или цепочки причин, и т. д.
Прогноз: оценка потенциальных последствий, изменений и т. д.
Переломы: потерянная информация, падающее приложение, заблокированный процесс и т. д.
Лечение: что мы делаем для улучшения ситуации — процедуры, списки дел, ограничения и т. д.

Файл с авторским шаблоном: TEMPLATE.md

Запуск постмортемов

Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.

Запустить разбор можно:

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

Безобвинительные постмортемы

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