Настоящий IT-шник всегда любит сварить «кашу из топора». А если этой кашей еще и получается вкусно накормить коллег, то выходит вообще замечательно.
По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.
С этой темой я уже выступал на конференции SQADays, но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.
Смысл?
Итак, для чего вообще может понадобиться нестандартно использовать баг-трекер? Причины для этого могут быть две:
- Банальная экономия средств. Хотя обычно рядовые сотрудники не привыкли задаваться таким вопросом, он все-таки имеет место быть.
- Попытки нестандартного применения того или иного инструмента (даже неудачные) позволяют лучше изучить этот инструмент и эффективнее его использовать для повседневных задач.
Disclaimer
Примеры, которые пойдут дальше, взяты из реальной жизни. Но успешное внедрение у кого-угодно никак не означает, что и у вас все пойдет как по маслу. Не забывайте думать, пробовать и советоваться со старшими товарищами.
Ну и сразу попрошу прощения, что частенько упор пойдет на использование JIRA (можете кинуть в меня помидор), т.к. эту систему я использую на повседневной основе, но и другие баг-трекеры не были забыты — практически все нижеописанное можно сделать и с их помощью.
Поехали!
HelpDesk
Наиболее частым, не совсем стандартным, применением баг-трекера, которое мне приходилось наблюдать, было использование его в качестве HelpDesk-а в службе технической поддержки.
Из плюсов такого применения можно отметить удобство связывания обращений в HelpDesk и багов, по ним заведенных (интеграции с HelpDesk-ами с каждым днем хорошеют, но идеала все нет), и отсутствие необходимости учить техподдержку работать с двумя системами. Но нужно понимать, что такая система будет чуть менее удобна, чем отдельный HelpDesk, и если вам приходится работать с большим количеством обращений, большинство из которых решается службой поддержки самостоятельно, то лучше смотреть на отдельную HelpDesk-систему.
Ближе к делу. Как такую систему можно настроить?
Сначала требуется обеспечить возможность приема обращений по email. Благо многие баг-трекеры умеют создавать заявки из электронных писем:
- Для JIRA это существующие Mail Handlers и замечательный плагин Jira Enterprise Mail Handler(который, начиная с JIRA 5, стал платным).
- Для Mantis — EmailReporting Plugin
- Для Bugzilla скрипт email_in.pl
Использование этих плагинов/обработчиков позволяет парсить письма, сохранять тему письма в теме созданной заявки, аттачить вложения из письма к заявке, привязывать ответные сообщения к соответствующим заявкам.
Но даже если вы не планируете разворачивать у себя HelpDesk, попробуйте использовать создание и комментирование заявок через email в повседневной работе. Некоторые находят это очень удобным.
Дальше нужно обеспечить принятие заявок через веб. Обычно в баг-трекере можно:
- Сильно урезать права клиентов, чтобы они видели только свои заявки и не могли копаться в вашей внутренней кухне.
- Открыть самостоятельную регистрацию, если у вас свободно продается коробочный продукт или сервис и новые клиенты могут появиться в любой момент.
- Включить возможность анонимного создания заявок, без регистрации пользователей. Особенно полезно, если у вас коммерческий баг-трекер, стоимость лицензии которого зависит от числа пользователей в системе.
Для JIRA отдельно стоит отметить плагин Issue Collector, который позволяет настроить удобные формы обратной связи для последующего размещения у себя на сайте.
К сожалению, плагин еще сыроват и не во всех случаях может надежно работать.
Наличие службы поддержки обычно подразумевает и наличие SLA (Service Level Agreement), по которому вы обязаны решать инциденты за строго определенное время. А для искоренения забывчивости администраторы, с подачи руководства, настраивают всякие напоминалки:
- Для JIRA можно применить относительно простое решение на базе периодически срабатывающего сервиса и Jelly-скрипта, который и будет делать всю черновую работу. Ну а если знаний хватает, то сервис может быть написан на Java и иметь нетривиальную логику.
- В bugzilla есть функция Whinning.
- А для Mantis тоже есть плагины и скрипты
Бюрократия
Согласования, отфутболивания, заявки, многоуровневые иерархии сотрудников, что может быть лучше… для автоматизации? На самом деле, автоматизация каких-то бюрократических моментов организации, если и не помогает сделать их проще, то уж прозрачнее так точно делает.
Доводилось видеть баг-трекеры, с помощью которых делали согласование закупок оборудования, отслеживание бюджета проекта, работу с документами и т.п.
В основе такой кастомизации обычно лежит создание своего Workflow — жизненного цикла заявки. Т.е. какие состояния у заявки есть и какие переходы могут быть между ними. Кроме того, благодаря настройке прав доступа отдельные переходы можно разрешить только для специально обученных ответственных товарищей.
- JIRA имеет даже два редактора Workflow — удобный и красивый :) С версии 5.0 красивый графический стал основным, но и до старого редактора можно докопаться. А workflow, приведенный выше, из JIRA и был скопирован.
- Bugzilla изначально имела фиксированный жизненный цикл заявки, но с версии 3.2 его можно "подкрутить"
- В Mantis нужно немного покопаться в коде
- А в Redmine все сделано в виде таблички
Помогает создание своего workflow и в ежедневной рутине разработчика. Например, могут быть введены новые промежуточные состояния для задач вроде «в тестировании» или «идет приемка заказчиком».
Использование своего workflow обычно неразрывно идет с созданием так называемых custom fields и новых типов заявок. Custom fields могут помочь в хранении любой дополнительной информации:
- Клиент, для которого делается фича
- Тестировщик, который её тестирует
- Промежуточный срок, когда должно быть проведено демо внутри команды
Новые типы заявок (например, «согласование документа», «закупка», «проектирование» или «тестирование») позволяют не только сделать процесс работы более наглядным, но и привязать к каждому типу заявки отдельный Workflow. Так если для задачи «разработка» имеет смысл ввести состояние «тестирование» в жизненном цикле, то для задачи «дизайн» такое может и не понадобится.
Почтовые рассылки
Баг-трекер это не только ценный инструмент, но обычно и система почтовых нотификаций, в него встроенных. И эти нотификации можно использовать себе во благо для создания почтовых рассылок внутри организации. Рецепт прост:
- Создаем отдельный проект «для рассылок»
- Внутри проекта заводим по одной заявке на каждую тему рассылок. Например, «График работы столовой» или «Вниманию автомобилистов офиса».
- В зависимости от градуса бюрократии определенные люди/группы либо принудительно вписываются в список получателей нотификаций, либо сами могут стать watсher-ами (теми, кто получает уведомления по заявке) самостоятельно.
- При добавлении нового комментария к заявке его текст отправляется нужным людям.
Дележ ресурсов
Вам определенно следует позаботиться о контроле за ресурсами, если одни и те же сервера часто одновременно используются для различных нагрузочных тестов, либо два сотрудника одновременно пытаются забрать один и тот же iPad в командировку для демонстрации.
Воспитывать совесть у коллег с помощью баг-трекера сложно, но повысить уровень организации можно. Рецепт:
- Для каждого ресурса, который может быть одновременно использован только одним сотрудником (сервер, автомобиль, демонстрационный iPad) заводится по одной заявке. Например «Занятость сервера LOAD-02».
- Настраивается простой Workflow из состояний «свободен» и «занят».
- Когда человек переводит заявку из состояния «свободен» в «занят», это означает, что ресурс он забрал себе. При этом заявка автоматически на него назначается, чтобы любой желающий мог видеть, у кого сейчас ресурс. Полезно бывает настроить при этом и почтовые нотификации.
- Право обратного перехода обычно есть только у того, кто ресурс забрал или у администратора.
- Сюда же можно прикрутить напоминалку (смотри выше про SLA), которая через пару дней уточнит, а нужен ли до сих пор этот ресурс.
Естественно, никто не может запретить человеку забрать ресурс и «не отметиться в системе», но с помощью доброго слова и удобного инструмента можно сделать больше, чем с помощью одного доброго слова.
Голосования
Довольно распространенную функцию голосования за реализацию тех или иных заявок тоже можно использовать себе на благо. Если вы задались вопросом «куда пойти на корпоратив» или «что подарить директору на день рождения», то можете смело использовать баг-трекер (убедитесь только, что директор им не пользуется :). Рецепт:
- Создается проект для голосований
- При каждом новом голосовании создается версия проекта
- Создаются заявки-варианты и назначаются на эту фиктивную версию
- Люди голосуют
- По истечении времени заявки закрываются (чтобы нельзя было больше голосовать)
- И строится отчет по версии с сортировкой заявок по убыванию голосов
JIRA и Bugzilla имеют встроенную функцию для голосований. Для Redmine есть плагин.
Тест-менеджмент
Есть любители использовать баг-трекер в качестве системы для хранения набора регресcионных тестов, которые нужно выполнять вручную на каждой очередной версии продукта. Сам я не фанат такого способа, но раз люди используют, то что-то в этом есть. Рецепт:
- Создается новый тип заявки «Тест».
- Для такого типа заявки добавляются кастомные поля «Шаги выполнения» и «Ожидаемый результат» (можно и в одно поле, но классики тестирования негодуют).
- Создается подзадача «Выполнение теста», у которой будут состояния «Тест не выполнялся», «Тест пройден», «Тест не пройден» и «Тест невозможно выполнить».
- Если тест планируется провести на версии X.Y, то у него создается подзадача, которая на эту версию и назначается.
- После проведения тестирования, подзадача переводится в нужное состояние.
- Дальше можно строить всякие отчеты по подзадачам «Выполнение теста», чтобы понять, на каком свете проект.
Плюсы такого решения: очень удобно из тестов ссылаться на заявки/баги в баг-трекере, нельзя закрыть версию, в которой есть «незакрытые» тесты. В целом может быть не так удобно, как специализированная система для тест-менеджмента.
Технические возможности расширения
Кроме возможностей по настройке баг-трекеров (а все предыдущие рецепты по сути настройки) часто есть возможность расширить функциональность баг-трекера и программно.
Все основные баг-трекеры имеют интерфейсы для удаленного доступа, которые можно использовать для какой-то своей автоматизации. Например, автоматически постить заявки по каким-то событиями или из внешних систем.
- JIRA: REST, SOAP, XML/JSON-RPC
- Mantis: MantisConnect SOAP
- Redmine: REST
- Bugzulla: XML/JSON-RPC
Кто не хочет заморачиваться с программированием, может использовать для автоматизации клиенты командной строки:
Для разжигания холиваров скажу, что самый развитый клиент у JIRA :)
Ну а если вам вообще ничего не хочется делать самому, то стоит поискать уже готовые плагины для своего баг-трекера:
- JIRA: более 400 плагинов (в том числе и платные), пишутся на Java
- Redmine: более 230 плагинов, пишутся на Ruby
- Trac: около 50 плагинов на Python
- Mantis: чуть более 25 плагинов на PHP
Опять-таки здесь JIRA впереди планеты всей. В основном благодаря экосистеме для разработчиков плагинов, которая при должном уровне подготовки позволяет очень здорово кастомизировать поведение JIRA и добавлять всякие «полезности» и «свистелки».
Итоги
Пару мыслей, которые я хотел донести до слушателей на SQADays и до читателей на Хабре:
- Знай практически все, что умеет твой баг-трекер (читай «любой инструмент»).
- Учись администрировать и программировать, либо дружи с коллегами, которые умеют это делать. Их помощь пригодится.
А в комментариях буду рад увидеть какие-то нестандартные использования баг-трекеров, которые попадались Хаброжителям.
Спасибо!
Автор: cr0ck
