Зачем клиенту багтрекер

Аватар пользователя neochief neochief 18 ноября 2009 в 4:32

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

Тезисы статьи могут показаться кому-то совсем уже очевидными, однако на моей памяти нет ни одного фрилансера, который имеет собственный багтрекер для обслуживания своих клиентов. Для мелких студий это вообще must-have, но и у них, бывает, что багтрекера попросту нет.

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

Зачем клиенту багтрекер »

P.S. Хотел вставить сюда весь пост, но он выглядел здесь слишком убого в стилях drupal.ru, поэтому, даю лишь ссылку на саму статью.

Комментарии

Аватар пользователя Splinter Splinter 18 ноября 2009 в 7:31

Если я правильно понял, то для этих целей подойдет Atrium. С появления Atrium стал задумываться что пора предлагать клиенту такие услуги.

Аватар пользователя sadmin sadmin 18 ноября 2009 в 8:33

Полезная тема. Традиционно, на друпал.ру мало обсуждалось (или я не заметил?) вопросов, посвященных подобным темам. Теперь дело исправилось, тут багтрекер, на баркемпе о тестировании услышим. Заживём однако

Аватар пользователя Химический Али Химический Али 18 ноября 2009 в 9:09

Сюда бы что-то типа багтрекера - запарился в трекере наблюдать мельтешащую плашку [решено] Smile Ведь по сути форум преимущественно и исполняет роль системы исполнения заявок, куда валятся людишки со своими проблемами, а другие их пытаются решить.

Тема полезная, однако уверен, что есть и другие решения Smile

Аватар пользователя Master of Tragedy Master of Tragedy 18 ноября 2009 в 9:12

"Химический Али" wrote:
запарился в трекере наблюдать мельтешащую плашку [решено]

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

Аватар пользователя VVS VVS 18 ноября 2009 в 9:43

добавлю трекер, который мы пользуемся: TrackStudio - мощное средство от соотечественников. Smile
Есть и бесплатный - ограничение только по количеству юзеров - для малой студии хватит.

Аватар пользователя yexel yexel 20 ноября 2009 в 4:56

Химический Али wrote:
Valeratal wrote:
дык модуль есть casetracker
на группах в друпал

И табличка для сравнения с другими тикет-хелпдесками: http://groups.drupal.org/node/17948[/quote]

А кто-нибудь пробовал какую-либо из этих систем на друпале?

Аватар пользователя kodo kodo 18 ноября 2009 в 10:50

Тема хорошая, для своих клиентов пытаюсь использовать Atrium. Почему только пытаюсь, потому что клиента хрен заставишь писать сообщение в багтреккинг, а не в привычный скайп, почту и телефон.
То ShvetsGroup Prefer English похоже пока не работает? (а вообще сайт понравился)
Александр, продолжай в том же духе, твои посты всегда интересны.

Аватар пользователя v1adimir v1adimir 18 ноября 2009 в 13:12

kodo wrote:
...потому что клиента хрен заставишь писать сообщение в багтреккинг, а не в привычный скайп, почту и телефон...

серьезные багртекеры имеют модули для коммита багов через e-mail. можно сделать занесение бага через jabber.

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

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

к слову для последнего вполне подходит Trac. советую! )

Аватар пользователя sadmin sadmin 18 ноября 2009 в 11:02

"kodo" wrote:
Почему только пытаюсь, потому что клиента хрен заставишь писать сообщение в багтреккинг, а не в привычный скайп, почту и телефон.

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

Аватар пользователя PVasili PVasili 18 ноября 2009 в 12:27

90-95% клиентов багтреккер не будут использовать. Мыло, тел, мессенджеры.
Единственное полезное применение - для команды разработчиков (территориально разнесённых) для совместной разработки систем уровнем выше среднего. Мантиса прижилась только с этого уровня ;).

Аватар пользователя v1adimir v1adimir 18 ноября 2009 в 13:01

Долгое время пользовали bugzilla -- это просто мега-монстр. Пробывали Mantis чем-то не покатил, уже не помню сейчас, что не устроило. Сейча перешли на Trac. Пока устраивает, в качестве плюса -- интеграция с SVN. Когда закрываешь баг можно сразу дать ссылку на ревизию в svn.

Аватар пользователя sadmin sadmin 18 ноября 2009 в 13:33

"v1adimir" wrote:
Долгое время пользовали bugzilla -- это просто мега-монстр. Пробывали Mantis чем-то не покатил, уже не помню сейчас, что не устроило. Сейча перешли на Trac.

Каковы причины перехода на Trac?

Аватар пользователя v1adimir v1adimir 18 ноября 2009 в 14:01

