Тикеты - esdp-2016-Team3/StepToUniverse GitHub Wiki

Как оформлять тикет:

Заголовок - краткое, лаконичное, емкое описание задачи

Описание:

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

Правила создания

Тикет нужно создавать с заботой о читателе. Если вы создали тикет, перечитайте, все ли понятно? Если есть недочеты - исправьте их, пусть читателю будет понятно.

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

Если тикет был закрыт и не описан — не проблема, закрытый тикет тоже можно отредактировать и наполнить содержанием.

Ссылки на источник требований

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

  • требованием изначального договора (смета, ТЗ) — тогда надо указать пункт требований (и документ, и где его взять, если непонятно, где он),
  • требованием клиента, выраженного в Скайпе или переписке — в этом случае слова клиента надо скопировать в тикет (см. описание ниже),
  • требование руководителя проекта или руководителя команды — надо об этом явно написать "Косяков сказал, что номер версии должен быть только одним числом"
  • рекомендацией стороннего эксперта или коллеги - надо написать об этом явно, например: "Вася Алферов <​[email protected]> говорит, что Докер-контейнеры должны содержать не более одной службы, так у Докеров заведено",
  • рекомендацией статьи в интернете — обязательно привести ссылку (URL) на статью (например: Сделать номер версии согласно ​http://semver.org/).

Цитирование слов клиента (или стороннего эксперта) удобней делать в виде комментариев к тикету, на которые из тела тикета можно сделать ссылку (типа "см. коммент. ниже"). Если же все требования тикета можно понять из текста, то имеет смысл вставить весь участок чата или письма в тело тикета. Обязательно должно быть понять, взято требование из чата, из какого чата, или из кокаго письмо, какого числа.

Особенности типов тикетов

Дефекты, тип defect

Для создания дефекта нужно обязательно указать:

  • шаги воспроизведения
  • наблюдаемое поведение
  • ожидаемое поведение
  • экземпляр (версия ПО, окружение) котором был обнаружен дефект
  • сценарий тестирования

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

Пример

№312 - Пользователь автоматически не авторизуется после регистрации

Шаги воспроизведения

Захожу на главную страницу Нажимаю на кнопку "Регистрация" Ввожу данные в поля: Email, Пароль, Дата рождения. Нажима на кнопку "Зарегистрироваться" Наблюдаемое поведение Перекидывает на главную страницу но видно что пользователь не авторизован. Также когда перехожу по ссылке только для зарегистрированных пользователей, то перекидывает на страницу авторизации и регистрации. Ожидаемое поведение Пользотель должен видеть свой профиль если регистрация прошла успешно.

Экземпляр демка, версия 1.0.1.565

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

Вариант решения Нужно добавить вызов функции авторизации

Задача, тип task

Для создания тикета на задачу нужно обязательно указать следующие пункты:

  • Конечный результат, План решения (Что нужно сделать, Как это сделать)
  • Мотивация (Зачем это нужно потребителю)
  • Критерии приемки
  • Улучшения, тип enhancement

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

Нужно описать предлагаемое решение проблемы.

Пример

№123 Улучшение пополния счета пользователя

Проблема Сложно пополнить счет пользователя.

его пополнить можно только зная номер пользователя (требование заказчика) номер пользователя в профиле пользователя не отображается номер пользователя в админке не отображается — можно только в списке пользователей найти или в URL Решение

В профиль пользователя добавить номер пользователя (чтобы он его видел и знал) В списке пользователя в админке добавить ссылку на страницу пополнения баланса, которая бы заполняла бы поле used_id (добавляла бы ?user_id=...)

Взятие тикета в работу

Определить мотивацию, ответить на вопросы:

  • для чего делать тикет,
  • в чем его смысл,
  • кому он облегчает жизнь,
  • какую пользу он приносит?
  • Определить критерии готовности, если не определены
  • Составить план работ
  • Сделать оценку и указать Time Planned

Приостановка работ над тикетом

Если работа над тикетом приостановлена по факту, то тикету нужно присвоить статус idle и написать причины приостановки. Когда работа будет возобновлена, тикет нужно вернуть в работу или закрыть, если тикет признан утратившим актуальность.

Статус invalid

Устанавливается, если цели тикета не соответствуют целям проекта, тикет устарел, или был ошибочно создан.

При закрытии необходимо указать причину

Статус worksforme

Устанавливается, для тикета типа дефект, если описанное поведение не удается воспроизвести.

При закрытии необходимо указать причину

Статус wontfix

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

При закрытии необходимо указать причину

Статус duplicate

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

Если у оригинала описание более слабое чем у дубликата, то дополнить его подробностями из дубликата.

  • В поле Time Spent указать 0
  • В комментарии указать ссылку на оригинал.
  • В поле milestone выбрать пустое значение (чтобы дубликат не фигурировал в майлстоуне)

Оценка тикета

В оценке главное — не облажаться. Недооцените - просрете сроки. Переоцените - потеряете доверие. Чтобы провести оценку, нужно четко ответить себе на все три вопроса:

  1. какую проблему решает тикет? - цель.
  2. что конкретно нужно сделать? - план реализации.
  3. как проверить готовность? - пошаговый сценарий приемочного тестирования.

Если вы не знаете ответов, то прежде чем оценивать ответьте на приведенные вопросы.

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