Спонсор: Microsoft
Опубликован: 25.03.2010 | Доступ: свободный | Студентов: 810 / 26 | Оценка: 4.43 / 3.71 | Длительность: 10:46:00
Дополнительный материал 4:

Практикум

Как управлять проектами в Visual Studio Team Foundation Server

Область применения

  • Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) .
  • Microsoft Visual Studio Team System (VSTS) .

Описание

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

Содержание

  • Задачи.
  • Обзор.
  • Порядок операций.
  • Прежде всего.
  • Шаг 1 - выбор шаблона процесса.
  • Шаг 2 - создание командного проекта.
  • Шаг 3 - создание групп доступа (при необходимости).
  • Шаг 4 - добавление членов команды в Team Foundation Server.
  • Шаг 5 - определение итерационного цикла.
  • Шаг 6 - описание сценариев проекта в TFS.
  • Шаг 7 - выбор сценариев для итерации.
  • Шаг 8 - определение требований QoS.
  • Шаг 9 - планирование итерации.
  • Шаг 10 - отслеживание процесса разработки.
  • Рекомендации по работе с областями и итерациями.
  • Дополнительные ресурсы.

Задачи

  • Научиться создавать командные проекты в TFS.
  • Научиться управлять проектами в TFS.

Обзор

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

В этой статье последовательно рассматривается процесс работы с командным проектом, начиная с создания и настройки нового проекта до контроля за его выполнением.

Порядок операций

  • Шаг 1 - выбор шаблона процесса.
  • Шаг 2 - создание командного проекта.
  • Шаг 3 - создание групп доступа (при необходимости).
  • Шаг 4 - добавление членов команды в Team Foundation Server.
  • Шаг 5 - определение итерационного цикла.
  • Шаг 6 - описание сценариев проекта в TFS.
  • Шаг 7 - выбор сценариев для итерации.
  • Шаг 8 - определение требований QoS.
  • Шаг 9 - планирование итерации.
  • Шаг 10 - отслеживание процесса разработки.

Прежде всего

Прежде чем приступать к созданию нового командного проекта, необходимо собрать следующую информацию:

  • Процесс, который будет использован в проекте От выбора процесса зависит выбор шаблона, на основе которого будет создан новый командный проект. Проанализировав процесс, вы также оцените, насколько сильно придется изменять поставляемые стандартные шаблоны. Если вы предпочитаете гибкий стиль выполнения проекта, выбирайте шаблон MSF Agile.
  • Имя проекта Тщательно продумайте соглашение о присвоении имен командным проектам. Проследите, чтобы имена проектов были достаточно уникальны и чтобы другие пользователи могли без труда найти проект по имени. В некоторых организациях в имя проекта включают его код проекта, в других используют сочетание названия отдела и заголовка проекта.
  • Структура системы управления исходным кодом Подумайте, начнете ли вы свой проект с пустого дерева исходного кода или возьмете за основу уже существующий исходный код. Разрабатывайте структуру исходного кода на основе требований к коду и ветвлению. Дополнительную информацию по этому вопросу вы найдете в статье "Как структурировать папки управления исходным кодом в Visual Studio Team Foundation Server ".

Шаг 1 - выбор шаблона процесса

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

  • MSF for Agile Software Development (MSF Agile) Простой шаблон процесса для небольших, срочных или неформальных проектов по разработке ПО. Он основывается на сценариях и управляемых контекстом действиях. Ориентирован на проект и членов группы.
  • MSF for CMMI® Process Improvement (MSF CMMI) Шаблон процесса для более серьезных проектов по разработке ПО. Он расширяет функциональность шаблона MSF Agile, предоставляя поддержку аудита, верификации и формальных процессов. Ориентирован на процесс, на соответствие процессу и на организацию.
  • В случае необходимости стандартные шаблоны можно настраивать, чтобы они максимально соответствовали вашим процессам. Настройке шаблонов процессов посвящен раздел "Как настроить шаблон процесса в Visual Studio Team Foundation Server ". В дальнейшем предполагается, что выбран шаблон MSF Agile.