sadmin wrote:
"v1adimir" wrote:
Долгое время пользовали bugzilla -- это просто мега-монстр. Пробывали Mantis чем-то не покатил, уже не помню сейчас, что не устроило. Сейча перешли на Trac.

Каковы причины перехода на Trac?

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

Зато могу рассказать почему следующий выбор был за Trac
* Разумная комбинация возможностей и сложностей
* Возможность использовать для project management, т.е. не только для багов, но и для задач.
* Наличие встроенной Wiki-системы для ведения сопровождающей документации по проекту
* Интеграция с SVN, возможность постановки отчеты по багам/задачам ссылок на ревизии, простотр diff-ов он-лайн...
* Использование в качестве БД Postgresql
* Желание поэксперементировать с Python )

Аватар пользователя sadmin sadmin 18 ноября 2009 в 14:42

"v1adimir" wrote:
Интеграция с SVN

Для связывания с SVN нужно создавать соответствующий внешний сервер для контроля версий? И он должен синхронизироваться с внутренним, правильно понимаю?

Аватар пользователя v1adimir v1adimir 18 ноября 2009 в 15:04

sadmin wrote:
"v1adimir" wrote:
Интеграция с SVN

Для связывания с SVN нужно создавать соответствующий внешний сервер для контроля версий? И он должен синхронизироваться с внутренним, правильно понимаю?

для svn нет понятия сервер в явном виде, основным понятие является "репозиторий", доступ к которому может осуществляться через различные механизмы. в том числе и через apache web-dav.

но trac не умеет работать с репозиторием через web-dav. в текущей реализации доступ к репозиторию возможен только напрямую к файлам, через python-binding.

то есть svn репозиторий должен находиться на в той же системе что и trac.

синхронизировать svn-репозитории можно, по-моему, только в одном направлении.

Аватар пользователя cyberpunk cyberpunk 18 ноября 2009 в 16:39

