Читать книгу "Искусство управления IT-проектами - Скотт Беркун"

Устранение ошибок и дефектов

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

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

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

Приоритетность. Все должно быть проще простого. Приоритет 1 – ошибка должна быть устранена; приоритет 2 – ошибка по возможности должна быть устранена; приоритет 3 – устранение ошибка желательно, но не обязательно; приоритет 4 – ошибка вряд ли будет устранена.

Серьезность. Насколько серьезно влияние данной ошибки? Серьезность 1 – потеря данных, крах системы, проблемы безопасности; серьезность 2 – основная функция не работает так, как ожидалось (предписывалось); серьезность 3 – неосновная функция не работает так, как ожидалось (предписывалось). Серьезность отличается от приоритетности. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе слова «PAPAYA!» одними заглавными буквами в поле ввода электронного адреса на странице регистрации, у нее низкий приоритет (серьезность 1, но приоритет 4).

Данные о том, кто исправит ошибку. Работа над всеми ошибками должна быть поручена конкретным людям. Распределение новых ошибок может быть отложено, но одной из задач классификации ошибок (которую мы вкратце уже рассматривали) является как можно быстрее назначить конкретных ответственных за их устранение. Чтобы показать, что ошибка может проявляться в альфа– и бета-версиях, создайте для нее атрибут под названием «действующая» или «отложенная». Ошибки с таким атрибутом позже должны быть классифицированы и их устранение поручено конкретным людям.

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

Область действия. Для крупных проектов ошибки должны быть классифицированы по месту их проявления (по области действия). Тогда их можно будет отслеживать не только по исполнителям, которым поручено их устранение, но и по компонентам проекта.

Данные о том, кто обнаружил ошибку. Имя человека, обнаружившего ошибку, с указанием контактной информации.

Статус. Ошибка может иметь только четыре состояния: активна, исправлена, решена или закрыта. Активной считается ошибка, которая еще не исправлена и требует внимания. Исправленной ошибка становится, когда программист решает, что она исправлена. Решенной ошибка становится лишь тогда, когда обнаруживший ее человек согласится с тем, что она исправлена, или с тем, что ее исправление можно отложить. Статус закрытой свидетельствует о том, что ошибки больше нет и команда тестировщиков данный факт подтвердила.

Решение. Если по ошибке принято решение, значит, она лишается статуса активной. Решение по ошибке может иметь несколько разновидностей: она может быть исправлена, отложена до следующего этапа или версии, объявлена двойником другой существующей ошибки или признана неустранимой.

Тип. Ошибки делятся на два основных типа: дефекты и рецидивы. Дефекты – это обыкновенные, хорошо всем известные ошибки. Рецидивы – это ошибки, которые, будучи однажды исправлены, проявляются снова в виде негативных побочных эффектов или каким-нибудь иным образом.

Классификация. Этот атрибут показывает, была ли ошибка классифицирована и каков результат классификации. Иногда единственными ошибками, подлежащими устранению, являются те ошибки, которые были классифицированы и помечены как принятые. Поэтому данная графа может иметь три варианта заполнения: принята, отклонена, исследуется.

Наименование. Все ошибки должны иметь короткое имя, описывающее их таким образом, чтобы суть проблемы была понятна любому человеку.

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

Диаграмма активности

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

Даже при наличии самой простой базы данных по учету ошибок можно опрометчиво решить, что на ее основе предельно просто составлять различные виды диаграмм и делать сложные аналитические выкладки.[95]Не стоит слишком увлекаться, имеет смысл составить только самые основные виды диаграмм. Более сложные запросы зачастую носят отвлеченный характер («Гляньте-ка! Наш уровень исправленных ошибок соответствует уровню дождливых дней в Испании!»). Прежде чем тратить свое время впустую на выдумывание новых видов детальных отчетов, задайтесь следующими вопросами: