Панель мониторинга "Ошибки" (Agile и CMMI)

 

Отслеживать активность ошибок в командном проекте можно при помощи панели мониторинга "Ошибки", на которой отображаются следующие графики:

• гистограмма ошибок;

• Скорость обнаружения, разрешения и закрытия ошибок командой за определенный период

• Количество приоритетных ошибок за определенный период

• Текущее количество активных ошибок, назначенных каждому из участников команды

  Доступ к панелям мониторинга осуществляется через портал командного проекта. Доступ к панели мониторинга "Ошибки" возможен только в том случае, если этот портал работает и подготовлен к работе с использованием SharePoint Server Enterprise Edition. Подробнее см. в разделе Панели мониторинга портала проекта.

Содержание раздела Данные, отображающиеся на панели мониторинга Действия, необходимые для отслеживания ошибок Отслеживание активных ошибок и тенденций ошибок

Эту панель мониторинга можно использовать для ответа на следующие вопросы. Насколько быстро команда устраняет и закрывает ошибки? Достаточно ли быстро группа исправляет ошибки, чтобы закончить работу вовремя? Сколько ошибок группа обнаруживает, разрешает и закрывает за день? Устраняет ли команда ошибки с приоритетом 1 перед устранением ошибок с приоритетом 2 и 3? Осталась ли у какого-либо из членов команды невыполненная работа по ошибкам с приоритетом 1, которые служат основанием для перераспределения? В каком состоянии находится вчерашнее построение? Что входило в число последних возвратов?

Требования

Те же требования, что и в разделе Панели мониторинга портала проекта.

Данные, отображающиеся на панели мониторинга

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

Примечание

Диаграммы сгорания, трендов, линейчатые диаграммы и отчеты c по не отображаются, когда недоступен сервер, на котором расположены службы Analysis Services для командного проекта.

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

Веб-часть	Отображаемые данные	Связанный раздел
	Визуальное представление совокупного количества всех ошибок за последние четыре недели. Ошибки группируются по состоянию.	Отчет "Ход исправления ошибок" в формате Excel
	График, показывающий скользящее среднее значение количества ошибок, открытых, разрешенных и закрытых группой за последние четыре недели. Скользящее среднее вычисляется за семь дней, предшествующих дате подсчета.	Отчет "Тенденции ошибок" в формате Excel
	Визуальное представление совокупного количества всех ошибок за последние четыре недели. Группировка ошибок осуществляется по приоритету.	Отчет "Ошибки по приоритету" в формате Excel
	Горизонтальная линейчатая диаграмма с отображением совокупного количества активных ошибок, назначенных каждому участнику команды в текущий момент. Ошибки группируются по приоритету.	Отчет "Ошибки по назначению" в формате Excel
	Список активных ошибок. Этот список является производным от веб-части Team Web Access.	Книги
	Список предстоящих событий. Этот список является производным от веб-части SharePoint.	Неприменимо
	Количество активных, разрешенных и закрытых рабочих элементов. Открыть список рабочих элементов можно путем нажатия каждого номера. Этот список является производным от веб-части Team Web Access.	Неприменимо
	Список последних построений и их состояний. Для просмотра дополнительных сведений выберите конкретную сборку. Этот список является производным от веб-части Team Web Access. Условные обозначения: : Сборка не начата : Выполняется сборка : Сборка успешно завершена : Ошибка сборки : Сборка остановлена : Сборка частично успешно выполнена	Запуск сборок, наблюдение за сборками и управление ими
	Список последних возвратов. Для просмотра дополнительных сведений выберите конкретный возврат. Этот список является производным от веб-части Team Web Access.	Разработка кода и управление ожидающими изменениями

Действия, необходимые для отслеживания ошибок

Для обеспечения точности и актуальности отчетов, отображаемых на панели мониторинга "Ошибки", команда должна выполнить следующие действия.

• Определите ошибки и укажите их пути Итерация и Область.

• Назначьте каждую ошибку тому участнику команды, который работает над ее разрешением и закрытием.

• Укажите Приоритет каждой ошибки.

• Обновляйте Состояние каждой ошибки по мере ее исправления, проверки и закрытия.

Отслеживание активных ошибок и тенденций ошибок

Участники команды могут использовать панель мониторинга "Ошибки" для определения того, насколько работа с перечнем активных ошибок соответствует заданным целям команды и гибким методам работы. При помощи модульного тестирования каждого фрагмента кода перед возвратом команда может снизить общее количество ошибок, которое она должна найти. Команда, нацеленная на отправку каждого фрагмента кода, последовательно устраняет дефекты и снижает количество накапливаемых ошибок.

При помощи панели мониторинга "Ошибки" команда может находить ответы на следующие вопросы:

• Приемлемо ли количество активных ошибок для заявленных целей команды? Не откладывает ли команда слишком много ошибок на будущее?