Шаг 2 - создание командного проекта

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

  1. Убедитесь, что Visual Studio соединена с экземпляром TFS.
  2. В Team Explorer щелкните правой кнопкой мыши сервер и выберите New Team Project.
  3. На первой странице мастера New Project Creation Wizard введите имя командного проекта и щелкните Next.
  4. На странице Select a Process Template из раскрывающегося списка укажите шаблон процесса, выбранный на шаге 1. В нашем примере выберите шаблон MSF for Agile Software Development -v4.0 и щелкните Next.
  5. На странице Specify the Settings for the Project Portal введите имя и описание портала командного проекта и щелкните Next. Указанное здесь имя используется при создании веб-сайта Microsoft Windows SharePoint® Services для портала проекта.
  6. На странице Specify Source Control Settings задайте Create an empty source control folder и щелкните Next.
  7. На странице Confirm Team Project Settings проверьте настройки и щелкните Finish.

На сервере TFS будет создан командный проект на базе шаблона процесса MSF Agile.

Шаг 3 - создание групп доступа (при необходимости)

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

  • Project Administrator.
  • Contributor.
  • Reader.
  • Build Services.

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

Чтобы создать новую группу, вы должны быть членом группы Project Administrators. Быть администратором Microsoft Windows® вам не нужно.

  1. В Team Explorer выберите командный проект, для которого хотите создать группу.
  2. В меню Team выберите команду Team Project Settings и щелкните Group Membership.
  3. В диалоговом окне Project Groups щелкните New /
  4. В диалоговом окне Create New Team Foundation Server Group в поле Group name введите имя группы командного проекта.
  5. В поле Description введите описание группы.
  6. Щелкните OK и Close.

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

Шаг 4 - добавление членов команды в Team Foundation Server

На этом этапе определяются ресурсы, которые будут работать над проектом, и их роли. Затем члены команды добавляются в TFS. Пользователей можно добавлять в существующие группы проекта или группы уровня сервера. Также вы должны добавить пользователей во вновь созданные вами группы. Для этого вы должны быть членом группы Team Foundation Administrators.

  1. Выберите нужный командный проект в Team Explorer.
  2. В меню Team выберите команду Team Project Settings и щелкните Group Membership. Чтобы добавить пользователей в группу уровня сервера, выберите команду Team Foundation Server Settings и щелкните Group Membership.
  3. В диалоговом окне Project Groups выберите группу, в которую хотите добавлять пользователей, и щелкните Properties.
  4. В диалоговом окне Team Foundation Server Group Properties на вкладке Members в разделе Add member выберите Windows User or Group.
  5. Щелкните Add.
  6. В диалоговом окне Select Users or Groups в разделе Enter the object names to select введите имя домена и имена пользователей, которого хотите добавить, в формате домен\имя пользователя. Чтобы добавить сразу несколько пользователей, введите их имена через точку с запятой.
  7. Дважды щелкните OK и щелкните Close.

Шаг 5 - определение итерационного цикла

Итерации ( iteration ) - это промежутки времени фиксированной длины, для которых вы продумываете, планируете и осуществляете работу. Все компоненты цикла разработки ПО, начиная с определения требований и заканчивая анализом, проектированием, разработкой, написанием кода и тестированием, группируются в итерации, продолжительность которых обычно составляет от 2 до 6 недель.

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

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

Шаг 6 - описание сценариев проекта в TFS

Описание сценария проекта в TFS позволяет лучше спланировать ход проекта и отслеживать его выполнение.

  1. На основании данных, предоставляемых различными заинтересованными сторонами, включая заказчиков, бизнес-аналитиков, конечных пользователей и руководителей, ответственных за выпуск продукта, создайте перечень задач по проекту ( project back log, PBL ). Его обычно составляют в Microsoft Office Word.
  2. Используйте PBL в качестве входных данных для выработки различных сценариев проекта.
  3. Можно выделить все сценарии до начала первой итерации или создавать их по мере продвижения проекта. Чтобы получить полную картину проекта и облегчить контроль его выполнения, рекомендуется описывать все сценарии заранее.
