Trаc для Тракта¶
- Table of contents
- Trаc для Тракта
Трак это комплексная система для поддержки процесса разработки и сопровождения ПО. Построенная на web-интерфесе, она обеспечивает доступ к хранимой информации из любого места, имеющего выход в Интернет.
Всю информацию о возможностях Трак можно прочесть в документации. Вот тут есть частичный русский перевод.
Общей для всей системы является система регистрации пользователей, позволяющая определить персональные возможности каждого пользователя.
Существует система почтовых уведомлений, для использования которой необходимо, зарегистрировавшись, один раз указать свой почтовый адрес в разделе Preferences.
Систему можно разделить на несколько основных частей.
Wiki¶
Wiki - это система простого и удобного редактирования web-старничек. Позволяет редактировать странички с любого места, использовать при редактирование форматирование - жирность, списки, заголовки разделов и пр.
Можно просматривать старое состояние страниц и ссылаться на него, вставлять в страницы картинки, ссылки на тикеты и другие объекты Трака. Кстати, описание тикета и комментарии к нему также допускают аналогичное форматирование.
В wiki главным параметром страницы является ее имя. Имя - это часть адреса странички после стандартного префикса, например:
support.digispot.ru/trac/wiki/page/*Name/With/Slash*
Именем странички в примере является Name/With/Slash. Как видно из примера, в имя может входит символ /. Имя странички должно содержать только латиницу!
Странички, отделенные в имени / рассматриваются как вложенные, по ним автоматически формируется возможность навигации к базовым страничкам.
Для редактирования содержимого страницы необходимо нажать кнопку* Edit this page *в правом нижнем углу любой страницы wiki.
Чтобы создать новую страничку необходимо просто набрать в адресной строке браузера ссылку на эту страницу. При наличии соответствующих прав доступа появится страничка с кнопкой Edit this page для этой страницы.
Оформление страниц¶
Для нормального автоматического формирования оглавлений необходимо соблюдать следующие правила
- Страница всегда начинается с заголовка Heading1. Это обязательно. По сути, это название страницы
- Все остальные подзаголовки идут по порядку вложенности 2,3 и т.д.
- При неаккуратном форматировании возникают пустые заголовки, в плоском тексте они видны так
Их надо находить и удалять, они мешают формированию оглавлений
Tickets (Тикеты)¶
Тикеты нужны в первую очередь разработчикам, тестерам и сотрудникам поддержки.
Тикет - это описание небольшого задания, которое необходимо выполнить ответственному за тикет человеку - владельцу (ticket owner) или информация о уже выполненной работе. В идеале все действия, совершаемые сотрудниками, должны сопровождаться созданием тикета.
Каждый тикет имеет уникальный номер, использующийся для идентификации тикета (id). Тикет может находится в одном из нескольких состояний (State).
* new- задача только поставлена
* assigned- задача принята к исполнению
* closed- работы завершены, результат указан в поле результата (Resolution)
* fixed- исправлено, сделано
* invalid- тикет поставлен неправильно, например, то, что посчитали ошибкой, оказалось некорректной настройкой и пр.
* wontfix- не будет исправлено. Например, ошибка есть, но ее можно обойти и сложно исправить, или предложенное улучшение программы не будет сделано.
* duplicate- данный тикет дублирует другой. Надо обязательно сослаться на оригинальный тикет.
* worksforme- "У меня - работает". Описанный баг не воспроизводится. Т.е. не удается повторить проблему.
* no_answer - тикет закрыт по причине длительного отсутствия ответа на запрос, без которого невозможно продолжить работу по тикету.
- reopened- тикет был закрыт, но потом был открыт заново, например, исправленный баг сохранился.
У тикета есть Тип (Type) который определяет смысл тикета. В нашем случае существуют:
- defect- дефект, баг в программе, неправильное поведение программы. Владельцами обычно являются разработчики, тикеты создают тестеры и сотрудники техподдержки, а также сами разработчики
- enhancement- улучшение, доработка. Конкретное описание улучшения поведения программы, расширения функциональности и т.д.
- support- задачи по техподдержке. Тикеты этого типа могут создаваться после общения с заказчиком, по результатам оказанной поддержки. Если в процессе поддержки выявлен баг или возникли пожелания по улучшения программы, то их необходимо оформить в виде отдельных тикетов, сославшись на низ в тикете поддержки.
- *task* - любое задание, не попадающее под остальные
- code_review- это задача по доработке исходного кода программы
- test - это задача по тестированию ПО
- idea- это некоторое соображение, идея, которую надо не забыть. Возможно, позже тикет станет *enhancement *или task. Не рекомендуется к использованию.
Основные правила работы с тикетами. Придерживайтесь их, это сильно облегчит работу других:
- Тикетами надо пользоваться. Создавайте новые и закрывайте повешенные на вса тикеты. Иначе это все не имеет смысла.
- Одна задача - один тикет. Не надо сваливать в один тикет несколько проблем, задач и пр. Такой тикет очень неудобно использовать. Часть задач может быть правильной, часть - нет, часть сделанной и т.д. В результате состояние тикета теряет смысл.
- Максимально описывайте тикет - укажите версию, заказчика, внесите ключевые слова, внятно опишите суть проблемы и способ ее повторения и т.д. Приложите к тикету аттачменты.
- Повторно используйте тикет. Если аналогичная проблема уже была - найдите старый закрытый тикет (Используйте запросы к тикетам или поиск) и повторно откройте его. История тикета поможет разработчику отследить всю историю проблемы. (А для поиска очень важно полное описание тикета).
- Комментируйте тикет - при смене состояния тикета обязательно напишите в комментариях, почему изменилось состояние тикета. При появлении новой информации, проблем, дочерних тикетов и пр - вносите это в комментарии к тикету или непосредственно в текст описания тикета - история сохранит его старое состояние.
- Изменяйте тикет только по делу. Любое изменение тикета приводит к почтовому уведомлению - лишние изменения приводят к лишним письмам. Поэтому пишите сразу внятно, грамотно, используйте средства проверки орфографии, для просмотра форматирования текста и ссылок используйте preview. Изменяйте тикет только если изменения действительно важны.
При планировании работы можно использовать этапы (Milestone - верстовой камень). Milestone это некоторый этап работы, с датой и описанием, к которому могут быть привязаны тикеты. У этапа тоже есть состояние выполнен/не выполнен. Посмотреть созданные этапы можно в разделе *Roadmap.
Как оформлять дефектные тикеты¶
Дефектные тикеты должны создаваться по описанному ниже шаблону.
Название тикета: краткое и внятное описание проблемы, не "проблема с джином".
В теле тикета:
Проявление: Как это выглядит для пользователя, на что пользователь обращает внимание, что доставляет ему неудобство. Может быть очень далеко от реальной проблемы.
Условия возникновения: Необходимые сопутствующие условия, без которых проблема не возникает: версии, режимы работы, нюансы настройки, выполняемые действия и пр. Если таковых нет - можно опустить. Обычно в виде списка, тут же можно указать версию или поколение.
Причина: Что на самом деле происходит и каким образом оно вызывает указанные выше проявления. Чистая правда.
Способ обхода: Если есть, то как избежать проявления проблемы или ослабить ее негативный эффект до исправления разработчиками.
Способ устранения: Если есть, то как можно самостоятельно исправить проблему.
Комментарий: В конце можно добавить комментарий на тему данной проблемы.
