Этот вопрос охватывает программное обеспечение для отслеживания ошибок в целом, но мне интересно узнать более подробно о Devtrack.
Если у вас есть опыт использования, я хотел бы услышать об этом. Как бы вы сравнили это с другими системами отслеживания ошибок, которые вы знаете, что вы считаете хорошим и плохим, и почему?
Я использовал его, когда работал в Electronic Arts Tiburon... IMO, пользовательский интерфейс неудобен, а входящие/управляющие ошибки занимают много времени. В зависимости от того, какую среду вы используете, я также рассмотрю:
Мы используем Devtrack как нашу систему отслеживания ошибок, и я бы сказал, что вы можете сделать намного лучше. Комментарий, который я добавил бы к сообщению Joel, поиск не выполняется хорошо и очень медленно.
Еще одно решение, которое я мог бы рассмотреть, - Jira
Мы используем DevTrack по всему миру - выбор сделан примерно 2 года назад и до того, как я присоединился к компании. Имея прошлый опыт работы с Mantis, Track и Jira, я очень страдаю от использования этого инструмента. Для выполнения основных задач требуется большая работа, например, добавление комментариев или представление новых проблем. Также мне не нужно "смотреть" билет, то есть получать уведомления об изменениях, внесенных в него, если в какой-то момент я не владел им. Он использует JavaScript для запуска функций, и вы не можете скопировать URL-адрес любой страницы билета. Нам нужно обменивать номера билетов и каждый раз просматривать их.
Он мощный и настраиваемый, но я бы хотел, чтобы они больше работали над удобством использования.
Если у вас есть выбор, держитесь подальше от DevTrack и отправляйтесь FogBugz или вместо Jira.
DevTrack вытесняется в некоторых областях моей компании. Я слышал две вещи: это нормально, когда вы привыкаете к ней, или это болезненный/утомительный опыт. Мое настоящее впечатление заключается в том, что он имеет большую поддержку на уровне "лица, принимающего решения", чем на уровне разработчика.
Не уверен, как это сделать, но хотелось бы, чтобы этот вопрос стал новым светом, теперь, когда прошло уже полгода. Любые дальнейшие мысли от кого-либо?
Мне вообще не нравится DevTrack, но наша компания использует его. У нас была небольшая команда, и у нас была лучшая работа bugzilla.
Одна из вещей, которую я ненавижу, заключается в том, что каждый раз, когда я получаю сообщение об ошибке, и нажимаю на ссылку, она переходит к ошибке, но вы ничего не можете изменить - на самом деле это не страница с ошибкой.
И снова наши тестировщики, производители, я думаю, привыкли к этому, и могут настроить его, вероятно, лучше, чем другие продукты для наших конкретных потребностей (видеоигры).
Мы также использовали DevTrack в течение многих лет и перешли на Software Planner (http://www.SoftwarePlanner.com) около года назад и намного счастливее.
мы всегда находили, что в итоге мы дублируем много работы с помощью devtrack. Для разработчиков обычно больно использовать, особенно при попытке сохранить историю или базу знаний о разработке приложений или исправленных ошибках и т.д. И в конечном итоге сохранить записи в другом программном обеспечении, которые больше предназначены для отслеживания ошибок, но также должны поддерживать devtrack "до дата", как то, что менеджеры используют, чтобы увидеть, сколько работы вы делали и т.д., они используют его для ответа на такие вопросы, как "где мой бюджет тратится", "это работа, выполняемая определенными датами"
инструмент определенно ориентирован на менеджеров, которые могут генерировать отчеты по часам и датам и т.д.
Мы использовали DevTrack 6 много лет назад и были полностью удовлетворены. Но мы использовали локальную версию, а не веб-интерфейс. Нам также не нужен доступ в Интернет. DevTrack очень настраиваемый: нам удалось установить наш собственный набор полей для проблем, пользовательских состояний проблем, рабочего процесса, прав пользователя (даже для каждого поля! - кто может просматривать или редактировать какое поле при заданном состоянии проблемы), настраиваемое описание проблемы страниц и т.д. Другие инструменты в настоящий момент не смогли обеспечить функциональность, в которой мы нуждаемся. Что касается добавления новых вопросов, мне интересно, почему это говорит о сложной ситуации. Нажмите кнопку "Создать", напишите описание проблемы и нажмите "ОК" - что может быть проще? Что касается поиска - да, это немного медленно. Но у DevTrack есть много других способов разобраться в проблемах. Например. вы можете настроить дерево функций проекта и отобразить проблемы, относящиеся к некоторым функциям, выбрав соответствующий элемент в дереве.
Я был в среде, которая использует его уже месяц, ранее использовала Jira, FogBugz и другие. Пользовательский интерфейс очень неуклюж, как если бы он был написан в VB в 1997 году, и ДЕЙСТВИТЕЛЬНО трудно получить отчеты (коллеги нашли способ экспортировать в Excel и делать там свои отчеты). Мы хотим создать гибкую среду разработки, и я не думаю, что DevTrack позволит это очень легко. Возможно, я ошибаюсь, посмотрим! Я готов ошибиться.