Создание сценария в проекте на основе шаблона процесса MSF Agile
  1. В Team Explorer разверните узел проекта и щелкните правой кнопкой папку Work Items.
  2. Выберите Add Work Item и щелкните Scenario.
  3. На странице New Scenario введите данные сценария.
  4. Сохраните новый сценарий.
  5. Повторите предыдущие шаги для всех сценариев проекта.

Шаг 7 - выбор сценариев для итерации

Теперь описанные сценарии нужно распределить по итерациям. Этот этап повторяется на каждом итерационном цикле.

  1. Исходя из данных, полученных от заинтересованных сторон, и приоритетности компонентов, выберите сценарии, которые будут выполняться в ходе данной итерации.
  2. Назначьте эти сценарии итерации.
Извлечение рабочих элементов и их связывание с конкретной итерацией
  1. Разверните папки Work Items и Team Queries, а затем дважды щелкните запрос All Scenarios, чтобы вывести на экран все сценарии проекта.
  2. Щелкните дважды сценарий, над которым хотите работать в текущей итерации.
  3. В поле Iteration введите путь текущей итерации и щелкните значок Save.
  4. Повторите эти шаги для всех выявленных сценариев.

Шаг 8 - определение требований QoS

На этом этапе для каждого из сценариев, реализуемых во время данного итерационного цикла, определяются требования QoS. Этот этап повторяется на каждом итерационном цикле. Это помогает определить критерий приемки для сценария. Требования QoS формулируются на основе целей, требований к проекту и спецификаций, если таковые имеются.

  1. Щелкните правой кнопкой папку Work Items проекта и выберите Add Work Item. Затем щелкните Quality of Service Requirements.
  2. На странице New Quality of Service Requirements введите следующую информацию:
    • Присвойте полю Type нужное значение: Performance, Scalability, Stress или Security.
    • Назначьте значение Iteration текущего итерационного цикла.
    • На вкладке Links свяжите требование QoS с конкретным сценарием, чтобы упростить контроль.
  3. Сохраните требование QoS.
  4. Создайте по одному требованию QoS для каждой дисциплины или типа требования QoS. Помните, что у каждого сценария может быть несколько требований QoS.
  5. Убедитесь, что создали требования QoS для всех сценариев, реализуемых в течение данного итерационного цикла.

    Важно! Позже требования QoS могут быть разложены на задачи тестирования.

Шаг 9 - планирование итерации

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

Задачи разработки

  1. Разбейте выбранные сценарии на уровни разработчиков.
  2. Разделите уровни разработчиков на задачи разработки.
  3. Зафиксируйте задачи разработки в TFS как рабочие элементы Task:
    • В Team Explorer в каталоге проекта щелкните правой кнопкой папку Work Items, выберите Add Work Item и щелкните Task.
    • На странице New Task введите следующие данные:
      • Присвойте полю Discipline значение Development.
      • Задайте в качестве Iteration текущий итерационный цикл.
      • На вкладке Links свяжите задачу с конкретным сценарием для упрощения контроля.
      • На вкладке New Task Page помимо описания задайте критерий приемки задачи, по которому можно будет судить о ее успешном завершении.
      • В поле Assigned to задайте разработчика, который будет заниматься данной задачей.
    • Сохраните новую задачу.
    • Повторите перечисленные шаги для всех задач.
  4. Повторите эти шаги для всех сценариев итерации.

