Является ли наш рабочий процесс работы с ошибками уникальным?

Question

В настоящее время мы используем Mantis как наш bugtracker, и мы очень устали от этого. Разработчики хотят больше интеграции SVN, клиенты хотят, чтобы более легкая система работала.

Таким образом, мы ищем новый bugtracker, и в настоящий момент мы смотрим на Redmine. Однако при настройке по умолчанию он не соответствует нашему желаемому рабочему процессу или, по крайней мере, не намного лучше, чем Mantis.

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

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

Конечно, обратная связь часто требуется особенно на ранних стадиях. Мы ищем способ отличить того, кто должен сделать следующий шаг, и кому эта ошибка назначена (разработчик). Мы также хотим, чтобы клиент сделал это, используя простой gui - попросив их изменить цессионария со своей учетной записи разработчику или еще более сложно: стороннему (think: design agency) просто слишком много, чтобы спросить, используя обычный графический интерфейс. Gui должен показать им, что делать, а какие есть - не искать их.

Есть ли у кого-нибудь опыт работы с bugtracker, который работает таким образом? Не работает ли наш рабочий процесс? Как вы убеждаетесь, что все участники понимают, где находится ошибка, и кто должен выполнить какой шаг?

Answer 1

В прошлом году у нас была та же проблема, и мы выяснили, что лучшим решением для нас было Jira. С уважением, наш рабочий процесс более прочный и сложный, чем ваш.

Answer 2

У нас практически такой же рабочий процесс, с которым мы управляем Redmine с интеграцией электронной почты. Клиент регистрирует ошибки в Redmine напрямую. Уведомление приходит к менеджеру проекта, который решает, какой разработчик может работать над ошибкой. Разработчик открывает ошибку и помещает ее в состояние «Расследование». Если его особенность, он отвечает на него с изложением причин и помещает их в состояние «Ответ», которое затем пересматривается позже. Если его ошибка, то разработчик начинает разработку. До этого он помещает ошибку в состояние кодирования. После того, как кодирование закончено, он изменяет состояние ошибки как Review и сверстников. Если есть какие-либо доработки, разработчик изменяет состояние на Rework. Как только все будет в порядке, разработчик изменяет состояние на «Поставлено». QA проверяет ошибку и, наконец, закрывает ее, изменяя состояние на Closed.

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

Answer 3

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

Рабочий процесс, который вы описали, также звучит так, как Red Hat использует Bugzilla.

Answer 4

Как было сказано другим, Джира очень хороша. Мне особенно нравится его способность создавать собственный вопрос. workflow