Странно что никто не юзает Redmine (http://www.redmine.org/). Мы его уже больше года используем. Пользовались всем выше перечисленым, наш опыт: Mantis - старье, похожее на курсовую работу студента с интерфейсом в котором не разберется даже продвинутый заказчик. Trac - хорош, но не удобен тем, что для каждого отдельного проекта разворачивать надо отдельную копию Trac (про последние версии не уверен, но врядли там что то сильно поменялось, идеология не та) и интеграция с svn там не очень (выше уже заметили).

Аватар пользователя v1adimir v1adimir 18 ноября 2009 в 17:04

cyberpunk wrote:
...Trac - хорош, но не удобен тем, что для каждого отдельного проекта разворачивать надо отдельную копию
...и интеграция с svn там не очень.

Отдельная инсталяция Trac для отдельного проекта -- это преднамеренная фича. Ее удобство/неудобство зависит исключительно от настройки рабочего процесса в организации. Проект сделали, сдали, все данные заархивировали, про проект забыли. Где-то другие требования, но для монстрозных проектов, по-моему, bugzilla вне конкуренции.

А насчет интеграции svn в trac ты что-то напутал, так с этим все ОК.

Аватар пользователя cyberpunk cyberpunk 18 ноября 2009 в 17:53

v1adimir wrote:
cyberpunk wrote:
...Trac - хорош, но не удобен тем, что для каждого отдельного проекта разворачивать надо отдельную копию
...и интеграция с svn там не очень.

Отдельная инсталяция Trac для отдельного проекта -- это преднамеренная фича. Ее удобство/неудобство зависит исключительно от настройки рабочего процесса в организации. Проект сделали, сдали, все данные заархивировали, про проект забыли. Где-то другие требования, но для монстрозных проектов, по-моему, bugzilla вне конкуренции.

А насчет интеграции svn в trac ты что-то напутал, так с этим все ОК.


Ну мог и напутать, в принципе это субьективно моё мнение, мне в Redmine это кажется удобным.

Аватар пользователя Dan Dan 18 ноября 2009 в 17:59

"sadmin" wrote:
Это идея. Связать багтрекер с почтой, завязать аккаунты на людях и выставлять свой id как контакт, по которому можно связаться и следить за результатом.

В Атриуме можно завязать почту и багтрекер.

Аватар пользователя axel axel 18 ноября 2009 в 18:24

Клиенту нужен не багтрекер, а хелпдеск. Потому как ему хочется побыстрей сообщить о проблеме и совершенно нет интереса разбираться в специфике заполнения полей, предлагаемых багтрекерами. Пример: клиенты практически всегда присваивают проблеме максимальную важность - просто потому, что раз проблема возникла и мешает им работать, для них лично её решение важней всего. Либо оставляют непонятные поля по умолчанию, т.к сомневаются в их заполнении.

На мой взгляд идеальным является симбиоз хелпдеска с багтрекером. С "клиентской" стороны - хелпдеск, для которого важна простота интерфейса и возможность сбора сообщений из разных источников - из почты, с джаббера, в идеале туда же логи телефонных звонков. Клиент пишет, получает ответ, что запрос получен - на какое-то время он успокаивается, т.к. ему важно вначале удостовериться что проблему он донёс до разработчиков. На "программерской" стороне стоит полноценный багтрекер, где разработчики рассматривают пришедшие запросы из хелпдеска и сами формируют по ним задачи. Например десяток пришедших в хелпдеск запросов вполне может оказаться принадлежащими одной задаче в багтрекере, т.к. клиенты никогда не ищут похожие задачи - они создают новые. А может быть наоборот - проблему в хелпдеске понадобится разбить на несколько подзадач (например решаемых разными разработчиками) и это логично присвоить нескольким зависимым задачам в багртрекере. После того как задача решена - закрываются запросы в хелпдеске и уведомления уходят клиенту на почту/jabber/sms. Все довольны - в хелпдеске клиент видит список своих обращений и реакции на них техподдержки, в багтрекере разрабы видят систематизированный по их собственной схеме список багов и задач, с приоритетами, ссылками на участников процесса и т.п.

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

Систем реализующих полностью такой workflow я пока не встречал - что-то похожее попадалось, но в основном эти вещи вообще разделяют - или только хелпдеск, или только багтрекер, иногда ещё интеграция с системой контроля версий. Roundup, Mantis, Trac, Bt, RedMine, Mindquarry, Drupal Project, Drupal Storm, OpenAtrium - я перепробовал эти вещи в разное время под багтрекеры и хелпдески, trac и redmine в комбинациях c svn и bzr. В принципе удобнее чем ничего для разработки, но полностью в описанную выше концепцию ничего из этого не вписывается. Мейби что-то можно будет построить из OpenAtrium, на который я смотрю с оптимизмом - сейчас он обладает очень хреновым багтрекером, но на нём можно изобразить часть хелпдеска. Если сюда с другой стороны прикрутить багтрекер и интегрировать это с subversion (и мне лично более интересно с bazaar ng) - получится искомый инструмент.

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

Аватар пользователя sadmin sadmin 18 ноября 2009 в 18:58

"Dan" wrote:
В Атриуме можно завязать почту и багтрекер.

спасибо, как то совсем пост про него просмотрел.

"axel" wrote:
идеальным является симбиоз хелпдеска с багтрекером

"axel" wrote:
По собственному опыту применения багтрекеров (на примерах roundup и mantis) в личных проектах - для клиентов оно имеет мало смысла, хотя по началу людям нравится

согласен.

Аватар пользователя Artu Artu 19 ноября 2009 в 1:18

Александр,какую версию Мантиса вы используете?
Установил.Судя по картинкам ваша немного отличается от последнего релиза.Например переводом и функцией выгрузки в ексель.

Аватар пользователя teamfighter teamfighter 22 ноября 2009 в 16:53

Господа, есть ведь и другие багтрекеры. Например, SLA Assyst или HP OpenView. И первое, и второе весьма активно применялось (а первое и применяется) в М.Видео для регистрации проблем, возникающих у сотрудников. И то, и другое имеет веб-интерфейс, развитую систему выборок, регистрацию заявок по е-мейл и кучу всяких разных вкусностей. Единственный минус - уж больно сложны эти системы в настройке, как раз-таки из-за большого количества фич)

Аватар пользователя VladSavitsky VladSavitsky 23 ноября 2009 в 10:55

А я использовал Project Pier там есть возможность дать доступ клиентам и они могут создавать задачи для тебя, но система не достаточно гибкая, отвратительная архитектура и давно уже не обновляется...
Спасибо за наводку, Саша. Попробую Мэнтис!

Аватар пользователя argon argon 28 ноября 2009 в 11:21

Вообще проблема клиентского багтрекера не столько в трекере сколько в клиенте. Пользование багтрекером предполагает некую культуру подхода к постановке задач. А клиент - он всегда разный, со своими фишками и личными глюками. Соответственно глупо ожидать что два разных клиента будут одинакого вести багтрекер. А рычагов давления на них... ну сами понимаете). Так что по сути дела достаточно просто фиксировать в дескрипшене задачи текст клиента (на всякий случай))), а выставлять задачи всетаки обязанность менеджера разработки.