gistfile1.md

Общие требования ¶

Создание тикета ¶

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

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

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

Обязательно указывать при создании тикета ¶

• Описание тикета
• Майлстоун (Milestone) (если нет подходящего майлстоуна нужно создать)
• Версию (Version) (если непонятно в какой версии, по-умолчанию указать текущую версию)

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

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

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

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

Примеры:

Цитата из чата:

07 января 2015 года клиент пишет о общем чате:

[11:05:26] Представитель команды: Всем привет
В iAuto поддержан функционал ватермарок для изображений.
На текущий момент стоят ватермарки worksforweb.
У вас есть пожелания к этому функционалу? или он вами использоваться не будет?
[11:06:30] Заказчик: Привет, с рождеством!
[11:06:46] Представитель команды: С рождеством!
[11:13:01] Заказчик:  Привет, С рождеством! Данный функционал будет использоваться. Но пока мы не будем ее активировать в админ панели...
                    

Цитата из почты:

On 11.12.2015 21:40, Customer wrote:

If I click on BSS app it says BSS Beta has expired. If I go to test flight it ask if I want to renew. When I press that it says could not install Backflow Software solutions . the app couldn’t be installed because the profile has expired. Try again.

Требование к оформлению ссылок на клиента становится особенно важным, когда клиент просит внести изменения в уже согласованную или разработанную программную функцию.

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

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

Название должно отображать только суть проблемы, ее наблюдаемое проявление, например:

• На странице мои финансы 500 ошибка
• Не отправляется СМС при ...
• Не смог залогиниться ...
• Опечатки на странице ...
• Съехала верстка в ...

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

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

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

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

Пример ¶

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

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

1. Захожу на главную страницу
2. Нажимаю на кнопку "Регистрация"
3. Ввожу данные в поля: Email, Пароль, Дата рождения.
4. Нажима на кнопку "Зарегистрироваться"

Наблюдаемое поведение ¶

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

Ожидаемое поведение ¶

Пользотель должен видеть свой профиль если регистрация прошла успешно.

Экземпляр ¶

демка, версия 1.0.1.565

Причины ¶

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

Вариант решения ¶

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

Тесты ¶

  Допустим анонимный пользователь перешел на страницу регистрации И вводит данные в форму регистрации:
 |поле | значение |  |Email | some@email.com |  |Пароль | 123123123 |  |Дата рождения | 1987-10-02 |  Если пользователь нажимает на кнопку Зарегистрироваться То видит свой профиль 

Задача, тип task ¶

Название должно содержать суть задачи, что нужно сделать. Начинатся на глагол: добавить, удалить, отключить, применить, и т.д.

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

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

Улучшения, тип enhancement ¶

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

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

Пример: ¶

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

Проблема ¶

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

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

Решение ¶

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

Как переоткрыть тикет из за обнаруженного дефекта ¶

Функция переоткрытия тикета отключена. Используйте инструкцию Как описать дефект к существующему тикету

Как описать дефект к существующему тикету ¶

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

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

• описать проблему,
• описать дефект (баг),
• предложить улучшение

Чтобы описать дефект к тикету воспользуйтесь ссылкой "описать дефект (баг)", откроется окно создания тикета и следуйте инстркуциям Как создать новый дефект

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

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

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

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

Закрытие тикета ¶

Статус fixed,completed ¶

Перед закрытием тикета со статусом fixed или completed, все артефакты должны быть опубликованы (комиты в репо команды, статьи в трак, и т.д.) Все критерии готовности должны быть выполнены.

• Указать TimeSpent?
• Написать план-фактный отчет, если TimeSpent? больше TimePlanned?, более чем на 15%
• Привести описание тикета в соответствии с реализацией, так чтобы не было противоречий.
• Сделать записи о проделанной работе:
  • указать все комиты имеющие отношение к тикету
  • указать гиперссылки на созданные викистраницы и гуглдоксы
  • указать ссылки на прочие артефакты созданные в рамках тикета
• Написать план-фактный очтет, если применимо
• Указать информацию специфичную для типа тикета:

для типа тикета defect ¶

• Выбрать статус fixed
• Обязатьльно описать причину дефекта
• Обязательно описать решение

для типа тикета task, enhacenent ¶

• Выбрать статус completed
• Написать пояснительную информацию в раздел == Результат ==, если применимо

Статус invalid ¶

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

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

Статус worksforme ¶

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

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

Статус wontfix ¶

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

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

Статус duplicate ¶

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

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

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

Критерии готовности тикета ¶

еще не написал

План работ по тикету ¶

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

План-фактный отчет ¶

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

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

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

Чеклист оценки программной функции ¶

В нашем проекте чеклист представлени в виде формы TicketEstimationChecklistForm, которая встроена в шаблон всех типов тикетов посредством макроса [[Include(TicketEstimationChecklistForm)]]. Порядок использования чеклиста таков:

• создаете тикет
• заполняете форму чеклиста значениями оценки
• нажимаете update form
• суммируете оценку
• записываете в поле Time Planned
• Нажимаете Submit changes

В текущей версии отсутствует функциональность по суммированию оценки и сохранению ее в поле time_planned, поэтому суммировать и сохранять оценку нужно оценщику тикета.