Интересуют не чистые bug tracking (типа PR Tracker), а умеющие также вести feature tracking. Ну то есть, чтобы не только ошибки менеджить, но и мелкие задачи.
Кроме того, желательно не иметь дополнительной монструозной нагрузки типа полный project management.
Интересуют отзывы: насколько удобно пользоваться, можно ли поставить сервер у себя или это чистый сервис, 
политика лицензирования (именное подключение или просто число одновременных подключений) и т.д.

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

Сама пока склоняюсь к FogBugs, но это, боюсь, чисто эмоциональный выбор...

FlySpray Несложная бесплатная програмка, позволяющая работать как с bug reports, так и с feature requests. Монструозности за ним я не заметил. Работать с ним на мой неискушенный вкус (с другими багтрегинговыми системами не работал) довольно удобно и, главное, просто. Штука эта бесплатная, распространяется под лицензией GNU. Требует для работы web-сервер, способный выполнять php-скрипты и MySQL/PgSQL в качестве базы данных. 

Это сообщение отредактировал(а) Bikutoru - 16.2.2007, 17:21

Bikutoru, спасибо, посмотрела. В общем все звучит неплохо, кроме призыва избегать MS Explorer, а у нас как-то везде по привычке именно он стоит (поскольку никаких особых требований никогда не было). Ты не знаешь, он действительно кривит? Опыт есть?

Я им пользовался только из Firefox'а, так что ничего про кривизну работы с IE сказать не могу. Сейчас ради интереса открыл в IE и просмотрел несколько страниц из него - вроде бы видимых косяков нет.

Обязательно посмотрите Trac http://trac.edgewall.org/
и плагины к нему: http://trac.edgewall.org/wiki/PluginList , http://www.trac-hacks.org/

dvska, спасибо за ссылку. Опыт есть? Как впечатления?

=)) 

Когда-то я тоже искал баг-трекер, и тоже думал на тему FogBugz. После изучения скриншотов и презентаций, желание пользоваться пропало. Не помню точно в чём было дело, видимо просто ожидал от неё большего. Правда я искал баг-трекер с уже интегрированной Wiki, интеграцией с Subversion, а также желательна была возможность примитивного управления проектом. Ну да это всё оффтоп. 

А если по делу, то... Я работал с Mantis, Bugzilla и пробовал Trac. Насколько я помню Feature Requests присутствует во всех трекерах. Обычно реализуется это через тот же "баг". Т.е. у бага просто выставляется соответствующий статус. 

Теперь конкретные впечатления от работы:

• Mantis - всё довольно просто, и при этом очень гибко. Очень много фильтров облегчающих поиск. Можно настраивать для себя главyю страницу. Установка(по словам админа, даже не админа, а начальника - ставил он) - проста, за 10 минут он поставил настроил язык. Требуется: Php+MySQL.
• Bugzilla - в плане функциональности схожа с mantis, но всё же(по-моему) проигрывает ему в плане удобства. Тем не менее, с регистрацией и отслеживанием багов справляется отлично. Требуется: Php+MySQL(если не ошибаюсь).
• Trac - этот проект в плане функциональности(поставленных) целей выходит за рамки обычного баг-трекера. Интеграция с Subversion заложена изначальна. Также присутсвует примитивное планирование(релизов) и управление проектом. Требуется: Python+MySQL(если не ошибаюсь). Работал с ним я довольно мало, ибо замучавшись разрешать глюки с настройкой некоторых плагинов, админ его просто снёс.  По-моему субъективному мнению, Trac ещё сыроват, хотя потенциал у него самый большой.

 
Хочу также упомянуть о Jira, которую очень хвалят те кто пробовал, но это уже не бесплатный продукт.

Пока искал ссылки, наткнулся на таблицу сравнения функциональности баг-трекеров в Wikipedia. Советую взглянуть. 

Пожалуйста отпишитесь о результатах выбора и впечатлениях от работы. Удачи вам!   

Это сообщение отредактировал(а) Bose - 21.2.2007, 15:46

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

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

Trac и Bugzilla мне при беглом взгляде не понравились - сразу говорю, не пробовала, а только посмотрела, что они про себя сами пишут, и как там все оформлено \ сложено... Вот FlySpray понравился, Mantis посмотрю.
С FlySpray попросила разобраться другого программиста (т.к. я с веб-программированием ну совсем никак), говорит какие-то проблемы с настройкой почты... Может, конфликтует с нашим почтовым сервером... За выходные, надеюсь, разберется...

