Командная разработка с использованием Visual Studio Team Foundation Server

Введение в управление проектами

Разбить на страницы
Показывать лекцию целиком

Обзор

Эта лекция познакомит вас с возможностями управления проектами из арсенала Visual Studio Team System. Вы узнаете, как с их помощью решать типичные проблемы и задачи, возникающие при управлении проектами по разработке ПО.

В Visual Studio Team System и Team Foundation Server (TFS) включены инструменты, шаблоны и отчеты, помогающие отслеживать и поддерживать процессы разработки ПО. Они упрощают обмен информацией в рамках команды, автоматизируют передачу необходимых данных различным членам команды, упрощают распределение и отслеживание рабочих элементов, например, задач, облегчают контроль за показателями состояния проекта.

Введение в управление проектами

Планирование проектов обычно выполняется по следующей схеме:

  • Концептуальное описание проекта На этом этапе формируется представление о том, какой конечный результат проекта хотят получить все заинтересованные стороны.
  • Формулирование сценариев На этом этапе с участием заказчика формулируется начальный набор сценариев использования ПО. Заказчик оценивает готовые сценарии с позиции собственных интересов.
  • Формирование набора функциональных возможностей для реализации выбранных сценариев На этом этапе сценарии разбиваются на отдельные компоненты, важные с точки зрения заказчика. Благодаря этому появляется возможность обсуждать ожидания заказчика в отношении этих компонентов.
  • Формирование набора рабочих элементов Сценарии и компоненты разбиваются на конкретные задачи. Завершение рабочего элемента означает реализацию соответствующей функции или сценария.
  • Распределение задач по областям Области выделяются на основе компонентов или в зависимости от организации конкретной команды.
  • Создание плана работ На этом этапе либо составляется полный график выполнения работ, либо производится разбиение работы на итерации.
    •

    Типичные проблемы управления проектами

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

  • Работа с разрозненными источниками информации Инструменты для управления проектами обычно используются изолированно, что приводит к появлению разрозненных источников информации, которые не так просто объединить. Кроме того, обычно бывает сложно объединить данные по управлению проектом с данными, предоставляемыми другими членами команды, например, учесть при формировании показателей ошибки, выявленные изолированной системой отслеживания ошибок.
  • Сложности со сбором показателей проекта Показатели проекта очень важны для контроля за его состоянием, принятия обоснованных решений и получения ответа на фундаментальные вопросы, например, "Будет ли проект поставлен вовремя и будет ли выполнен бюджет?". Отвечая на ключевые вопросы, руководитель проекта обычно полагается на данные Microsoft Office Project или системы отслеживания ошибок, используемой группами разработки и тестирования. Объединить данные, предоставляемые этими несопоставимыми системами, сложно, на это уходит много времени, к тому же, в процессе сведения данных легко допустить ошибки. Для большинства показателей, формируемых инструментарием, не существует унифицированной системы хранения и доступа. Создание отчетов - это обычно напряженный ручной труд, связанный с многократным копированием и вставкой информации из разных источников.
  • Сложности с выполнением требований Зачастую работа, запланированная для группы разработки, требования заказчика и основные нефункциональные требования к создаваемой системе существенно отличаются друг от друга. Еще одна "пропасть" разделяет запланированный и фактический объемы. Из-за этих несоответствий теряются важные данные, что приводит к невыполнению требований.
  • Управление процессами и изменения в них Объяснить команде, каких процессов она должна придерживаться, очень сложно. Еще сложнее, не снизив производительности команды, внести изменения в процессы для решения возникающих проблем.
  • Недостаток учитываемого обмена информацией и отслеживания задач Взаимодействие и слаженность команды обычно обеспечиваются при помощи совещаний и списков задач, позволяющих правильно выбрать приоритеты. Отслеживать процесс выполнения отдельной задачи может быть очень сложно. Также руководители проектов часто тратят массу ценного времени на извлечение информации о состоянии работ из разных планов и списков. Члены команды тратят время на отчеты о состоянии и обновление различных документов и форм.
  • Контроль качества Предсказать количество и серьезность ошибок в создаваемом ПО сложно, поэтому обычно плановые оценки и затраты основываются на "оптимистических предположениях". Эти оценки традиционно делаются с запасом, величина которого зависит от степени уверенности руководителя в текущем состоянии проекта.
    •

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

    Функции управления проектами в Team Foundation Server

    Основные функции Visual Studio Team System по управлению проектами таковы:

  • Управление процессами Система управления процессами Team Foundation Server включает руководство по процессу Microsoft Solution Framework (MSF) , а также шаблоны процессов, благодаря которым новые командные проекты обеспечены типами рабочих элементов, отчетами, порталом проекта SharePoint и настройками системы управления исходным кодом.
  • Безопасность и разрешения В новые проекты включены стандартные группы и разрешения, соответствующие типичным ролям команды разработки.
  • Централизованное управление рабочими элементами Рабочие элементы, в том числе ошибки, риски, задачи, сценарии и требования к качеству обслуживания ( quality of service, QoS ), централизованно регистрируются, управляются и обслуживаются в БД рабочих элементов TFS. Централизованное хранение упрощает доступ и просмотр этих элементов всеми членами команды.
  • Интеграция с Microsoft Office Excel® и Microsoft Office Project Благодаря интеграции с Office Excel и Office Project руководители проектов могут работать с хранилищем рабочих элементов и расписанием, используя хорошо знакомые инструменты.
  • Показатели и составление отчетов В TFS включена возможность создания и отображения отчетов, которые превращают рабочие данные, например, рабочие элементы, результаты сборки и результаты тестирования, в показатели, хранящиеся в хранилище данных TFS. Благодаря встроенным отчетам у вас есть возможность запрашивать разнообразные показатели состояния и качества проекта.
  • Порталы проекта Для каждого командного проекта TFS создает ассоциированный портал Microsoft Windows SharePoint®. Портал используется для управления документацией проекта, быстрого просмотра ключевых отчетов и оценки текущего состояния проекта.
    •

    Преимущества

    Управляя проектами из TFS, вы получаете следующие преимущества:

  • централизованное управление;
  • возможность отслеживать взаимосвязи рабочих элементов;
  • интегрированное планирование и составление графика проекта;
  • расширенные возможности управления процессами;
  • расширенные возможности обмена информацией и взаимодействия внутри команды;
  • подробные отчеты о ходе выполнения работ.
    •

    Создание проектов и управление ими в Team Foundation Server

    В целом, создание проекта в Team Foundation Server разделяется на следующие этапы:

  • Выбор шаблона процесса Можно использовать стандартный шаблон или создать собственный.
  • Создание командного проекта В основу проекта ляжет выбранный шаблон.
  • Добавление в командный проект групп и членов.
  • Разработка итерационного цикла проекта Включает создание итераций.
  • Преобразование сценариев в рабочие элементы TFS.
  • Выбор сценариев, которые должны быть завершены в каждой итерации.
  • Определение требований QoS Связывание требований со сценариями.
  • Разбиение сценариев с целью обеспечить разработчиков управляемыми рабочими элементами Разработчики предварительно оценивают сроки выполнения для каждого рабочего элемента.
  • Создание графика проекта График создается средствами Microsoft Project и добавляется в Team Project.
  • Определение критериев приемки Критерии завершенности рабочих элементов согласовываются с требованиями QoS.
  • Определение требований к отчетам Определяются ключевые показатели выполнения проекта и оговариваются требования к отчетам.
    •

    Подробнее о создании и управлении проектом рассказывается в разделе "Как управлять проектами в Visual Studio Team Foundation Server " этой книги.

    Стратегии командных проектов

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

    Выбирая структуру командного проекта, необходимо руководствоваться требованиями к ПО. Структура проекта может меняться в процессе работы. Существует три основных стратегии создания нового проекта, которые могут использоваться по отдельности или в сочетании друг с другом:

  • один проект на приложение ;
  • один проект на выпускаемую версию ;
  • один проект на команду.
    •

    Один проект на приложение

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

    Один проект на выпускаемую версию

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

    Один проект на команду

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

    Управление процессами

    Благодаря VSTS управление циклом разработки ПО стало неотъемлемой частью инструментария для его разработки. Благодаря тому что процессы цикла разработки интегрированы в VSTS, обмен рабочими элементами между членами команды можно в значительной степени автоматизировать.

    Шаблоны процессов

    В VSTS для определения набора инструкций и артефактов, например, руководств по процессу, шаблонов документов, стандартных рабочих элементов и т. д., используются шаблоны процессов. Шаблон процесса - это независимый набор инструкций, описывающих методологию разработки ПО для команд разработчиков. В шаблон процесса включаются следующие элементы:

  • Руководство по процессу Предоставляется для каждого шаблона и содержит контекстно-зависимую информацию, справку и указания членам команды, нуждающимся в помощи и понимании определенной деятельности. Руководство по выполнению процесса интегрировано в Visual Studio Help System.
  • Шаблоны документов Позволяют членам команды единообразно создавать новые документы (спецификации, оценки рисков и планы проектов).
  • Рабочие элементы и последовательность операций У рабочих элементов имеется собственный набор полей и правил, определяющих последовательность операций рабочего элемента и распределение работ между членами команды.
  • Группы безопасности Используются для определения прав по управлению и изменению отчетов, результатов работы, например, исходного кода и документации, и рабочих элементов. Администрировать группы безопасности проекта может его руководитель, для этого ему не обязательно быть администратором Windows.
  • Политики возврата после правки Используются для применения правил и порогов качества ко всему коду, возвращаемому в систему управления исходным кодом. Например, можно поставить условие, что весь возвращаемый код должен отвечать определенному критерию, скажем, соответствовать корпоративным стандартам написания кода, или должен подвергаться модульному тестированию. Более подробно о создании и настройке политик возврата изменений рассказывается в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server ".
  • Отчеты Используются для мониторинга исполнения процессов и текущего состояния проекта. В VSTS встроено множеством отчетов, включая отчеты о качестве кода, о соблюдении графика работ, об эффективности тестирования и др. Можно создавать собственные отчеты и настраивать существующие.
    •

    Шаблоны процессов MSF Agile и MSF CMMI

    В комплекте VSTS поставляются два шаблона процессов:

  • MSF for Agile Software Development Простой шаблон для небольших или неформальных проектов по разработке ПО. Он основывается на сценариях и действиях по обстоятельствам. Ориентирован на конкретный проект и его исполнителей.
  • MSF for CMMI® Process Improvement Предназначен для более серьезных проектов по разработке ПО. Расширяет функциональность шаблона MSF Agile, предоставляя поддержку аудита, верификации и формальных процессов, опираясь на процесс и соответствие процессу. Ориентирован на организацию.
    •

    Если предоставляемые шаблоны недостаточно отражают требования конкретного процесса и методологии, добавьте в систему новые шаблоны или настройте стандартные. Подробнее о настройке шаблонов рассказывается в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server ".

    Безопасность и разрешения

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

  • Project Administrator - администратор проекта;
  • Contributor - участник;
  • Reader - читатель;
  • Build Services - сервисы сборки.
    •

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

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

    Управление рабочими элементами

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

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

    В шаблонах MSF Agile и MSF CMMI предусмотрен стандартный набор рабочих элементов с задачами, достаточными для начала процесса разработки ПО.

    Шаблон MSF Agile

    В этом шаблоне имеются следующие типы рабочих элементов:

  • Сценарий ( scenario ) Используется для представления взаимодействия пользователя с приложением. Описывает конкретные шаги, необходимые для достижения цели. Сценарии должны быть конкретными, поскольку возможных способов действия может быть несколько.
  • Задача ( task ) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
  • Требование QoS ( Quality of Service requirement ) Документирует характеристики системы, например, производительность, нагрузку, доступность, устойчивость к нештатным условиям эксплуатации, специальные возможности и удобство обслуживания.
  • Ошибка ( bug ) Используется для информирования о потенциальной проблеме в системе.
  • Риск ( risk ) Используется для выявления и управления рисками в проекте.
    •

    Шаблон MSF CMMI

    В этом шаблоне имеются следующие типы рабочих элементов:

  • Требование ( requirement ) Фиксирует требования, определенные на этапе сбора требований.
  • Запрос на изменение ( change request ) Фиксирует любые запросы на внесение изменений, возникающие после этапа сбора требований.
  • Проблема ( issue ) Проблемы, исправление которых необходимо отслеживать.
  • Задача ( task ) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
  • Рецензия ( review ) Блок работы по составлению отзывов, например, рецензии исходного кода, проекта и пр.
  • Ошибка ( bug ) Используется для информирования о потенциальной проблеме в системе.
  • Риск ( risk ) Используется для выявления и управления рисками в проекте.
    •

    Интеграция с Microsoft Project

    В VSTS и приложении Team Explorer имеются расширения для Microsoft Project. В крупных проектах, где задействовано большое количество ресурсов, для работы с графиком работ по проекту в TFS можно использовать Microsoft Office Project. Можно, например, управлять и планировать работы, назначать их, распределять и отслеживать, а затем, когда результаты готовы к использованию другими членами команды, публиковать их в базе данных рабочих элементов.

    Подробнее об этом - в статье "Working with Work Items in Microsoft Project" по адресу http://msdn2.microsoft.com/en-us/library/ms244368(VS.80). aspx.

    Интеграция с Microsoft Excel

    В VSTS и приложении Team Explorer имеются расширения для Microsoft Excel. В крупных проектах, где задействовано большое количество рабочих элементов, можно использовать интеграцию с Excel: создавать рабочие элементы в электронной таблице Excel и загружать их в базу данных рабочих элементов для использования другими членами команды.

    Подробнее - в статье "Working with Work Item Lists in Microsoft Excel" по адресу http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx.

    Контроль выполнения работ и отчеты

    Отчеты из комплекта TFS помогут вам оперативно оценить состояние проекта, качество разрабатываемого ПО и этап, на котором находится проект. Отчеты формируются на основе данных из хранилища TFS и объединяют показатели, поступающие от рабочих элементов, системы управления исходным кодом, тестирования и сборок.

    Например, с помощью отчетов можно выяснить темпы работы команды на основании ее фактической деятельности. Задача системы создания и отображения отчетов TFS - предоставить вам интегрированные данные по всем компонентам VSTS, чтобы руководители проекта и члены команды могли оценить состояние проекта и предпринять соответствующие действия для его успешного выполнения.

    Отчеты, доступные по умолчанию, определяются используемым шаблоном проекта, но существует также возможность создания собственных отчетов. Содержимое и использование каждого отчета из шаблона процесса, объясняется в руководстве для этого шаблона. Team Foundation Server основан на Microsoft SQL Server™ 2005 и использует SQL Server для хранения всех данных, связанных с рабочими элементами, атрибутами качества, тестированием, результатами тестирования и результатами сборок. Для объединения и анализа этих данных и создания отчетов в TFS используются службы SQL Server Analysis Services. Отчеты, созданные шаблоном процесса или отдельными членами команды с помощью Microsoft Office Excel или Visual Studio 2005 Report Designer, доступны при помощи SQL Server 2005 Reporting Services и портала SharePoint команды.

    Подробнее о настройке отчетов - в разделе "Как создать собственный отчет в Visual Studio 2005 Team Foundation Server" этой книги.

    Резюме

    Team Foundation Server предоставляет такие возможности управления проектами, как централизованное управление рабочими элементами, управление процессами, управление безопасностью и разрешениями, сбор показателей проекта и составление отчетов. Все это упрощает управление проектами по разработке ПО средствами Visual Studio.

    Управление циклом разработки ПО стало неотъемлемой частью инструментария для разработки ПО. В TFS включены шаблоны процессов MSF Agile и MSF CMMI, поддерживающие две разные методики разработки. Можно изменять предоставляемые шаблоны процессов или создать собственный шаблон, удовлетворяющий потребностям конкретной команды.

    Дополнительные ресурсы

  • Подробнее об управлении и организации проектов по разработке ПО с использованием .
  • Более подробную информацию об использовании .
  • Более подробную информацию об использовании .
    •
    Страницы:

    Обзор

    Эта лекция познакомит вас с возможностями управления проектами из арсенала Visual Studio Team System. Вы узнаете, как с их помощью решать типичные проблемы и задачи, возникающие при управлении проектами по разработке ПО.

    В Visual Studio Team System и Team Foundation Server (TFS) включены инструменты, шаблоны и отчеты, помогающие отслеживать и поддерживать процессы разработки ПО. Они упрощают обмен информацией в рамках команды, автоматизируют передачу необходимых данных различным членам команды, упрощают распределение и отслеживание рабочих элементов, например, задач, облегчают контроль за показателями состояния проекта.

    Введение в управление проектами

    Планирование проектов обычно выполняется по следующей схеме:

  • Концептуальное описание проекта На этом этапе формируется представление о том, какой конечный результат проекта хотят получить все заинтересованные стороны.
  • Формулирование сценариев На этом этапе с участием заказчика формулируется начальный набор сценариев использования ПО. Заказчик оценивает готовые сценарии с позиции собственных интересов.
  • Формирование набора функциональных возможностей для реализации выбранных сценариев На этом этапе сценарии разбиваются на отдельные компоненты, важные с точки зрения заказчика. Благодаря этому появляется возможность обсуждать ожидания заказчика в отношении этих компонентов.
  • Формирование набора рабочих элементов Сценарии и компоненты разбиваются на конкретные задачи. Завершение рабочего элемента означает реализацию соответствующей функции или сценария.
  • Распределение задач по областям Области выделяются на основе компонентов или в зависимости от организации конкретной команды.
  • Создание плана работ На этом этапе либо составляется полный график выполнения работ, либо производится разбиение работы на итерации.
    •

    Типичные проблемы управления проектами

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

  • Работа с разрозненными источниками информации Инструменты для управления проектами обычно используются изолированно, что приводит к появлению разрозненных источников информации, которые не так просто объединить. Кроме того, обычно бывает сложно объединить данные по управлению проектом с данными, предоставляемыми другими членами команды, например, учесть при формировании показателей ошибки, выявленные изолированной системой отслеживания ошибок.
  • Сложности со сбором показателей проекта Показатели проекта очень важны для контроля за его состоянием, принятия обоснованных решений и получения ответа на фундаментальные вопросы, например, "Будет ли проект поставлен вовремя и будет ли выполнен бюджет?". Отвечая на ключевые вопросы, руководитель проекта обычно полагается на данные Microsoft Office Project или системы отслеживания ошибок, используемой группами разработки и тестирования. Объединить данные, предоставляемые этими несопоставимыми системами, сложно, на это уходит много времени, к тому же, в процессе сведения данных легко допустить ошибки. Для большинства показателей, формируемых инструментарием, не существует унифицированной системы хранения и доступа. Создание отчетов - это обычно напряженный ручной труд, связанный с многократным копированием и вставкой информации из разных источников.
  • Сложности с выполнением требований Зачастую работа, запланированная для группы разработки, требования заказчика и основные нефункциональные требования к создаваемой системе существенно отличаются друг от друга. Еще одна "пропасть" разделяет запланированный и фактический объемы. Из-за этих несоответствий теряются важные данные, что приводит к невыполнению требований.
  • Управление процессами и изменения в них Объяснить команде, каких процессов она должна придерживаться, очень сложно. Еще сложнее, не снизив производительности команды, внести изменения в процессы для решения возникающих проблем.
  • Недостаток учитываемого обмена информацией и отслеживания задач Взаимодействие и слаженность команды обычно обеспечиваются при помощи совещаний и списков задач, позволяющих правильно выбрать приоритеты. Отслеживать процесс выполнения отдельной задачи может быть очень сложно. Также руководители проектов часто тратят массу ценного времени на извлечение информации о состоянии работ из разных планов и списков. Члены команды тратят время на отчеты о состоянии и обновление различных документов и форм.
  • Контроль качества Предсказать количество и серьезность ошибок в создаваемом ПО сложно, поэтому обычно плановые оценки и затраты основываются на "оптимистических предположениях". Эти оценки традиционно делаются с запасом, величина которого зависит от степени уверенности руководителя в текущем состоянии проекта.
    •

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

    Функции управления проектами в Team Foundation Server

    Основные функции Visual Studio Team System по управлению проектами таковы:

  • Управление процессами Система управления процессами Team Foundation Server включает руководство по процессу Microsoft Solution Framework (MSF) , а также шаблоны процессов, благодаря которым новые командные проекты обеспечены типами рабочих элементов, отчетами, порталом проекта SharePoint и настройками системы управления исходным кодом.
  • Безопасность и разрешения В новые проекты включены стандартные группы и разрешения, соответствующие типичным ролям команды разработки.
  • Централизованное управление рабочими элементами Рабочие элементы, в том числе ошибки, риски, задачи, сценарии и требования к качеству обслуживания ( quality of service, QoS ), централизованно регистрируются, управляются и обслуживаются в БД рабочих элементов TFS. Централизованное хранение упрощает доступ и просмотр этих элементов всеми членами команды.
  • Интеграция с Microsoft Office Excel® и Microsoft Office Project Благодаря интеграции с Office Excel и Office Project руководители проектов могут работать с хранилищем рабочих элементов и расписанием, используя хорошо знакомые инструменты.
  • Показатели и составление отчетов В TFS включена возможность создания и отображения отчетов, которые превращают рабочие данные, например, рабочие элементы, результаты сборки и результаты тестирования, в показатели, хранящиеся в хранилище данных TFS. Благодаря встроенным отчетам у вас есть возможность запрашивать разнообразные показатели состояния и качества проекта.
  • Порталы проекта Для каждого командного проекта TFS создает ассоциированный портал Microsoft Windows SharePoint®. Портал используется для управления документацией проекта, быстрого просмотра ключевых отчетов и оценки текущего состояния проекта.
    •

    Преимущества

    Управляя проектами из TFS, вы получаете следующие преимущества:

  • централизованное управление;
  • возможность отслеживать взаимосвязи рабочих элементов;
  • интегрированное планирование и составление графика проекта;
  • расширенные возможности управления процессами;
  • расширенные возможности обмена информацией и взаимодействия внутри команды;
  • подробные отчеты о ходе выполнения работ.
    •

    Создание проектов и управление ими в Team Foundation Server

    В целом, создание проекта в Team Foundation Server разделяется на следующие этапы:

  • Выбор шаблона процесса Можно использовать стандартный шаблон или создать собственный.
  • Создание командного проекта В основу проекта ляжет выбранный шаблон.
  • Добавление в командный проект групп и членов.
  • Разработка итерационного цикла проекта Включает создание итераций.
  • Преобразование сценариев в рабочие элементы TFS.
  • Выбор сценариев, которые должны быть завершены в каждой итерации.
  • Определение требований QoS Связывание требований со сценариями.
  • Разбиение сценариев с целью обеспечить разработчиков управляемыми рабочими элементами Разработчики предварительно оценивают сроки выполнения для каждого рабочего элемента.
  • Создание графика проекта График создается средствами Microsoft Project и добавляется в Team Project.
  • Определение критериев приемки Критерии завершенности рабочих элементов согласовываются с требованиями QoS.
  • Определение требований к отчетам Определяются ключевые показатели выполнения проекта и оговариваются требования к отчетам.
    •

    Подробнее о создании и управлении проектом рассказывается в разделе "Как управлять проектами в Visual Studio Team Foundation Server " этой книги.

    Стратегии командных проектов

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

    Выбирая структуру командного проекта, необходимо руководствоваться требованиями к ПО. Структура проекта может меняться в процессе работы. Существует три основных стратегии создания нового проекта, которые могут использоваться по отдельности или в сочетании друг с другом:

  • один проект на приложение ;
  • один проект на выпускаемую версию ;
  • один проект на команду.
    •

    Один проект на приложение

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

    Один проект на выпускаемую версию

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

    Один проект на команду

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

    Управление процессами

    Благодаря VSTS управление циклом разработки ПО стало неотъемлемой частью инструментария для его разработки. Благодаря тому что процессы цикла разработки интегрированы в VSTS, обмен рабочими элементами между членами команды можно в значительной степени автоматизировать.

    Шаблоны процессов

    В VSTS для определения набора инструкций и артефактов, например, руководств по процессу, шаблонов документов, стандартных рабочих элементов и т. д., используются шаблоны процессов. Шаблон процесса - это независимый набор инструкций, описывающих методологию разработки ПО для команд разработчиков. В шаблон процесса включаются следующие элементы:

  • Руководство по процессу Предоставляется для каждого шаблона и содержит контекстно-зависимую информацию, справку и указания членам команды, нуждающимся в помощи и понимании определенной деятельности. Руководство по выполнению процесса интегрировано в Visual Studio Help System.
  • Шаблоны документов Позволяют членам команды единообразно создавать новые документы (спецификации, оценки рисков и планы проектов).
  • Рабочие элементы и последовательность операций У рабочих элементов имеется собственный набор полей и правил, определяющих последовательность операций рабочего элемента и распределение работ между членами команды.
  • Группы безопасности Используются для определения прав по управлению и изменению отчетов, результатов работы, например, исходного кода и документации, и рабочих элементов. Администрировать группы безопасности проекта может его руководитель, для этого ему не обязательно быть администратором Windows.
  • Политики возврата после правки Используются для применения правил и порогов качества ко всему коду, возвращаемому в систему управления исходным кодом. Например, можно поставить условие, что весь возвращаемый код должен отвечать определенному критерию, скажем, соответствовать корпоративным стандартам написания кода, или должен подвергаться модульному тестированию. Более подробно о создании и настройке политик возврата изменений рассказывается в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server ".
  • Отчеты Используются для мониторинга исполнения процессов и текущего состояния проекта. В VSTS встроено множеством отчетов, включая отчеты о качестве кода, о соблюдении графика работ, об эффективности тестирования и др. Можно создавать собственные отчеты и настраивать существующие.
    •

    Шаблоны процессов MSF Agile и MSF CMMI

    В комплекте VSTS поставляются два шаблона процессов:

  • MSF for Agile Software Development Простой шаблон для небольших или неформальных проектов по разработке ПО. Он основывается на сценариях и действиях по обстоятельствам. Ориентирован на конкретный проект и его исполнителей.
  • MSF for CMMI® Process Improvement Предназначен для более серьезных проектов по разработке ПО. Расширяет функциональность шаблона MSF Agile, предоставляя поддержку аудита, верификации и формальных процессов, опираясь на процесс и соответствие процессу. Ориентирован на организацию.
    •

    Если предоставляемые шаблоны недостаточно отражают требования конкретного процесса и методологии, добавьте в систему новые шаблоны или настройте стандартные. Подробнее о настройке шаблонов рассказывается в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server ".

    Безопасность и разрешения

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

  • Project Administrator - администратор проекта;
  • Contributor - участник;
  • Reader - читатель;
  • Build Services - сервисы сборки.
    •

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

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

    Управление рабочими элементами

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

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

    В шаблонах MSF Agile и MSF CMMI предусмотрен стандартный набор рабочих элементов с задачами, достаточными для начала процесса разработки ПО.

    Шаблон MSF Agile

    В этом шаблоне имеются следующие типы рабочих элементов:

  • Сценарий ( scenario ) Используется для представления взаимодействия пользователя с приложением. Описывает конкретные шаги, необходимые для достижения цели. Сценарии должны быть конкретными, поскольку возможных способов действия может быть несколько.
  • Задача ( task ) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
  • Требование QoS ( Quality of Service requirement ) Документирует характеристики системы, например, производительность, нагрузку, доступность, устойчивость к нештатным условиям эксплуатации, специальные возможности и удобство обслуживания.
  • Ошибка ( bug ) Используется для информирования о потенциальной проблеме в системе.
  • Риск ( risk ) Используется для выявления и управления рисками в проекте.
    •

    Шаблон MSF CMMI

    В этом шаблоне имеются следующие типы рабочих элементов:

  • Требование ( requirement ) Фиксирует требования, определенные на этапе сбора требований.
  • Запрос на изменение ( change request ) Фиксирует любые запросы на внесение изменений, возникающие после этапа сбора требований.
  • Проблема ( issue ) Проблемы, исправление которых необходимо отслеживать.
  • Задача ( task ) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
  • Рецензия ( review ) Блок работы по составлению отзывов, например, рецензии исходного кода, проекта и пр.
  • Ошибка ( bug ) Используется для информирования о потенциальной проблеме в системе.
  • Риск ( risk ) Используется для выявления и управления рисками в проекте.
    •

    Интеграция с Microsoft Project

    В VSTS и приложении Team Explorer имеются расширения для Microsoft Project. В крупных проектах, где задействовано большое количество ресурсов, для работы с графиком работ по проекту в TFS можно использовать Microsoft Office Project. Можно, например, управлять и планировать работы, назначать их, распределять и отслеживать, а затем, когда результаты готовы к использованию другими членами команды, публиковать их в базе данных рабочих элементов.

    Подробнее об этом - в статье "Working with Work Items in Microsoft Project" по адресу http://msdn2.microsoft.com/en-us/library/ms244368(VS.80). aspx.

    Интеграция с Microsoft Excel

    В VSTS и приложении Team Explorer имеются расширения для Microsoft Excel. В крупных проектах, где задействовано большое количество рабочих элементов, можно использовать интеграцию с Excel: создавать рабочие элементы в электронной таблице Excel и загружать их в базу данных рабочих элементов для использования другими членами команды.

    Подробнее - в статье "Working with Work Item Lists in Microsoft Excel" по адресу http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx.

    Контроль выполнения работ и отчеты

    Отчеты из комплекта TFS помогут вам оперативно оценить состояние проекта, качество разрабатываемого ПО и этап, на котором находится проект. Отчеты формируются на основе данных из хранилища TFS и объединяют показатели, поступающие от рабочих элементов, системы управления исходным кодом, тестирования и сборок.

    Например, с помощью отчетов можно выяснить темпы работы команды на основании ее фактической деятельности. Задача системы создания и отображения отчетов TFS - предоставить вам интегрированные данные по всем компонентам VSTS, чтобы руководители проекта и члены команды могли оценить состояние проекта и предпринять соответствующие действия для его успешного выполнения.

    Отчеты, доступные по умолчанию, определяются используемым шаблоном проекта, но существует также возможность создания собственных отчетов. Содержимое и использование каждого отчета из шаблона процесса, объясняется в руководстве для этого шаблона. Team Foundation Server основан на Microsoft SQL Server™ 2005 и использует SQL Server для хранения всех данных, связанных с рабочими элементами, атрибутами качества, тестированием, результатами тестирования и результатами сборок. Для объединения и анализа этих данных и создания отчетов в TFS используются службы SQL Server Analysis Services. Отчеты, созданные шаблоном процесса или отдельными членами команды с помощью Microsoft Office Excel или Visual Studio 2005 Report Designer, доступны при помощи SQL Server 2005 Reporting Services и портала SharePoint команды.

    Подробнее о настройке отчетов - в разделе "Как создать собственный отчет в Visual Studio 2005 Team Foundation Server" этой книги.

    Резюме

    Team Foundation Server предоставляет такие возможности управления проектами, как централизованное управление рабочими элементами, управление процессами, управление безопасностью и разрешениями, сбор показателей проекта и составление отчетов. Все это упрощает управление проектами по разработке ПО средствами Visual Studio.

    Управление циклом разработки ПО стало неотъемлемой частью инструментария для разработки ПО. В TFS включены шаблоны процессов MSF Agile и MSF CMMI, поддерживающие две разные методики разработки. Можно изменять предоставляемые шаблоны процессов или создать собственный шаблон, удовлетворяющий потребностям конкретной команды.

    Дополнительные ресурсы

  • Подробнее об управлении и организации проектов по разработке ПО с использованием .
  • Более подробную информацию об использовании .
  • Более подробную информацию об использовании .
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^