18 ноября 2009 в 4:32
Этой статьей я хотел бы начать цикл статей об инструментах разработки друпал-ориентированного фрилансера или веб-студии. Начнем, пожалуй, с багтрекера.
Тезисы статьи могут показаться кому-то совсем уже очевидными, однако на моей памяти нет ни одного фрилансера, который имеет собственный багтрекер для обслуживания своих клиентов. Для мелких студий это вообще must-have, но и у них, бывает, что багтрекера попросту нет.
Кроме того, статья является мануалом для самих клиентов, где на пальцах показано, как пользоваться типичным багтрекером.
P.S. Хотел вставить сюда весь пост, но он выглядел здесь слишком убого в стилях drupal.ru, поэтому, даю лишь ссылку на саму статью.
Комментарии
Если я правильно понял, то для этих целей подойдет Atrium. С появления Atrium стал задумываться что пора предлагать клиенту такие услуги.
Atrium, Mantis... есть еще? На Drupal ведь тоже можно сделать багтрекер?
Есть еще seework.
Полезная тема. Традиционно, на друпал.ру мало обсуждалось (или я не заметил?) вопросов, посвященных подобным темам. Теперь дело исправилось, тут багтрекер, на баркемпе о тестировании услышим. Заживём однако
Сюда бы что-то типа багтрекера - запарился в трекере наблюдать мельтешащую плашку [решено]
Ведь по сути форум преимущественно и исполняет роль системы исполнения заявок, куда валятся людишки со своими проблемами, а другие их пытаются решить.
Тема полезная, однако уверен, что есть и другие решения
Ничего не стоит добавить во вьюху фильтр по этой "плашке". Как только пользователь дописывает этот текст в ноду, оно автоматом убирается из всех трекеров. Можно экспозед фильтром позволить и их выводить. Все просто, но некошерно
добавлю трекер, который мы пользуемся: TrackStudio - мощное средство от соотечественников.
Есть и бесплатный - ограничение только по количеству юзеров - для малой студии хватит.
дык модуль есть casetracker
на группах в друпал
И табличка для сравнения с другими тикет-хелпдесками: http://groups.drupal.org/node/17948
Отличная тема! Вот вам и баг в ваш багтрекер!
Тема хорошая, для своих клиентов пытаюсь использовать Atrium. Почему только пытаюсь, потому что клиента хрен заставишь писать сообщение в багтреккинг, а не в привычный скайп, почту и телефон.
То ShvetsGroup Prefer English похоже пока не работает? (а вообще сайт понравился)
Александр, продолжай в том же духе, твои посты всегда интересны.
серьезные багртекеры имеют модули для коммита багов через e-mail. можно сделать занесение бага через jabber.
но это не вылечит основную причину почему клиенты это не делают. заполнять баги надо учиться, надо договариваться как будет организована схема обработки багов и прочее. именно это не хочет клиент делать! и по правде говоря, я и сам не люблю тратить время на багбазу и никто не любит.
в небольших проектах расход времени на работу с багбазой неоправдан. это реально только потеря времени. это становится оправданным когда багтрекер совмещен с проджект менеджментом, то есть задачи сотрудникам раздаются через тикет-систему, а зарплата начисляется по количеству закрытых тикетов.
к слову для последнего вполне подходит Trac. советую! )
Это идея. Связать багтрекер с почтой, завязать аккаунты на людях и выставлять свой id как контакт, по которому можно связаться и следить за результатом.
90-95% клиентов багтреккер не будут использовать. Мыло, тел, мессенджеры.
Единственное полезное применение - для команды разработчиков (территориально разнесённых) для совместной разработки систем уровнем выше среднего. Мантиса прижилась только с этого уровня ;).
Долгое время пользовали bugzilla -- это просто мега-монстр. Пробывали Mantis чем-то не покатил, уже не помню сейчас, что не устроило. Сейча перешли на Trac. Пока устраивает, в качестве плюса -- интеграция с SVN. Когда закрываешь баг можно сразу дать ссылку на ревизию в svn.
Каковы причины перехода на Trac?
Использовать далее инсталяцию bugzilla не было возможности, а Mantis не покатил. Почему не покатил я уже не помню, год назад экспериментировали. Может быть из-за того, что сразу после bugzilla. Мантис, конечно, по фичам сильно проигрывает, другая идеология... может просто не приглянулось.
Зато могу рассказать почему следующий выбор был за Trac
* Разумная комбинация возможностей и сложностей
* Возможность использовать для project management, т.е. не только для багов, но и для задач.
* Наличие встроенной Wiki-системы для ведения сопровождающей документации по проекту
* Интеграция с SVN, возможность постановки отчеты по багам/задачам ссылок на ревизии, простотр diff-ов он-лайн...
* Использование в качестве БД Postgresql
* Желание поэксперементировать с Python )
А этот Trac веб интерфейс для клиента имеет?
обязательно! )
сам проект -- http://trac.edgewall.org/
список активных задач -- http://trac.edgewall.org/report/1
все доступные отчеты -- http://trac.edgewall.org/report
Для связывания с SVN нужно создавать соответствующий внешний сервер для контроля версий? И он должен синхронизироваться с внутренним, правильно понимаю?
для svn нет понятия сервер в явном виде, основным понятие является "репозиторий", доступ к которому может осуществляться через различные механизмы. в том числе и через apache web-dav.
но trac не умеет работать с репозиторием через web-dav. в текущей реализации доступ к репозиторию возможен только напрямую к файлам, через python-binding.
то есть svn репозиторий должен находиться на в той же системе что и trac.
синхронизировать svn-репозитории можно, по-моему, только в одном направлении.
Да, мантис хороший багтрекер, сам регулярно пользуюсь.
Странно что никто не юзает Redmine (http://www.redmine.org/). Мы его уже больше года используем. Пользовались всем выше перечисленым, наш опыт: Mantis - старье, похожее на курсовую работу студента с интерфейсом в котором не разберется даже продвинутый заказчик. Trac - хорош, но не удобен тем, что для каждого отдельного проекта разворачивать надо отдельную копию Trac (про последние версии не уверен, но врядли там что то сильно поменялось, идеология не та) и интеграция с svn там не очень (выше уже заметили).
Отдельная инсталяция Trac для отдельного проекта -- это преднамеренная фича. Ее удобство/неудобство зависит исключительно от настройки рабочего процесса в организации. Проект сделали, сдали, все данные заархивировали, про проект забыли. Где-то другие требования, но для монстрозных проектов, по-моему, bugzilla вне конкуренции.
А насчет интеграции svn в trac ты что-то напутал, так с этим все ОК.
Ну мог и напутать, в принципе это субьективно моё мнение, мне в Redmine это кажется удобным.
В Атриуме можно завязать почту и багтрекер.
Клиенту нужен не багтрекер, а хелпдеск. Потому как ему хочется побыстрей сообщить о проблеме и совершенно нет интереса разбираться в специфике заполнения полей, предлагаемых багтрекерами. Пример: клиенты практически всегда присваивают проблеме максимальную важность - просто потому, что раз проблема возникла и мешает им работать, для них лично её решение важней всего. Либо оставляют непонятные поля по умолчанию, т.к сомневаются в их заполнении.
На мой взгляд идеальным является симбиоз хелпдеска с багтрекером. С "клиентской" стороны - хелпдеск, для которого важна простота интерфейса и возможность сбора сообщений из разных источников - из почты, с джаббера, в идеале туда же логи телефонных звонков. Клиент пишет, получает ответ, что запрос получен - на какое-то время он успокаивается, т.к. ему важно вначале удостовериться что проблему он донёс до разработчиков. На "программерской" стороне стоит полноценный багтрекер, где разработчики рассматривают пришедшие запросы из хелпдеска и сами формируют по ним задачи. Например десяток пришедших в хелпдеск запросов вполне может оказаться принадлежащими одной задаче в багтрекере, т.к. клиенты никогда не ищут похожие задачи - они создают новые. А может быть наоборот - проблему в хелпдеске понадобится разбить на несколько подзадач (например решаемых разными разработчиками) и это логично присвоить нескольким зависимым задачам в багртрекере. После того как задача решена - закрываются запросы в хелпдеске и уведомления уходят клиенту на почту/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) в личных проектах - для клиентов оно имеет мало смысла, хотя по началу людям нравится. Но потом сам путаешся в куче бессистемных багрепортов от заказчиков. Я только убедился, что багтрекер хорош персонально для себя, когда сам пишешь напоминалки о багах - особенно в интеграции с системой контроля версий (при условии, что она поддерживает связь с багтрекером).
спасибо, как то совсем пост про него просмотрел.
согласен.
короче - пустое это в применении к клиентам...
Александр,какую версию Мантиса вы используете?
Установил.Судя по картинкам ваша немного отличается от последнего релиза.Например переводом и функцией выгрузки в ексель.
1.2.0rc2
Господа, есть ведь и другие багтрекеры. Например, SLA Assyst или HP OpenView. И первое, и второе весьма активно применялось (а первое и применяется) в М.Видео для регистрации проблем, возникающих у сотрудников. И то, и другое имеет веб-интерфейс, развитую систему выборок, регистрацию заявок по е-мейл и кучу всяких разных вкусностей. Единственный минус - уж больно сложны эти системы в настройке, как раз-таки из-за большого количества фич)
А я использовал Project Pier там есть возможность дать доступ клиентам и они могут создавать задачи для тебя, но система не достаточно гибкая, отвратительная архитектура и давно уже не обновляется...
Спасибо за наводку, Саша. Попробую Мэнтис!
Вообще проблема клиентского багтрекера не столько в трекере сколько в клиенте. Пользование багтрекером предполагает некую культуру подхода к постановке задач. А клиент - он всегда разный, со своими фишками и личными глюками. Соответственно глупо ожидать что два разных клиента будут одинакого вести багтрекер. А рычагов давления на них... ну сами понимаете). Так что по сути дела достаточно просто фиксировать в дескрипшене задачи текст клиента (на всякий случай))), а выставлять задачи всетаки обязанность менеджера разработки.