Задачи тестирования

  1. Разбейте требования QoS для данного сценария на сценарии тестирования.
  2. Разделите сценарии тестирования на задачи тестирования и зафиксируйте их в TFS как рабочие элементы Task:
    • В Team Explorer в каталоге проекта щелкните правой кнопкой папку Work Items, выберите Add Work Item и щелкните Task.
    • На странице New Task введите следующие данные:
      • Присвойте полю Discipline значение Test.
      • Задайте в качестве Iteration текущий итерационный цикл.
      • На вкладке Links свяжите задачу с конкретными требованиями QoS для упрощения контроля.
      • На вкладке New Task Page помимо описания задайте критерий приемки задачи, по которому можно будет судить о ее успешном завершении.
      • В поле Assigned to задайте тестировщика, который будет заниматься данной задачей.
    • Сохраните новую задачу.
    • Повторите перечисленные шаги для всех задач.
  3. Повторите эти шаги для всех требований QoS итерации.
Прочее
  1. Опишите задачи итерации, для других дисциплин, например, Architecture, Release Management, Project Management, Requirements, которые нуждаются в контроле.
  2. Свяжите каждую из этих задач с соответствующим сценарием.

В крупных проектах с огромным количеством рабочих элементов используйте возможность интеграции с Microsoft Office Excel®. В этом случае рабочие элементы создаются в электронной таблице Excel и затем загружаются на TFS. Подробнее об этом читайте в статье "Working with Work Item Lists in Microsoft Excel" по адресу http://msdn2.microsoft.com/en-us/library/ ms181694(VS.80).aspx.

В крупных проектах, где задействовано множество ресурсов, используйте возможность интеграции с Microsoft Office Project для отслеживания рабочих элементов и равномерного распределения задач между исполнителями. Дополнительную информацию по этому вопросу вы найдете в статье "Working with Work Items in Microsoft Project" по адресу http://msdn2.micro-soft.com/en-us/library/ms244368(VS.80).aspx.

Шаг 10 - отслеживание процесса разработки

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

Ошибки

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

  • Bugs by Priority Правильно ли выявлены ошибки? В этом отчете показывается соотношение выявленных высокоприоритетных ошибок и ошибок с низким приоритетом. Он доступен в обоих стандартных шаблонах.
  • Bug Rates Насколько эффективно происходит выявление, исправление и закрытие ошибок? В этом отчете показывается общая тенденция по выявлению новых ошибок, приводятся списки незакрытых ошибок и сведения по исправлению ошибок. Он доступен в обоих стандартных шаблонах.
Управление выпусками

Отчеты по управлению выпусками позволяют судить, насколько разрабатываемое ПО готово к выпуску. К вашим услугам следующие отчеты:

  • Actual Quality versus Planned Velocity Сколько сценариев можно завершить, прежде чем качество станет неприемлемым? На каждой итерации этот отчет представляет соотношение примерного объема проекта и общего качества. Отчет доступен в обоих стандартных шаблонах.
  • Builds Каково качество сборки? В этом отчете содержится список имеющихся сборок, а также их качество и другая подробная информация. Отчет доступен в шаблоне MSF CMMI.
  • Quality Indicators Каково качество ПО? В этом отчете собраны результаты тестов, ошибки, сведения о покрытии кода и его изменчивости. Отчет доступен в обоих стандартных шаблонах.
  • Velocity Насколько быстро команда справляется с работой? Из этого отчета вы узнаете, насколько своевременно команда выполняет плановые задания и как темп ее работы меняется изо дня в день. Отчет доступен в обоих стандартных шаблонах.
  • Scenario Details Для каких сценариев мы готовим приложение? В отчете содержатся сведения обо всех сценариях, включая информацию о завершенности, рисках и испытаниях.
Тестирование

Отчеты о тестировании позволяют следить за эффективностью испытаний. Доступны следующие отчеты о тестировании:

  • Regressions Какие тесты ранее выполнялись, а теперь - нет? Их список содержится в этом отчете. Отчет доступен в шаблоне MSF CMMI.
  • Requirements Test History Насколько хорошо протестированы сценарии и требования? В этом отчете показаны результаты испытаний определенных сценариев и требований. Отчет доступен в шаблоне MSF CMMI.
  • Test Failure Without Active Bug Каждый ли из известных дефектов документирован как ошибка? В этом отчете показаны неудачные испытания, с которыми не связаны открытые ошибки. Отчет доступен в шаблоне MSF CMMI.
  • Test Passing With Open Bug Своевременно ли обновляется список ошибок и согласуется ли он с качеством приложения? Отчет отображает список устаревших ошибок, тесты для которых теперь выполняются. Доступен в шаблоне MSF CMMI.
  • Load Test Summary К каким выводам о производительности приложения привели испытания под нагрузкой? В отчете содержатся результаты нагрузочного тестирования. Отчет доступен в шаблоне MSF Agile
