Правильный выбор отчетности для custom-поля в work item type definition - дело, очевидно, важное, и ошибаться здесь нельзя - после того, как поле попало в TFS Warehouse, "переиграть" уже ничего не получится, придется удалять поле и создавать его по новой.
Поэтому, чтобы вам проще было сделать сразу правильный выбор, я для начала хочу на простом отвлеченном примере провести кратенький экскурс в имеющие для нас значение азы SQL Server Analysis Services.
Представим, что перед нами стоит задача - собрать и проанализировать статистику по стоимости отсылки MVP Award Kit'ов и MCP Welcome Kit'ов по всему миру. Допустим, в качестве исходных данных у нас есть:
- Страна назначения
- Дата отправки
- Тип посылки (MVP или MCP)
- Стоимость доставки посылки
Наши бизнес-аналитики хотят видеть разбиение суммарной стоимости доставки по годам, странам и типам посылок.
Для решения задачи нам нужно создать 3х мерный куб с такими размерностями (dimension):
- Страна назначения (пусть будет X)
- Дата отправки (пусть будет Y)
- Тип посылки (пусть будет Z)
Отметим: В качестве размерностей (dimension) следует использовать те поля, по которым имеет статистический смысл делать разбиение.
Возвращаясь к нашему кубу (кубы бывают, кстати, скольки угодно размерные), зададимся вопросом - а где же в нем будет фигурировать стоимость доставки? Все просто - в нашем примере суммарная стоимость доставки всех посылок, имеющихся в базе данных, заполняет объем куба целиком. А "вырезкой" из всего объема, имеющей статистическую ценность, скажем, может быть суммарная стоимость доставки MVP Award Kit'ов (по оси Z), отправленных на Украину (по оси X) в 2006 году (по оси Y).
Отметим: Величины, как правило, агрегированные, и имеющие статистическую ценность в качестве подобных "вырезок", называются мерами (measure). Забегая вперед, скажу, что единственная агрегирующая функция, реализованная в TFS - это суммирование.
Если мы хотим включить в статистический отчет дополнительные данные, скажем, номер авианакладной (airway bill) для каждой посылки, то их разумно брать непосредственно из исходной реляционной базы - непосредственно в анализе такие данные не участвуют и в куб, соответственно, не помещаются.
Собственно, описанные выше три сценария и ограничивают наш выбор отчетности для конкретного поля тремя вариантами:
- Dimension - значения поля будут откладываться на одной из координатных осей куба.
- Measure - планируется делать "вырезки" из суммы всех значений поля.
- Detail - значения поля не нужно включать в куб, в отчеты данные будут браться непосредственно из реляционной базы данных TFS.
Напоследок, примеры, более приближенные к реалиям разработки ПО.
- Мы добавляем поле Originator в work item типа Defect. Тип отчетности - скорее всего Dimension, так как нам будет интересно знать, сколько багов наплодил Вася, и сколько - Петя.
- Мы добавляем поле Overtime Work в несколько типов work items. Тип отчетности выбираем Measure, так как нас может интересовать объем сверхурочного времени за определенную итерацию или отношение овертайма, потраченного на исправление багов, к овертайму на реализацию новых фичеров.
- Мы добавляем в work item типа Change Request поле для хранения имени автора запроса. Если мы только не хотим определить самого плодовитого автора :), такое поле скорее всего будет иметь тип отчетности Detail.