Отчеты на основе SQL Server Reporting Services, которые поставляются «из коробки» в TFS, предоставляют достаточно информации для понимания ситуации с качеством и текущими требованиями в работе. Весь список отчетов можно посмотреть здесь: https://docs.microsoft.com/en-us/vsts/report/sql-reports/reporting-services-reports. Команде конечно может хватать оперативных отчетов, которые предоставляет TFS (VSTS) на основе отчетов от запросов по рабочим элементам, цифровым панелям и т.д.: https://docs.microsoft.com/en-us/vsts/report/dashboards/overview. Но, если же нет желания предоставлять доступ к проектам и исходному коду внешним пользователям, а на это может быть достаточно причин, то можно воспользоваться отчетам SQL Server Reporting Services и Power BI. В рамках данной статьи мы рассмотрим, как можно дополнительно настроить один из стандартных отчетов SQL Server Reporting Services.
Перед настройкой отчетов необходимо проверить следующее:
- Включена ли отчетность SQL Server Reporting Services. Если нет, то ее можно подключить этими шагами: https://docs.microsoft.com/en-us/vsts/report/admin/add-reports-to-a-team-project
- Есть ли отчеты для выбранного проекта. Если нет, то можно подключить следующими шагами: https://ashamray.wordpress.com/2018/02/16/create_tfs_default_reports/
- Выбрать отчет для дополнительной настройки. В нашем случае отчет «Обзор требований» из проекта на основе шаблона CMMI, который дает полную информацию о состоянии реализации требований и их тестирования.
Рисунок 1. Пример отчета
- Выбрать инструмент для реализации изменений. Тут будем использовать SQL Server Report Builder.
- Открыть отчет через выбранный инструмент:
Рисунок 2. Открытие отчета
В открывшемся отчете мы увидим несколько разделов, но нас будет интересовать только два из них – Параметры и Наборы данных. Свойства одного из параметров можно увидеть на рисунке ниже.
Рисунок 3. Настройка параметра отчета
Параметры, которые имеет смысл настраивать:
- IncludeTasks – отображать ли дочерние задачи в отчете. По умолчанию отображаются только требования без какой-либо декомпозиции. Если необходимо отображать задачи, то в значении по умолчанию устанавливаем =1.
Рисунок 4. Включение дочерних задач
Рисунок 5. Пример работы отчета
- DisplayOwnValues – учитывать ли в трудозатратах их значение в суммарных задачах. По умолчанию установлено, что учитываются только значения конечных задач.
- DeliverableCategory – список типов рабочих элементов, которые считаются как поставляемые типы рабочих элементов. По молчанию это требования и пользовательские истории. Но если мы хотим видеть декомпозицию выше, то мы можем добавить функции:
Рисунок 6. Добавление функции в общую структуру работ
Рисунок 7. Пример работы отчета
Вышеприведенные настройки по сути позволяют немного расширить представляемую информацию. Ниже рассмотрим еще два примера:
- Включение новых задач в отчет. По умолчанию учитываются только те задачи, которые были выведены из инициирующего состояния, т.е. взяты работу и потом выполнены. Все новые задачи при работе отчета игнорируются.
- Добавление дополнительного поля в общую таблицу отчета. Отчет отбирает достаточное количество полей, например, идентификатор, тип рабочего элемента. Но иногда есть необходимость отобразить какое-то свое пользовательское поле.
Эти два примера реализуются уже на основе набора данных. В частности, выбранный отчет как основной набор данных использует dsOverview. Изменить набор данных можно с помощью кнопки Конструктор запросов, в котором запрос находится в текстовом виде.
Рисунок 8. Изменение запроса
Рисунок 9. Пример запроса
Мы не будем разбирать весь код запроса, а сосредоточимся только на решении выбранных задач.
Для того, чтобы включить в запрос новые задачи, необходимо закомментировать строки, которые отбрасывают эти задачи при построении иерархии данных. Это строка 98 в запросе:
Рисунок 10. Установка комментария вместо отбрасывания предложенных задач
Далее добавим поле, которого нет в стандартном наборе полей. По умолчанию список отбираемых полей можно посмотреть в свойствах набора данных:
Рисунок 11. Поля запроса
Выполним пример на основе поля Приоритет. Для начала необходимо узнать, как поле называется в общей отчетной базе данных. Сделать это можно, создав новый набор данных и подключив источник данных TfsReportsDS:
Рисунок 12. Создание нового набора данных
В конструкторе запроса необходимо выбрать представление CurrentWorkItemView и найти необходимое поле (Microsoft_VSTS_Common_Priority). Как правило, названия колонок для полей, которые подвергаются отчетности, именуются также как свойство Reference Name с заменой точек на подчеркивания.
Рисунок 13. Поле Важность
Далее необходимо «провести» отбор данного поля через все промежуточные таблицы, которые создаются при обработке данных в отчете. Это нужно сделать в следующих строках:
- Добавить дополнительную колонку в таблицу Rollups (строка 227)
Рисунок 14. Новая колонка для отбора приоритета
- Добавить извлечение поля приоритета (строка 259):
Рисунок 15. Получение приоритета из представления
- Добавить столбец при обработке собственных значений (строка 390):
Рисунок 16. Добавление приоритета для собственных значений
- Добавить колонку при создании результирующего набора данных (строка 431):
Рисунок 17. Добавление приоритета в результирующие данные
После сохранения запроса необходимо добавить новый столбец в таблицу отчета и выбрать новое поле как отображаемое значение:
Рисунок 18. Добавление нового столбца таблицу отчета
Рисунок 19. Назначение в столбец поля приоритета
Кроме этого можно поправить форматирование, чтоб поле приоритета не выстраивалось в виде дерева.
Рисунок 20. Вызов свойства поля
Рисунок 21. Исправление отступа
Сохраняем изменения и в результате получим следующий вид:
Рисунок 22. Рабочий отчет
Заметки консультанта 