В настоящее время мы используем Mantis в качестве нашего багтрекера, и нам это надоело. Разработчики хотят больше интеграции с SVN, а клиенты - с более простой системой для работы.
Таким образом, мы ищем новый багтрекер, и в данный момент мы смотрим на Redmine. Однако в настройках по умолчанию он не соответствует желаемому рабочему процессу или, по крайней мере, не намного лучше, чем Mantis.
У нас есть следующий рабочий процесс, и мы хотим, чтобы багтрекер соответствовал ему.
- Сообщается об ошибке (часто заказчиком) и считается «новой».
Эти ошибки регулярно проверяются и либо признаются (это ошибка), либо помечаются как функция (клиент часто должен платить), и откладываются до тех пор, пока не будет проработана финансовая часть.
- Ошибки затем назначаются и обрабатываются разработчиком
- по окончании помечается как «готовый к рассмотрению» (другой разработчик)
- при просмотре помечается как "проверенный"
- если помечен как «проверенный», первоначальный разработчик помещает новый код в промежуточную среду и помечает ошибку как «готовую к проверке» (автор сообщения об ошибке)
- bug-reporter помечает ошибку как "решенную"
- при запуске в производство, ошибка-репортер закрывает ошибку
Конечно, обратная связь часто требуется, особенно на ранних стадиях. Мы ищем способ разграничить, кто должен сделать следующий шаг, и кому назначена ошибка (разработчик). Мы также хотим, чтобы клиент делал это с помощью простого графического интерфейса - попросив его сменить правопреемника со своего аккаунта на разработчика, или еще более сложным: у третьей стороны (например, дизайнерское агентство) слишком много вопросов, чтобы спросить с помощью обычного графический интерфейс.
Графический интерфейс должен показать им, что делать и какие есть варианты, а не искать их.
У кого-нибудь есть опыт работы с багтрекером, который работает таким образом? Является ли наш рабочий процесс действительно ненормальным? Как убедиться, что все участники понимают, где находится ошибка, и кто должен сделать какой шаг?