До этого много лет вели ошибки\задачи просто в аутлуке, форму свою нарисовали. Не то, чтобы очень уж удобно, но как-то хватало...
Но недавно руководитель заявил, что ему ненаглядно и неудобно. И перевел все это дело в простую таблицу Excel  (начальники - они любят Excel). Но после того, как список задач вырос, я взвыла. Руководитель, выслушав мои вопли, сказал, что насчет возвращения в аутлук от категорически против, а если найду что-то удобно и недорогое - то пожалуйста, лишь бы были достаточные возможности просмотров. Project management мне там не нужен, насчет интеграции с Version control я в некотором недоумении - зачем? Т.е. предполжить могу, конечно, но как-то это громоздко. 

Как вариант - TrackStudio. 

Плюсы по сравнению со всем остальным:

1) Настроить можно вообще все, причем конфигурация (группы пользователей,workflow, права, шаблоны e-mail, etc) может быть разной для разных проектов. Это очень удобно, т.к. если система начинает использоваться для 2-х разных проектов/заказчиков, то другие системы часто бывает нельзя так настроить. Например, у всех open source систем может быть только 1 workflow, если нужно 2 - ставим еще один экземпляр и думаем как мигрировать пользователей, проекты и прочие настройки. С TrackStudio этого можно успешно избежать, на демо-проекте (TrackStudio Host) хостится больше 1000 проектов на одном экземпляре TS. Jira Enterprise тоже что-то умеет в этом плане, но TrackStudio гибче на порядок, сравнение с Jira "в лоб" тут:
http://www.trackstudio.ru/products-comparison.html

2) Если хочется еще и project management, то обычного issue tracking может не хватить. Заказчик обычно не способен понимать прогресс по проекту на уровне отдельных багов, а более высокоуровневое представление другие issue tracking system обеспечить не могут т.к. не поддерживают иерархии задач:
http://www.trackstudio.ru/forum/bug-tracki...issue-1685.html

3) Во всех остальных системах добавление комментария, изменение состояния, ответственного, внесение рабочих часов - это разные операции, которые никак не связаны между собой. На деле же это часто одна операция:
- программист исправил багу и вносит в систему комментарий с описанием что он сделал (1), переводит багу в состояние resolved (2), меняет ответственного на tester-а (3), вносит сколько времени заняло исправление.
- от пользователя пришел feedback по старой проблеме и саппортер должен внести в систему ответ пользователя (1),  переоткрыть задачу (2), назначить программиста ответственным (3), установить приоритет/deadline (4).
В TrackStudio это можно сделать на одной форме (там можно настраивать кто и что может/должен внести), в других системах меня очень напрягало лазить по нескольким экранам чтоб сделать несколько связанных действий. Кроме того, в TrackSudio можно по этой исторической информации искать, например можно узнать сколько времени ушло на исправление баги (resolve), а сколько на проверку (verify). Или посмотреть на одной странице все исправленные баги за день и комментарии именно к этим исправлениям.

4) Project managament и version control - они начальству нужны, программистам они обычно ни к чему. Например, исправляет программист багу, при коммите указывает что исправление относится к задаче #123. Когда менеджер решит посмотреть что сделал программист - у него прямо в багтрекилке все под рукой - и описание программиста, и что именно он менял, и diff-ы. Часто по одним diff-ам понятно что программист сделал не то и можно даже не тестировать, это очень экономит время. Если в разработке несколько версий продукта - сразу видно в какие версии были внесены изменения, программисты довольно часто тут ошибаются (например, исправляют только development версию, хотя нужно еще и stable).
А программистам оно ни к чему - свои изменения они и так знают, а хронология чужих изменений их интересует мало.

С project management аналогично - программист понимает состояние проекта по состоянию багов, а начальство/заказчик - не очень. И никакие анализы/отчеты/графики тут не помогут - нельзя по принципиальной схеме телевизора сгенерить руководство пользователя, это просто разные уровни представления информации.

Внешне мне FlySpray тоже понравился - смутило лишь отсутствие "финальной версии". Всё в постоянном процессе разработки. 


До того как перейти на трекер, мы тоже пользовались Excelом. 


Очень удобно, по-моему должно быть. На практике, я так и не пользовался, но в теории(упрощенно) всё по-моему должно выглядеть так:
Тестировщик заносит баг в трекер.
Программист этот баг исправляет, и сохраняет в репозитории новый код с пометкой того самого бага. 
После этого описывает в Wiki изменения(если есть что описать).

В результате получается, что для каждого bug/feature request можно посмотреть что же именно было изменено в исходном коде. А если есть Wiki, то ещё и документировать. 

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


maximkr, спасибо за примеры в описании. Очень интересно.

Earnest, загляните сюда и по ссылкам.

Да, использовали. 
Оно работает.  Интеграция с Subversion сделана действительно удачно. Wiki тоже неплохо прикручена.


