Руководства

Руководство по управлению проектом

В этом разделе

Области и итерации

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

Политики возврата после правки

• Повышайте качество кода при помощи политики возврата после правки.
• Обязывайте разработчиков связывать рабочие элементы с возвратом после правки при помощи политики.
• Используйте политики возврата для соблюдения стандартов программирования.
• Настраивайте уведомления о перекрытии политик возврата после правки.

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

• Используйте шаблон процесса MSF Agile в несложных проектах, допускающих неформальный подход.
• Используйте шаблон процесса MSF CMMI в проектах, требующих более формального подхода или соответствия стандартам CMMI.
• По возможности используйте минимальный шаблон процесса.
• Отредактируйте существующий шаблон в соответствии с потребностями вашей команды.

Группы безопасности и разрешения

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

Командные проекты

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

Рабочие элементы

• Создавайте сценарии в начале работы над проектом.
• Правильно определяйте требования QoS.
• Разделяйте сценарии на управляемые задачи.
• Разрабатывайте критерии приемки для каждой задачи.
• Связывайте требования и задачи со сценариями.
• Используйте Microsoft Excel для массового редактирования рабочих элементов.

Области и итерации

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

Используйте области для улучшения контроля за проектом

Используйте области ( area ) командного проекта для упорядочения задач, ошибок, требований и других рабочих элементов. Разрешения для областей позволяют ограничить доступ к различным частям командного проекта.

Области применяются для представления логических или физических компонентов, а подобласти ( sub-area ) представляют отдельные функции. Такая структура помогает упорядочить рабочие элементы и упрощает отслеживание работ по компоненту или функции.

Создание области проекта

1. Щелкните проект в окне Team Explorer.
2. В меню Team раскройте подменю Team Project Settings и выберите команду Areas and Iterations.
3. В диалоговом окне Areas and Iterations перейдите на вкладку Area.
4. Щелкните кнопку Add a child node на панели инструментов.
5. Щелкните правой кнопкой новый узел, выберите команду Rename и введите нужное имя.
6. Щелкните узел Area.
7. Повторяйте шаги 2, 3 и 4 для создания дополнительных областей и иерархической структуры проекта.

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

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

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

Представляйте вехи проекта с помощью итераций

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

Создание итерации

1. Щелкните проект в окне Team Explorer.
2. В меню Team раскройте подменю Team Project Settings и выберите команду Areas and Iterations.
3. В диалоговом окне Areas and Iterations перейдите на вкладку Iteration.
4. Щелкните кнопку Add a child node на панели инструментов.
5. Щелкните правой кнопкой новый узел, выберите команду Rename и введите имя.
6. Щелкните узел Iteration.
7. Повторите шаги 2, 3 и 4 для создания других итераций.
8. Щелкните Close.

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

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

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

Создавайте отдельные итерации для неназначенных сценариев и задач

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

Создание отдельной итерации

1. Щелкните командный проект в окне Team Explorer.
2. В меню Team раскройте подменю Team Project Settings и выберите команду Areas and Iterations.
3. В диалоговом окне Areas and Iterations перейдите на вкладку Iteration.
4. Щелкните кнопку Add a child node на панели инструментов.
5. Щелкните Close.

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

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

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

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

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

На практике в большинстве командных проектов работает двухнедельный цикл итерации.

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

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

Политики возврата после правки

• Повышайте качество кода при помощи политики возврата после правки.
• Обязывайте разработчиков связывать рабочие элементы с возвратом после правки при помощи политики.
• Используйте политики возврата для соблюдения стандартов программирования.
• Настраивайте уведомления о перекрытии политик возврата после правки.

Повышайте качество кода при помощи политики возврата после правки

Сочетая политики анализа и тестирования, вы обеспечите соблюдение стандартов качества кода. Например, встроенная в VSTS политика тестирования обеспечит обязательное проведение специальных тестов перед возвратом кода в системе управления исходным кодом Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) . Также можно настроить политику анализа кода, обеспечив с ее помощью соответствие кода определенным нормам безопасности, производительности, переносимости, удобства сопровождения и надежности.

Применяя этот тип политики возврата после правки в дополнение к политикам, направленным на укрепление стандартов и нормативов программирования, вы гарантируете соответствие кода специфическим критериям качества.

Применение анализа кода в командном проекте

1. В окне Team Explorer щелкните правой кнопкой нужный командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.
2. Перейдите на вкладку Check-in Policy, щелкните кнопку Add, а затем выберите и настройте соответствующую политику.

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

• Дополнительную информацию о создании и использовании пользовательской политики возврата после правки вы найдете в разделе "Как создать пользовательскую политику возврата после правки в Visual StudioTeam Foundation Server " этой книги.

Обязывайте разработчиков связывать рабочие элементы с возвратом после правки при помощи политики

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

Настройка политики Work Items

1. В окне Team Explorer правой кнопкой мыши щелкните нужный командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.
2. Перейдите на вкладку Check-in Policy.
3. Щелкните кнопку Add, а затем выделите и настройте политику Work Item.

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

• Дополнительную информацию о возврате после правки вы найдете в статье "How to: Check In Pending Changes" по адресу http://msdn2.microsoft. com/en-us/library/ms181411(VS.80).aspx.
• Дополнительную информацию о рабочих элементах и незавершенных изменениях вы найдете в статье "How to: Associate Work Items with Changesets" по адресу http://msdn2.microsoft.com/en-us/library/ms181410 (VS.80).aspx.

Используйте политики возврата для соблюдения стандартов программирования

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

Применение политики для соблюдения стандартов программирования

1. В окне Team Explorer правой кнопкой мыши щелкните нужный командный проект, раскройте подменю Team Project Settings и щелкните команду Source Control.
2. Перейдите на вкладку Check-in Policy и щелкните кнопку Add.
3. В диалоговом окне Add Check-in Policy установите параметр Code Analysis и щелкните OK.
4. В редакторе Code Analysis Policy Editor задайте параметр Enforce C/C++ Code Analysis (/analyze), Enforce Code Analysis For Managed Code или оба, если ваш проект содержит сочетание управляемого и неуправляемого кода.
5. Если вы выбрали анализ управляемого кода, задайте необходимые правила, руководствуясь собственными стандартами программирования. Кроме того, вы вольны создать пользовательскую политику возврата после правки для выполнения проверок, не выполняющихся по умолчанию. Можно запретить определенные виды кода, например, вызовы запрещенных функций API, или написать политику для соблюдения стиля программирования, принятого в вашей команде, задав, например, как расставлять фигурные скобки в исходном коде.

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

• Дополнительную информацию о создании и использовании пользовательской политики возврата после правки вы найдете в разделе "Как создать пользовательскую политику возврата после правки в Visual Studio Team Foundation Server " этой книги.

Настраивайте уведомления о перекрытии политик возврата после правки

Система управления версиями Team Foundation Server Version Control не запрещает перекрывать политики возврата после правки. Однако вы можете выполнить следующие действия, чтобы при помощи службы Team Foundation Server Eventing Service из Team Foundation Core Services API выявить факт перекрытия политики: напишите метод Notify, проводящий разбор свойств набора изменений и реагирующий на факт перекрытия. Можно также обнаружить перекрытие политики, просмотрев историю набора изменений вручную.

Дополнительная информация

• Дополнительную информацию о перекрытии политики возврата вы найдете в статье "How to: Override a Check-in Policy" по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.