Рабочие элементы

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

  • Open Issues and Blocked Work Items Trend Сколько у вас осталось неразрешенных проблем? В отчете перечислены открытые проблемы и наметившиеся тенденции к их разрешению. Отчет доступен в шаблоне MSF CMMI.
  • Reactivations Сколько рабочих элементов было повторно активировано? В отчете указаны рабочие элементы, которые были преждевременно закрыты или помечены как разрешенные. Отчет доступен в обоих стандартных шаблонах.
  • Related Work Items Как одни рабочие элементы зависят от других рабочих элементов? В отчете отображается список рабочих элементов, которые связана с другими рабочими элементами, что позволяет прослеживать зависимости между ними. Отчет доступен в шаблоне MSF CMMI.
  • Remaining Work Сколько осталось выполнить работ и когда они будут завершены? В отчете отражена незавершенная работа, а также разрешенная и закрытая работа. Выявив тенденции, вы определите время, к которому код будет завершен. Отчет доступен в обоих стандартных шаблонах.
  • Triage Какие рабочие элементы нуждаются в уточнении? В этом отчете показаны рабочие элементы, все еще имеющие статус предложения. Отчет доступен в шаблоне MSF CMMI.
  • Unplanned Work Сколько выполняется внеплановых работ? В отчете полная работа сопоставляется с уже выполненной с разделением плановых и внеплановых задач. Отчет доступен в обоих стандартных шаблонах.
  • Work Items Какие рабочие элементы активны? В отчете перечислены все активные рабочие элементы. Отчет доступен в шаблоне MSF CMMI.
  • Work Items by Owner Сколько работы назначено каждому члену команды? В этом отчете рабочие элементы отсортированы по владельцам.

Отчет доступен в шаблоне MSF CMMI.

  • Work Items by State Сколько имеется активных, разрешенных и закрытых рабочих элементов? В этом отчете рабочие элементы отсортированы по состоянию. Отчет доступен в шаблоне MSF CMMI.

Рекомендации по работе с областями и итерациями

При работе с областями и итерациями необходимо учитывать следующие соображения:

  • Области используются для организации работы в командном проекте. Например, работу по проекту можно разбить на области UI (пользовательский интерфейс), Application (приложение) и Database (база данных), а затем распределить по этим областям сценарии и рабочие элементы. С помощью областей рабочие элементы группируются для запросов и отчетов. Можно начать с одной корневой области, а потом в ходе разработки проекта по мере надобности создавать дополнительные области.
  • С помощью итераций мы определяем, сколько раз в ходе разработки приложения команда будет повторять определенный набор основных действий (планирование, разработка, тестирование). Итерации используются для группировки рабочих элементов и тем самым оказывают влияние на создание рабочих элементов, запросов к рабочим элементам и отчетов.

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

  • Дополнительную информацию об использовании электронных таблиц Microsoft Office Excel для работы с рабочими элементами вы найдете в статье "Working with Work Item Lists in Microsoft Excel" по адресу http:// msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx.
  • Дополнительную информацию об использовании Microsoft Office Project для отслеживания рабочих элементов и равномерного распределения задач между исполнителями вы найдете в статье "Working with Work Items in Microsoft Project" по адресу http://msdn2.microsoft.com/en-us/library/ ms244368(VS.80).aspx.
Александр Будник
Александр Будник
Израиль, Иерусалим
Pavel Pelevin
Pavel Pelevin
Украина, Одесса