Межпроектная отчетность TFS

Мы переходим на TFS и на основе онлайн-комментариев решили структурировать TFS как один проект на команду, причем каждый «настоящий проект» является областью (а каждый выпуск - итерацией).

Это означает, что наша структура TFS в чем-то похожа на:

Apps Team
  - WinForms Project
  - WPF Project
  - Embedded Project
  - WPF Project 2

Web Team
  - Admin Site
  - Client Site
  - Client Site 2

DB Team
  - General Scripts
  - DB 1
  - DB 2

Однако с точки зрения руководства анализировать отчеты каждой команды по отдельности утомительно.

Для тех, кто имеет опыт использования этой структуры, мне интересно, какой из этих вариантов (или других вариантов) вы успешно использовали?

1) Переместите все команды в один проект

  • Плюс: нет изменений в отчете.
  • Плюсы: Межкомандная осведомленность
  • Минус: беспорядок
  • Против: Возможно, безопасность

2) Сделайте все отчеты кросс-командными.

  • Плюс: команды по-прежнему могут иметь собственные проекты.
  • Против: необходимо изменять и синхронизировать все отчеты по всем проектам.
  • Против: отчеты становятся менее полезными для отдельных команд (все еще можно настраивать копии)
  • Против: команды должны использовать один и тот же шаблон процесса (для меня это не проблема)

3) Настройте проект TFS только для управления, содержащий межгрупповые отчеты

  • Pro: нужно изменить только один проект TFS
  • Pro: Ведение текущих отчетов, ориентированных на команду
  • Плюсы: Сниженный риск того, что руководство нарушит Рабочие элементы в командных проектах.
  • Против: все команды должны использовать один и тот же шаблон процесса (для меня это не проблема).

person Matt Mitchell    schedule 29.04.2011    source источник


Ответы (2)


Я создал проекты, как вы определили выше. И я настроил отчеты TFS для №2 и №3. Мысль о том, чтобы заставить команды реорганизоваться, чтобы отчеты работали, делает вариант № 1 слишком суровым для меня. №3 привлекателен, но, как и №1, ограничивает отдельные команды совместным использованием одних и тех же типов рабочих элементов и шаблонов процессов. Неизменно я попадаю в состояние 2. Особенно, если команды развивают свои процессы независимо. Я смог смягчить проблему «отчеты становятся менее полезными», вложив средства в настройку отчетов (я знаю, нетривиальное дело).

person kkelly18    schedule 29.04.2011
comment
Спасибо k2 за отзыв. Я начал делать копии стандартных отчетов для разных команд. Жаль, что структуры отчетов не поддаются этому сразу (т.е. это сложнее, чем изменить TeamProject = '' на TeamProject IN '', '') - person Matt Mitchell; 02.05.2011

Это был бы хороший кандидат для использования служб Excel в службах SharePoint. Их можно составить намного быстрее, чем настраиваемые отчеты SQL. Вы можете быстро и легко создавать межгрупповые отчеты.

На этом этапе вы можете свободно организовывать свои командные проекты и корректировать их в будущем. Фактически, вы можете обнаружить, что вам нужен TPC для каждой команды, а не просто один TPC.

person Ryan Cromwell    schedule 30.04.2011
comment
Спасибо за ответ. Excel определенно интересен и, вероятно, подходит для создания настраиваемых отчетов. Однако на данном этапе менеджменту требуются точно такие же стандартные отчеты TFS SQL для межпроектного использования. Рассматривался вариант сбора для каждой команды, но от него отказались из-за необходимости межгруппового взаимодействия (например, общие рабочие элементы / код и т. Д.) - person Matt Mitchell; 02.05.2011
comment
Вы по-прежнему можете использовать службы Reporting Services через TPC. На складе есть вся информация TPC. Отчеты служб Excel представляют собой стандартные отчеты TFS. Если вы используете SharePoint со службами Excel и настроена TFS, TFS будет создавать и использовать службы Excel для многих отчетов. Это потому, что создавать отчеты Excel проще даже для команды TFS. *** Может быть, мне стоит уточнить, что я говорю не об Excel клиентском приложении, а об Excel / services /. Это отчеты, опубликованные в Интернете. - person Ryan Cromwell; 03.05.2011