Цель ежедневной классификации проста – поддерживать порядок. Критический путь эндшпиля проекта проходит через работу программистов, и классификация является единственным способом обеспечить эффективность конвейера. Желательно до того, как каждая новая ошибка попадет на рабочий стол программиста, провести ее первичную обработку и сравнение с существующим фондом ошибок.
Иногда лучше (в интересах эффективной работы команды) в каждой области иметь по одному человеку, занимающемуся ежедневной классификацией ошибок. Предполагая, что программисты и тестировщики согласовали критерии, этот человек должен отвечать за первичную обработку новых ошибок, пометку ошибок-двойников и расстановку обнаруживаемых ошибок по приоритетам. Предполагая, что технических знаний руководителя проекта вполне достаточно для осмысления проблемы и принятия основных решений по ошибке, он является весьма неплохой кандидатурой на эту роль.
Впрочем, классификация может проводиться и на небольшом совещании в присутствии руководителя проекта и представителей от разработчиков и тестировщиков. Если понадобятся другие специалисты из состава команды, скажем, маркетологи, проектировщики или специалисты по потребительским качествам продукта, то их можно пригласить дополнительно. Совещание должно проводиться накоротке. Все, что не может быть решено за пару минут, должно передаваться программисту на исследование.
Как только ошибки будут классифицированы, для них должно быть заполнено поле классификации. Тогда в проекте появятся дополнительные условия для представления данных об ошибках и можно будет отделить количество классифицированных ошибок (в достаточной мере распознанных) от общего количества активных ошибок (еще не прошедших оценку).
При целенаправленной классификации усилия сосредоточиваются на решении конкретных задач. Целенаправленная классификация проводится в дополнение к ежедневным классификациям. Это – одно из средств управления проектного уровня, призванное помочь придать проекту новый импульс и повысить ценность диаграмм работ по устранению ошибок и анализа текущих тенденций. Рассмотрим несколько общих причин проведения целенаправленной классификации:
Низкое соотношение числа классифицированных ошибок к числу активных. Если на 500 активных ошибок приходится лишь 200 классифицированных, то невозможно узнать серьезность оставшихся 300 ошибок. Кто знает, все они могут оказаться ошибками с приоритетом первой очереди, вызывающими полный крах системы, или двойниками уже существующих ошибок. Целенаправленная классификация может иметь особую задачу по ликвидации всех неклассифицированных ошибок к определенному сроку (к завтрашнему полудню). Ели эта проблема приобрела для команды хронический характер, задачей может стать не оставить ни одной активной неклассифицированной ошибки старше определенного количества часов (например, 24 часов).
Изменились критерии выхода. Если руководство команды решило, что критерии выхода должны претерпеть изменения, то классификация станет единственным способом вывести проект на путь этих изменений. Обычно новые критерии выхода используются для изменения угла снижения, исключая определенные классы ошибок из рассмотрения для повышения безопасности этого угла (но при этом жертвуя качеством процесса).
Слишком много незакрытых ошибок. Когда ошибка исправлена, нужно присвоить ей статус решенной и отправить сообщение назад, тому, кто ее открыл, чтобы убедить его в том, что она действительно исправлена. Определенный процент таких ошибок может быть исправлен не так, как следовало бы. Если подобные ошибки числятся незакрытыми, то набирается множество ошибок, требующих исправления, но не попадающих в отчете в число активных. В зависимости от применяемой системы мониторинга ошибок могут быть и другие места, где могут скрываться ошибки. Периодически команду нужно нацеливать на то, чтобы она извлекала их из этих закутков.
