Системы отслеживания ошибок
В дополнение к своей основной функции, система контроля жизненного цикла ошибок (bug-tracking system) представляет собой превосходное средство для пересылки коротких напоминаний и хранения списка работ, особенно в процессе разработки кода. Некоторые разработчики любят хранить заметки и списки работ в записных книжках, однако существенная информация при этом часто теряется среди случайных записей. Помещая эти заметки, адресованные самому себе, в систему отслеживания ошибок, вы объединяете их в одном месте и облегчаете поиск. Кроме того, код, с которым вы работаете, в действительности принадлежит всей команде. И при наличии вашего списка работ в системе отслеживания ошибок, другие члены команды, которые должны взаимодействовать с вашим кодом, могут видеть, что вами сделано, а что — нет. Включение списков работ и заметок в систему отслеживания ошибок позволяет также уменьшить количество деталей, потерянных в результате забывчивости или других причин. Я всегда работаю с системой отслеживания ошибок, что дает мне возможность быстро записывать важные замечания и списки работ в момент их обдумывания.
Я люблю резервировать самый низкоприоритетный код ошибки в системе для замечаний и списков работ. Это облегчает их хранение отдельно от реальных ошибок, но в то же время, если понадобится, можно быстро поднять их приоритет. Следует структурировать отчеты с метрикой ошибок так, чтобы они не включали код ошибок самого низкого приоритета, потому что это приведет к искажению результатов.
Внимательно просматривайте данные каждой прослеживаемой ошибки — там неприкрашенная правда о вашем продукте. Планируя модернизацию,
пробегите систему отслеживания ошибок и найдите те модули или свойства, которые сопровождаются самыми длинными отчетами об ошибках. Предусмотрите некоторое дополнительное время в вашем рабочем плане, чтобы члены команды могли вернуться к отладке и подправить секции соответствующего кода.
При развертывании системы прослеживания ошибок (BTS) удостоверьтесь, что каждый, кто в этом нуждается, имеет к ней доступ.
Этот доступ нужен, по крайней мере, всем членам команды разработчиков и команды технической поддержки. Если эта система поддерживает различные уровни доступа, то можно подумать также и о разрешении доступа другим специалистам, например, коммерческим инженерам (техническим экспертам, которые являются частью торговой организации и помогают продавцам при реализации сложных продуктов) и представителям маркетинга. Например, некоторым продавцам и специалистам по маркетингу можно позволить вводить запросы об ошибках и свойствах, но не просматривать существующие ошибки. Эти две группы специалистов общаются с заказчиками гораздо чаще, чем обычные инженеры, и подобная обратная связь может оказаться бесценной. Регистрация их запросов и проблем в той же системе, которую используют еще и другие специалисты, достаточно эффективна и практична. Смысл состоит в том, чтобы иметь единое место, где сосредотачиваются запросы по поводу всех проблем и свойств. Если эта информация хранится в разных местах, то возрастает вероятность потерять ее след.
