Можно ли отследить или измерить причину ошибок или это просто требует непредвиденных последствий?

Question

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

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

ИмеетКто-нибудь нашел механизм, чтобы сделать этот тип отслеживания без вождения плохого поведения?Можно ли ожидать полезных данных от членов команды, если мы объясним команде причину этих данных (не для определения отдельных показателей эффективности, а показателей успеха проекта)?Есть ли другой, лучший способ сделать что-то подобное (возможно, более специальное вскрытие или открытое обсуждение вопросов)?

Answer 1

У многих пакетов контроля версий есть такие вещи, как svn blame. Это не прямой показатель для отслеживания ошибки, но он может сказать вам, кто зарегистрировал изменения в выпуске, в котором есть серьезная ошибка.

Есть также такие программы, как http://www.bugzilla.org/, которые помогают отслеживать вещи с течением времени.

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

• Плохо написанные спецификации
• Срочные сроки
• Программирование с низким уровнем навыков
• Плохой боевой дух
• Отсутствие бета или QA тестирования
• Отсутствие подготовки программного обеспечения, чтобы его можно было использовать даже для бета-тестирования или тестирования качества
• Низкое соотношение времени, затрачиваемого на устранение ошибок, по сравнению с получением новых функций
• Низкое соотношение времени, затрачиваемого на усовершенствования без ошибок, по сравнению с получением функциональности
• Превосходная сложная система, которую легко сломать
• Изменяющаяся среда вне базы кода, например, администрация машины
• Вина за ошибки, влияющие на компенсацию или продвижение программиста

Это лишь некоторые из них ... Если слишком много ошибок - это большая проблема, то руководству и ведущим программистам и всем другим заинтересованным сторонам всего процесса необходимо сесть и обсудить проблему.

Answer 2

Высокие показатели ошибок могут быть признаком слишком быстрого или негибкого графика. Переход на подход с нулевым дефектом может помочь. Исправьте все ошибки, прежде чем работать над новым кодом.

Назначение причин - это хороший способ выяснить, есть ли у вас проблемная зона. Типичные метрики, которые я видел и встречал, - это четное разделение между:

• Ошибки спецификации (отсутствуют, неточности и т. Д.)
• Ошибки приложения (неправильный код, отсутствующий код, неверные данные и т. Д.)
• Неправильные тесты / нет ошибок (как правило, неверные ожидания или спецификации еще не реализованы)

Может быть полезным выявление и проверка причин неисправности.