RU

Багтрекер для разработки ПО

Рассмотрим ситуацию: существует компания, занимающаяся разработкой программного обеспечения (ПО). Для формализации бизнес-процесса нужно определить:

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

 1. Организационная структура

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


2. Роли участников

Роли участников

3. Список статусов

Список статусов

4. Описание бизнес-процесса

Бизнес-процесс

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

Бизнес-процесс для Багтрекера выглядит следующим образом:

  1. Клиент (разработчик, тестировщик или любой другой пользователь), обнаружив ошибку в ПО, создает заявку в статусе «Открыта».
    1. Разработчик получает уведомление. Далее он сам берет заявку на себя. Он может как перевести заявку в статус «В работе», так и потребовать у заявителя дополнительной информации, переведя заявку в статус «Требует уточнения» (заявителю придет уведомление). Заявитель, предоставив дополнительную информацию (комментарии, файлы), нажимает на кнопку «Вернуть в работу» и заявка возвращается в статус «Открыто».
    2. Если в ходе работы снова возникают вопросы, то аналогичным образом можно добавить комментарии и снова перевести в статус «Требует уточнения».
  2. Закончив работу над заявкой, разработчик переводит ее в статус «Выполнена». Тестировщик и Заявитель получают уведомления.
  3. Тестировщик, получив уведомление, проверяет, устранена ли ошибка (выполнена доработка):
    • Переводит заявку в статус «В работе» с добавлением комментария для разработчика, если ошибка не устранена.
    • Переводит заявку в статус «Проверена», если ошибка устранена (доработка выполнена).
  4. Далее возможны 2 варианта:
    • Тестирование работ по заявке сначала производится на тестовом сервере с последующим выносом изменений на продуктивный сервер. В этом случае перевод Заявки в статус «Закрыто» может быть выполнен менеджером при переносе очередных доработок, соответствующих этой заявке с тестового сервера на продуктивный.
    • Тестирование работ по заявке производится клиентом сразу на продуктивном сервере. После выноса изменений на продуктивный сервер менеджер переводит заявку в статус «Выполнена», ожидая от клиента проверки и подтверждения работ путем перевода заявки в статус «Закрыта». В этом случае можно предоставить клиенту на подтверждение заявки какое-то время, например 24 часа, по истечении которых заявка будет автоматически переведена в статус «Закрыта» в случае, если за отведенное время клиент сам этого не сделал.

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

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


Сервисная модель

Сервисы служат для логического объединения заявок в независимые группы. Если у вас несколько проектов по разработке ПО, например, «Разработка игры №1», «Разработка игры №2», то сервисами будут именно эти проекты. На разных сервисах могут быть разные Пользователи, разные бизнес-процессы, разные уведомления, разные сроки работ по заявкам и так далее.

Кроме того, у Сервиса есть понятие, как Этапы. При разработке ПО под этапами понимаются версии ПО. Этапы удобно использовать для того, чтобы определить, какие заявки на доработки или исправление ошибок наиболее критичны и должны быть отработаны в первую очередь. Менее критичные заявки откладываются на более поздние этапы развития ПО. Например, текущая версия ПО – 1.01 и существуют 3 этапа развития: Релиз 1.02, Релиз 1.03 и релиз 1.04.

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


Детализация

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

Пример email-уведомления:

Email

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

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

Список заявок:

Tickets

На списке заявок Исполнитель, Тестировщик или Менеджер, не заходя на карточку заявки, подведя курсор к наименованию заявки, может узнать следующую информацию: Тема заявки, Описание заявки, имя Заявителя, срок выполнения, последний комментарий.

Карточка заявки:

Tickets

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

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

История изменений Заявки:

Tickets

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

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


Фильтры

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

Для тестировщика:

Тестировщик, заведя несколько заявок, может создать фильтр «Мои в работе», чтобы иметь возможность отобрать только те свои заявки, которые приняты в работу Разработчиками. Настройки фильтра будут следующие:

Фильтры Тестировщика

Результат выполнения фильтра покажет Тестировщику только те созданные им заявки, которые были приняты в работу Разработчиками (статус «В процессе»):

Результат фильтра Тестировщика

Для исполнителя:

Для Исполнителя можно создать фильтр «Мои проверенные», применение которого выведет Исполнителю список тех его заявок, которые проверены Тестировщиком.

Настройки такого фильтра будут следующие:

Фильтры Исполнителя

Результат выполнения фильтра покажет Исполнителю те отработанные им заявки, которые проверил Тестировщик:

Результат фильтра Исполнителя

Для менеджера:

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

Менеджер создает для себя фильтр «Релиз 1.02 открыто» со следующими параметрами:

Фильтры Менеджера

Применение фильтра покажет Менеджеру список заявок, открытых на Релиз 1.02:

Результат фильтра Менеджера

Как мы видим, в работу над Релизом 1.02 пока еще не взята одна заявка.


Вложение скриншотов из буфера обмена

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

Кнопка добавления скриншота доступна на карточке заявки в браузере IE:

Скриншоты в IE

Single Sign On или доменная авторизация.

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

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

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


Попробуйте смоделировать работу багтрекера сами на нашей демо-площадке?

Демо-версия