Это сообщение отредактировал(а) dvska - 22.2.2007, 17:18

Bose,  а расскажите, для какого рода комментариев вообще Wiki использовать ? Мы не пользуемся и я не очень понимаю зачем оно может быть полезно для разработки коммерческого софта.

Общие соображения:

1) Информацию о коде (кто, когда, что и зачем сделал) лучше хранить или в коде, или в багтрекилке. Например, если непонятно кто и зачем то сделал, то можно выполнить svn annotate, посмотреть номер revision и по нему найти багу/задачу, а там уж будет понятна вся история вопроса и что еще менялось по этой теме. Т.е. багтрекинг + SVN дают вместе очень ценную возможность - видеть частью какой фичи был этот кусок кода и переписку зачем оно было нужно, этого нельзя добиться ни комментариями, ни wiki.

2) Для внешних пользователей (особенно непрограммистов) wiki слишком сложна и не дает нужной гибкости. Скажем, системы типа RoboHelp для хелпописателей гораздо понятнее и удобнее, многие из них используют Word/HTML в качестве исходного формата. 
Word в качестве системы подготовки документации - это ОГРОМНЫЙ плюс по сравнению с wiki, т.к. wiki не поддерживает style sheets и нельзя указать что это статья, это новость, а потом изменить форматирование всех новостей.
Другой момент - под Word/FreeMarker есть куча специализированных продуктов, например разные системы translation memory. А если документ в виде wiki (который 90% переводчиков не понимают, у большинства и с HTML проблемы), то его нужно будет сначала перегнать в word, потом отдать на перевод, потом перевод обратно отформатировать в wiki. Дописывание такой документации с переводом измененных кусков - это просто кошмар, по себе знаю :-(
Ну т.е. нестандартный формат файлов - это практически showstopper при подготовке документации, этот минус перевешивает почти все остальные плюсы.

Wiki популярна для open source проектов, когда специальных писателей документации нет и разработчки напрямую общаются с пользователями и когда пользователи сами хотят дописывать документацию. А вот для коммерческого софтописания зачем используют (а ведь используют же) - не пойму.

PS. Сорри за наивные вопросы, сам с  wiki толком не работал (т.к. не понимаю где такие системы можно применить). 

Я не хочу утверждать, что Wiki это самый удобный способ, но с другой стороны - он всё же работает. ;) К тому же синтаксис Wiki достаточно прост. 

Я использовал Wiki для ведения технической документации по проекту. Причем на том месте работы это была stand-alone Wiki. Т.е. интеграция с репозиторием кода и баг-трекером отсутствовала. Описывал там я следующее:  
1) описание библиотек, модулей, классов. 
2) описание необходимых файлов и их местонахождения
3) описание DLL-лок задействованных сразу в нескольких проектах
4) режимы запуска программы
5) Changelog также вёл в Wiki(дублируя эту информацию при внесении кода в репозитарий).

Хочу уточнить. У меня не было опыта работы в крупных компаниях, где процессы создания технической документации были бы описаны и успешно внедрены в повседневное использование. Т.е. в моей работе я постоянно наблюдал такую картину: у компании есть несколько проектов, и за каждый проект обычно отвечает один человек, который там всё знает вдоль и поперёк, и не ведёт никакой документации. Именно опыт разбора подобной "свалки недокументированного кода" и побудил меня вести хоть какое-то протоколирование действий. Во всех компаниях есть какие-то свои наработки и библиотеки, многие из реализованных в них вещей могут быть гениальны, но документация как правило отсутствует. И всё, с чем мне приходилось разбираться я старался описать хотя бы вкратце.


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


Опять сознаюсь в отсутствии опыта.   * немного грустный смайлик * Я не работал(и упомянул об этом) в интегрированной системе, где в связке трудятся Bug-tracker и SVN. Поэтому могу предложить лишь теоретическое обоснование: комментарии к коду при коммите хороши, но насколько я помню - они представляют собой plain-text, т.е. возможность создания ссылок на другие документы(коммиты, баги, requestы) отсутствует(поправьте меня пожалуйста если я не прав). И интеграция с Wiki по идее должна исправить эти недостатки, позволив создавать более развёрнутые описания исправлений и остальные преимущества использования html.
Так это я себе представляю. 

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


Спасибо, maximkr! Ваш опыт для меня действительно интересен.

Добавлено @ 18:24 
Вот еще наткнулся на обсуждение баг-трекера в ветке java-tools:
http://forum.vingrad.ru/topic-89697/0.html

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

По Вики на форуме где-то была отдельная тема.
Мы его тоже активно в работе используем.