• Соответствует ли скорость обнаружения, исправления и закрытия ошибок командой ожиданиям и предыдущим циклам разработки?

• Работает ли команда над устранением ошибок с высоким приоритетом перед устранением ошибок с более низким приоритетом?

• Требуется ли кому-либо из членов команды помощь в устранении ошибок?

Индикаторы хода исправления ошибок

Индикатор	Вопросы, которые следует задать
Диапазон активных ошибок расширяется. Если диапазон активных ошибок команды расширяется, возрастает объем невыполненной работы с ошибками. Команда обнаруживает больше ошибок, чем она может разрешить или закрыть. Расширение диапазона активных ошибок может быть признаком того, что существует определенный фактор, замедляющий работу команды по разрешению и закрытию ошибок.	Не перебрасываются ли участники команды на другие, менее приоритетные задания? Существуют ли другие факторы, снижающие способности команды по разрешению и устранению ошибок?
Количество активных ошибок не меняется. Неизменность количества активных ошибок свидетельствует о том, что команда не обнаруживает ошибки.	Охватывают ли тесты достаточный объем работ? Существуют ли другие факторы, снижающие способности команды по обнаружению ошибок?
Количество разрешенных и закрытых ошибок не меняется. Если количество ошибок, разрешаемых и закрываемых командой, остается неизменным в течение долгого времени, возможно, участники команды не способны разрешать и закрывать ошибки.	Правильно ли установлены приоритеты для команды? Не перебрасывается ли избыточное число участников команды на другие задания? Правильно ли отслеживают состояние ошибки участники команды?

Индикаторы тенденций ошибок

Индикатор	Вопросы, которые следует задать
Команда разрешает множество ошибок в каждый период. Высокое число разрешенных ошибок, как правило, указывает на высокое качество работы команды.	Быстро ли команда закрывает устраненные ошибки? Показатель закрытия должен соответствовать показателю решения ошибок. Приемлем ли показатель реактивации ошибок командой?
Команда быстро разрешает ошибки, но не закрывает их. Участники команды, назначенные для проверки исправления ошибок, возможно, недостаточно тесно сотрудничают, либо различные приоритеты не позволяют участникам команды закрывать разрешенные ошибки.	Возможно, выделены чрезмерные ресурсы для тестирования? Возможно, следует пересмотреть приоритеты тестирования? Подробнее об этих метриках читайте в разделе Панель мониторинга "Тест" (Agile и CMMI).
Команда находит мало ошибок в каждый период. Проблема обнаружения ошибок может возникать в случае высококачественного продукта или при неэффективном тестировании.	Указывают ли метрики покрытия кода, обработки кода или хода тестирования на проблему с кодом или тестированием? Подробнее об этих метриках читайте в разделе Панель мониторинга "Качество" (Agile и CMMI).
Команда находит приблизительно одинаковое количество ошибок в течение последовательных периодов. Если команда находит одинаковое количество ошибок за неделя за неделей или итерация за итерацией, следует изучить основную причину. В начале цикла тестирования тесты могут быть недостаточно строгими или тщательными, чтобы находить большое количество ошибок. На этапе ранних итераций такая ситуация соответствует ожиданиям. Тем не менее, по мере разработки продукта тесты должны использовать более широкие сценарии и интеграции.	Соответствуют ли тестовые случаи описаниям пользователей, над которыми работает команда? Возможно, тесты устарели или используются в отношении неверной функциональности? Достаточно ли тщательно группа тестирования проводит проверку каждого описания функциональности пользователей? Подробнее об этих метриках читайте в разделе Панель мониторинга "Тест" (Agile и CMMI).
Команда находит множество ошибок в каждый период. Команда легко может обнаруживать ошибки в сыром коде, в недавно интегрированном коде, при эффективном тестировании или при особых событиях, таких как ошибки "bug bash".	Указывают ли метрики покрытия кода, обработки кода или хода тестирования на проблему с кодом или тестированием? Подробнее об этих метриках читайте в разделе Панель мониторинга "Качество" (Agile и CMMI).

Приоритет и распределение ошибок

Индикатор	Вопросы, которые следует задать
Количество активных ошибок с высоким приоритетом превышает количество активных ошибок с низким приоритетом. Если количество ошибок с высоким приоритетом значительно превышает количество ошибок с низким приоритетом, возможно, команда уделяет повышенное внимание элементам с низким приоритетом.	Разрешает ли команда ошибки в установленном порядке приоритетов? Существуют ли другие факторы, снижающие способности команды по разрешению ошибок с высоким приоритетом?
Ошибки назначаются неравномерно. Возможно, команде следует рассмотреть возможность перераспределения объемов работы, если одному или двум участникам команды отводится много ошибок, а остальным участникам команды лишь небольшое их количество.	Следует ли команде сбалансировать нагрузку путем перераспределения ошибок?

См. также

Панели мониторинга портала проекта