Не баг-трекер, а…

    Настоящий IT-шник всегда любит сварить «кашу из топора». А если этой кашей еще и получается вкусно накормить коллег, то выходит вообще замечательно.

    По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.



    С этой темой я уже выступал на конференции SQADays, но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.



    Смысл?


    Итак, для чего вообще может понадобиться нестандартно использовать баг-трекер? Причины для этого могут быть две:
    • Банальная экономия средств. Хотя обычно рядовые сотрудники не привыкли задаваться таким вопросом, он все-таки имеет место быть.
    • Попытки нестандартного применения того или иного инструмента (даже неудачные) позволяют лучше изучить этот инструмент и эффективнее его использовать для повседневных задач.


    Disclaimer


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

    Ну и сразу попрошу прощения, что частенько упор пойдет на использование JIRA (можете кинуть в меня помидор), т.к. эту систему я использую на повседневной основе, но и другие баг-трекеры не были забыты — практически все нижеописанное можно сделать и с их помощью.

    Поехали!



    HelpDesk


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



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

    Ближе к делу. Как такую систему можно настроить?

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


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

    Но даже если вы не планируете разворачивать у себя 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 :)

    Ну а если вам вообще ничего не хочется делать самому, то стоит поискать уже готовые плагины для своего баг-трекера:


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

    Итоги


    Пару мыслей, которые я хотел донести до слушателей на SQADays и до читателей на Хабре:

    • Знай практически все, что умеет твой баг-трекер (читай «любой инструмент»).
    • Учись администрировать и программировать, либо дружи с коллегами, которые умеют это делать. Их помощь пригодится.


    А в комментариях буду рад увидеть какие-то нестандартные использования баг-трекеров, которые попадались Хаброжителям.

    Спасибо!
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 29

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Насколько я помню свой опыт общения с OTRS 2.x, то служба поддержки вникала в неё серьезно дольше чем в использование той же JIRA, хотя не скажу, что у JIRA очень уж простой интерфейс. Плюс не было никакой интеграции с багтрекером.

        Искренне надеюсь, что в 3-й версии с интерфейсом и интеграцией стало получше.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Ну видимо у нас своя специфика была. Простых сотрудников поддержки, «исполнителей», которые только смотрели в свой список задач, не было. Одни и те же люди работали сразу над несколькими проектами, занимались уточнением приоритетов и, если нужно, «раскидыванием по очередям», а так же администрированием OTRS.

            Т.е. как я и предупредил в начале — универсальных решений не бывает :)
              0
              OTRS нацелен на крупные команды (суппорт хостинга), администраторы, first/second line support и даже вовсе на других сотрудников. Тут не необходимость использования, а поиск подходящего «не универсального решения», по-скольку все решения в каком-то роде не универсальны.
              OTRS лучше и удобнее использовать когда:
              1. Вы вообще не хотите знать ни о каких интерфейсах, а просто выслать письмо с проблемой.
              2. Для всех реквестов вы хотите использовать единую точку входа, например, support@mycompany.com
              3. У вас большой штат обслуживающего персонала (не только админы) по разным направлениям и вы хотите, чтоб нужные запросы автоматом попадали к нужным людям (очереди, которые кстати автоматизируются, чтоб их не раскидывать вручную)
              4. Чтобы это всё трекалось по времени, SLA, исполнители вовремя уведомлялись о сроках, менеджеры знали о состоянии дел.

              Примеры:
              «у меня не работает мышка/принтер/клавиатура/монитор» и прочая мелочь попадает в очередь к эникейщикам
              «Выход нового сотрудника» попадает в очереди к hr и админам
              «Сгорел датацентр/упали сервера» попадают в очереди к совершенно другим админам
              И всё это автоматически.

              На больших предприятиях это даёт серьёзных выигрыш. Но в настройку системы придётся окунуться с головой. На малых предприятиях — это может быть накладно и вовсе невыгодно.

              Кстати, jira из коробки тоже относительно мало чего умеет в этом плане. Она больше заточена сразу под разработку ПО.
                0
                Согласен, спорить не буду. Мы использовали OTRS для небольшой кросс-функциональной команды.

                Насчет автоматического раскидывания по очередям тоже согласен, есть такое. Но иногда приходят письма вида «а-а-а-а, ничего не работает» от клиентов, с которыми ведется несколько проектов. И в какую очередь положить, приходится выяснять глазами и телефоном :)

                Ну и в качестве ремарки, читал как-то про команду, которая использовала OTRS именно для баг-трекинга (и внутреннего тоже). Так что все относительно.
                  0
                  В стеке Atlassian это к JIRA Service Desk (https://www.atlassian.com/software/jira/service-desk).
          0
          Интересно было бы посмотреть еще на то, что с помощью багтрекеров сделать нельзя?
          0
          У нас баг-трекер используется для учета оборудования. Удобно.
            0
            Расскажите подробнее как. Какая абстракция для единицы оборудования? Какие операции могут быть отражены в баг-трекере с оборудованием?
            +1
            Картинка к HelpDesk великолепна.
              0
              в JIRA мешает отсутствие вложенных проектов и вложенных задач (подзадачи есть, но они не могут в свою очередь быть вложенными). Существует ли от этого недуга какой-нибудь плагин?..
                0
                Есть хороший плагин, который эту проблему «лечит» — Structure. Но, как и многое хорошее в этом мире, он стоит денег.
                  0
                  В TrackStudio неограниченное количество уровней вложенности есть, причем задачи могут быть разных типов, иметь разные права и workflow.

                  Если сравнивать по тому функционалу, который описан в статье, то:
                  — прием почты от зарегистрированных/незарегистрированных пользователей тоже есть
                  — приема заявок через web из коробки нет, решается написанием своего интерфейса (это что-то вроде плагина, можно разные web-морды делать для разных пользователей)
                  — бюрократия есть. Графического редактора workflow нет, но в остальном гибче JIRA, подробности на сайте TrackStudio
                  — почтовые рассылки есть, аналогично JIRA
                  — Дележ ресурсов есть
                  — голосования из коробки нет, нужно скрипты писать
                  — тест-менеджмент есть
                  — API: SOAP и read-only REST, но готовых плагинов/скриптов мало (несколько десятков).

                    0
                    Максим, с TrackStudio, к сожалению, практически не сталкивался и ничего про неё в статье не написал. Поэтому, спасибо за дополнение.

                    Из интересных вопросов, хотя немного и не в тему. Планируется в TrackStudio делать какое-то взаимодействие с Continuous Integration системами? Или может уже есть какие-то решения?
                  0
                  Прямо из коробки нет, но можно реализовать скриптами (аналог плагинов в JIRA), по цене это будет не очень дорого, стоить несколько тысяч рублей.

                  Вообще из-за небольших размеров команды и community в TrackStudio интеграция «из коробки» с разными системами заметно хуже (есть разве что SVN/CVS/Perforce/Bazaar/Git, Google Calendar, вход через LDAP/NTLM/JOSSO/Crowd, экспорт в CSV/XML/MS Prokect, импорт из CSV, ну и REST + SOAP), для JIRA список куда длиннее.

                  Еще одно отличие JIRA от Redmine/TrackStudio: JIRA — это только трекер (для документов предполагается использовать Confluence), а в TrackStudio/Redmine есть возможность хранения документации. В TrackStudio еще есть макросы типа как Confluence, автосоставление оглавлений, оповещения при изменении документов, история изменений и прочие стандартные для таких систем вещи.
                    0
                    А где в TrackStudio возможность хранения документации? Полазил по сайту и не нашел такого.

                    В Redmine да, есть своя wiki-система, но, imho, Confluence на голову бьет любую другую wiki-систему в варианте для корпоративного использования, как по удобству, так и по функционалу. Другое дело, что не всем этот функционал нужен.
                      0
                      Посмотрите вот тут, вверху скриншоты
                      www.trackstudio.ru/whatsnew.html

                      По поводу функционала: в TrackStudio документы — это просто особый вариант представления задачи, они лежат в той же БД, они в дереве выводятся, задачи могут ссылаться на них (а из документов можно ссылаться на задачи, документы так же можно организовывать в дерево.

                      В TrackStudio есть макросы, на самом первом скриншоте на этих макросах дашборд нарисован (тоже документ), можно свои макросы писать и, например, графики выводить (описание есть в документации). Другое дело, что Confluence можно использовать как такую локальную социальную сеть, а в TrackStudio документы — это просто документы.

                        0
                        Ясно, вижу. Но это не полноценная wiki-система, а просто возможность хранить и редактировать документы. Кого-то определенно устроит и такое, но если работа над документами идет в команде, то лучше все-таки Confluence (и опционально SharePoint или Alfresco).
                          0
                          А чего именно не хватает? Картинки вставлять можно, история изменений есть…

                          Хотя в целом да, цели создать полноценную систему для работы с документами не было, более типичное применение — knowledge base.

                            0
                            Я, например, от wiki-системы ожидаю, как минимум, такие вещи (не знаю, есть ли они у вас):
                            — Возможность просмотра diff-ов между ревизиями страницы.
                            — Возможность комментировать/обсуждать страницы
                            — Экспорт страниц в разные форматы
                            — Мержинг одновременно отредактированных страниц или редактирование страниц по секциям. Чтобы люди могли работать над одной страницей одновременно.

                            Ну а Confluence, в частности, добавляет всякие плюшки вроде вставки картинок прямо из буфера обмена, присоединение файлов через drag-n-drop, ну и пачка социальных (и удобных) штук, про которые вы упоминали.
                              0
                              Да, понял. Есть частично:
                              1) Diff между ревизиями есть
                              2) Комментирование было, отрезали чтоб упростить интерфейс, если будет потребность — вернем. У нас для страницы можно создавать подзадачи и можно обсуждать исправления уже там.
                              3) Экспорт в PDF ожидается в следующей минорной версии, сейчас есть экспорт в CSV, XML
                              4) Мержинга нет.

                              Из прочего — вставка картинок из буфера у нас тоже есть, файлы через drag-n-drop можно присоединять к задачам, для документов пока не делали. А вот социальных штук в самом деле нет.
                    0
                    Баг-трекер это не только ценный инструмент, но обычно и система почтовых нотификаций

                    Бобёр это не только ценных мех…
                      0
                      А существует ли в Redmine поддержка SLA?
                        0
                        Отвечу сам себе — существует в виде платного, но очень простого плагина от easyredmine, и redminecrm тоже собирается выпустить нечто подобное.
                        0
                        У меня на Redmine уже 4 года база данных агенства недвижимости
                        image
                          0
                          Колонку телефон замазал, а телефоны в тексте номер замазать — смекалки не хватило?!

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

                            Да ужас просто, персональные данные, вот только эти телефоны взяты с авито и из газет, люди деньги платили, чтобы мир узнал их телефоны. Вы что в СМС им сказали? Ваш телефон zionkv опубликовал, злодей такой, не подавайте больше номер в газеты? Не говоря о том, что при продаже имущества люди часто покупают одноразовую симку, чтобы потом не мучали звонками.
                            В общем, мой вам совет: слезайте с лошади, снимайте латы и не грубите людям. А я все лишь человек, который не замазал пару номеров там, где их вообще не надо было замазывать, хотя, на остальных скриншотах с редмайном замазаны в обоих местах, видимо, год назад подумать не мог, что они пишут номера в комментарии. Спасибо за бдительность!

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

                        Самое читаемое