Заметки консультанта

Шамрай Александр Владимирович

Рекомендации: Управление проектами

<< Назад

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

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

•      Microsoft Visual Studio Team System

Содержание Области и итерации

•      Использование областей для отслеживания связей между артефактами.

•      Использование итераций для представления основных этапов проекта.

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

•      Определение соответствующей продолжительности итерационного цикла.

Политики регистрации изменений

•      Использование политик регистрации изменений для обеспечения качества кода.

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

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

•      Как настроить уведомления о переопределении политики регистрации изменений разработчиками.

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

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

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

•      Использование минимального шаблона процесса.

•      Изменение существующего шаблона процесса для соответствия процессу группы.

Группы и права доступа

•      Предоставление специальных прав доступа через создание групп доступа.

•      Включение членов группы в соответствующие группы доступа.

Групповые проекты

•      Создание одного проекта для приложения, если предполагается миграция рабочих элементов и других ресурсов между версиями приложения.

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

•      Предоставление только необходимых прав доступа к ресурсам проекта.

•      Структурирование дерева исходного кода для поддержки ветвления.

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

•     Описание сценариев должно происходить в начале проекта.

•     Должное определение нефункциональных требований.

•     Разложение сценариев на управляемые независимые задачи разработки.

•     Как задать критерий приемки для каждой задачи.

•     Как связать требования и задачи со сценариями.

•     Использование Microsoft Excel для редактирования списка рабочих элементов.

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

•     Использование областей для отслеживания связей между артефактами.

•     Использование итераций для представления основных этапов проекта.

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

•     Определение соответствующей продолжительности итерационного цикла.

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

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

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

Чтобы создать области для проекта

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.

Примечание: Шаблон процесса Microsoft® Solutions Framework (MSF) for Agile Software Development (MSF 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.   Щелкните правой кнопкой мыши новый узел, выберите Rename и введите имя итерации Iteration 999.

6.   Щелкните Close.

Дополнительные источники

Больше информации о создании итераций можно найти в разделе «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

Определение соответствующей продолжительности итерационного цикла

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

При определении продолжительности итерационного цикла следует принять во внимание следующие факторы:

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

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

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

Дополнительные источники

•     Подробнее о продолжительности итерационного цикла рассказывается в разделе «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

•     Больше информации о продолжительности итерационного цикла можно найти в Главе 11 «Управление проектом» данного руководства.

Политики регистрации изменений

•     Использование политик регистрации изменений для обеспечения качества кода.

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

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

•     Как настроить уведомления о переопределении политики регистрации изменений разработчиками.

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

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

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

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

1.    В Team Explorer щелкните правой кнопкой мыши групповой проект, выберите Team Project Settings и затем щелкните Source Control.

2.    Выберите вкладку Check-in Policy, щелкните Add и затем выберите и конфигурируйте соответствующую политику.

Дополнительные источники

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

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

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

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

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

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/msl81411(VS.80).aspx.

•     Подробнее о рабочих элементах и пакетах изменений рассказывается в статье «How to: Associate Work Items with Changesets» (Как: ассоциировать рабочие элементы с пакетами изменений) по адресу http://msdn2.microsoft.com/en-us/library/msl81410(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) (Активировать анализ кода С/С++ (ключ /analyze)) или Enforce Code Analysis For Managed Code (Активировать анализ кода для управляемого кода). Выберите оба пункта, если в проекте используется как управляемый, так и неуправляемый код.

5.   Если выбран анализ управляемого кода, конфигурируйте набор обязательных правил для анализа управляемого кода на основании требуемых стандартов написания кода. Таким образом, будут точно определены используемые правила.

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

Дополнительные источники

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

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

Team Foundation Server Version Control не запрещает переопределение политики регистрации. Используя следующий порядок действий, можно выяснить, была ли переопределена политика регистрации изменений:

1.   С помощью Team Foundation Server Eventing Service (из Team Foundation Core Services API) перехватываем события регистрации изменений.

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

Или можно самостоятельно просматривать историю изменений.

Дополнительные источники

Подробнее о переопределении политики регистрации рассказывается в статье «How to: Override a Check-in Policy» (Как: переопределить политику регистрации изменений) по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.

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

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

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

•     Использование минимального шаблона процесса.

•     Изменение существующего шаблона процесса для соответствия процессу группы.

Использование шаблона процесса MSF Agile при работе над проектами, для которых достаточно упрощенного или неформального процесса

При использовании Test-Driven Development (TDD) или других методологии гибкой разработки, следует применять шаблон процесса MSF для Agile Software Development (MSF Agile). Это упрощенный процесс для гибких программных проектов. Данный шаблон проекта должен рассматриваться как основной шаблон, если нет необходимости в дополнительных функциях совершенствования процесса, предоставляемых шаблоном процесса MSF для CMMI Software Development (MSF CMMI).

Шаблон процесса MSF Agile можно без труда редактировать и менять соответственно конкретным требованиям к процессу.

Дополнительные источники

•     Более подробная информация представлена в Главе 11 «Управление проектом» данного руководства.

•     Подробнее о шаблоне процесса MSF Agile рассказывает Глава 14 «Проекты MSF Agile» данного руководства.

•     Больше информации о настройке шаблона процесса можно найти в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server» данного руководства.

Использование шаблона процесса MSF CMMI при работе над проектами, требующими более формального процесса или соответствия стандартам CMMI

В качестве формального процесса разработки ПО, целью которого является совершенствование существующего процесса, следует использовать шаблон процесса MSF для CMMI Software Development (MS CMMI).

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

Дополнительные источники

•      Подробнее об этом рассказывает Глава 11 «Управление проектом» данного руководства.

•      Больше информации о настройке шаблона можно найти в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server» данного руководства.

Использование минимального шаблона процесса

Многим группам не нужна поддержка всех частей стандартного группового проекта. Например, многие группы хотят использовать систему контроля версий, но им не нужен портал Microsoft Office SharePoint®. Шаблоны групповых проектов можно менять, из них можно изымать некоторые части, в которых нет необходимости. При изменении шаблона удалены могут быть любые разделы, кроме Group Permissions (Права доступа группы) и Classifications (Классификации).

Для создания минимального шаблона процесса с помощью Process Template Manager (Диспетчер шаблонов процессов) шаблон загружается на локальный компьютер, из него изымаются ненужные разделы, и после этого шаблон загружается обратно на сервер.

Дополнительные источники

•      Подробнее о шаблонах процессов рассказывает Глава 13 «Шаблоны процессов» данного руководства.

•      Подробнее о настройке шаблонов процессов рассказывается в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server» данного руководства.

•      Больше информации о настройке шаблонов процессов можно найти в статье «Customizing Process Templates» по адресу http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx.

•      Больше информации об использовании минимального шаблона процесса представлено в статье «How to use TFS for source control only» (Как использовать TFS только для контроля версий исходного кода) по адресу http://blogs.msdn.com/richardb/archive/2007/05/10/how-to-use-tfs-for-source-control-only.aspx.

Изменение существующего шаблона процесса для соответствия процессу группы

Разрабатываемый проект может не соответствовать поставляемым с Microsoft Visual Studio Team System (VSTS) стандартным шаблонам процессов, например, требуется другой тип рабочих элементов или используется совершенно другая методология процесса. В этом случае необходимо изменить существующий шаблон процесса. Для этого выбираем наиболее близко отвечающий поставленным требованиям шаблон процесса и изменяем его.

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

•      Groups and Permissions (Группы и права доступа)

•      Work Item Types (Типы рабочих элементов)

•      Source Control Check-in Notes and Policies (Комментарии и политики регистрации изменений в системе контроля версий)

•      Areas and Iterations (Области и итерации)

•      Reports (Отчеты)

•     Team Portal (Портал группы)

•      Process Guidance (Руководство по процессу)

Дополнительные источники

•      Подробнее о шаблонах процессов рассказывается в Главе 13 «Шаблоны процессов» данного руководства.

•      Больше информации о настройке шаблона можно найти в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server» данного руководства.

Группы и права доступа

•      Предоставление специальных прав доступа через создание групп доступа.

•      Включение членов группы в соответствующие группы доступа.

Предоставление специальных прав доступа через создание групп доступа

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

•      Project Administrator (Администратор проекта)

•      Contributor (Участник)

•      Reader (Читатель)

•      Build Services (Сервисы сборки)

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

Дополнительные рекомендации:

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

•      Используйте группы Active Directory (AD) только на уровне сервера.

•     Для задания прав доступа используйте группы TFS (а не группы AD).

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

Дополнительные источники

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

•      Больше информации о правах доступа TFS можно найти в статье «Team Foundation Server Permissions» (Права доступа Team Foundation Server) по адресу http://msdn2.microsoft.com/en-us/library/ms252587(VS.80).aspx.

Включение членов группы в соответствующие группы доступа

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

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

Дополнительные источники

•      Подробнее о группах доступа рассказывает раздел «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

Групповые проекты

•      Создание одного проекта для приложения, если предполагается миграция рабочих элементов и других ресурсов между версиями приложения.

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

•      Предоставление только необходимых прав доступа к ресурсам проекта.

•      Структурирование дерева исходного кода для поддержки ветвления.

Создание одного проекта для приложения, если предполагается миграция рабочих элементов и других ресурсов между версиями приложения

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

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

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

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

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

•     TFS не сможет обслуживать сотни приложений, каждое из которых будет иметь собственный проект, он достигнет пределов производительности и масштабируемости.

•      От версии к версии будет накапливаться ненужный ‘багаж’ дефектов. Самый простой способ справиться с этой проблемой — создать новый проект и весь код который требуется перенести в него из предыдущих проектов, поместить в отдельную ветвь.

Дополнительные источники

•      Подробнее об использовании групповых проектов рассказывает статья «When to use Team Projects» (Когда использовать групповые проекты) по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

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

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

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

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

переноса большого числа рабочих элементов придется создавать собственную сервисную программу.

•     TFS не сможет обслуживать сотни приложений и их версий, каждое из которых будет иметь собственный проект, он достигнет пределов производительности и масштабируемости.

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

•      Групповые проекты могут без труда совместно использовать исходный код посредством:

о Создания ветвей исходного кода одного проекта в другом. о Отображения исходного кода из другого проекта в ваше рабочее пространство.

•     Team Foundation Server может обслуживать до ~500 проектов при использовании шаблона процесса MSF Agile или 250 проектов при использовании MSF CMMI. При создании собственного шаблона процесса или настройке существующего следует помнить, что огромное влияние на масштабируемость сервера имеет схема рабочих элементов. Чем сложнее схема, тем меньше проектов сможет поддерживать сервер.

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

Дополнительные источники

•      Более подробную информацию об использовании групповых проектов можно найти в статье «When to use Team Projects» по адресу http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx.

Предоставление только необходимых прав доступа к ресурсам проекта

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

Дополнительные источники

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

Структурирование дерева исходного кода для поддержки ветвления

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

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

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

Ниже представлен пример структуры дерева исходного кода, поддерживающей ветвление:

  • Main — Контейнер всех ресурсов, необходимых для поставки продукта
    • Source — Контейнер всего, что необходимо для выполнения сборки
      • Code — Контейнер исходного кода
      • Shared Code — Контейнер исходного кода, используемого совместно с другими проектами
      • Unit Tests — Контейнер модульных тестов
      • Lib — Контейнер используемых двоичных файлов
    • Docs — Контейнер документации, поставляемой с продуктом 
    • Installer — Контейнер исходного кода и двоичных файлов пакета установки приложения 
    • Builds — Контейнер сценариев сборки 
    • Tests — Контейнер сценариев тестирования группы тестирования

Дополнительные источники

•     Более подробно о структуре дерева исходного кода рассказывает Глава 5 «Выбор стратегии ветвления и слияния» данного руководства.

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

•     Описание сценариев должно происходить в начале проекта.

•     Должное определение нефункциональных требований.

•     Разложение сценариев на управляемые независимые задачи разработки.

•     Как задать критерий приемки для каждой задачи.

•     Как связать требования и задачи со сценариями.

•     Использование Microsoft Excel для редактирования списка рабочих элементов.

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

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

Чтобы описать сценарии в начале проекта

1.    Выработайте сценарии для своего проекта, используя перечень невыполненных работ по проекту (project back log, PBL). PBL является спецификацией требований, создаваемой на основании данных, предоставленных различными заинтересованными сторонами (включая заказчиков, бизнес-аналитиков, конечных пользователей и руководителей, ответственных за выпуск продукта).

2.    В Team Explorer разверните узел проекта, правой кнопкой мыши щелкните папку Work Items, выберите Add Work Item и затем щелкните Scenario (Сценарий).

3.    На странице New Scenario (Новый сценарий) введите данные сценария. Не забудьте установить для Iteration значение Iteration 999.

4.    Сохраните новый сценарий.

5.    Повторите перечисленные выше шаги для всех сценариев проекта.

Дополнительные источники

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

Должное определение нефункциональных требований

Для каждого сценария, который будет обрабатываться в итерационном цикле, описываются нефункциональные требования (Quality of Service, QoS). Они помогают определить приемочные критерии для сценария. Исходные данные для нефункциональных требований получают, исходя из целей проекта, и на основании требований и спецификации, если они имеются в распоряжении.

Чтобы определить нефункциональные требования

  1. Щелкните правой кнопкой мыши папку проекта Work Items, выберите Add Work Item и затем щелкните Quality of Service Requirements (Нефункциональные требования).
  2. На странице New Quality of Service Requirements (Новые нефункциональные требования) введите следующую информацию:
    1. Задайте тип нефункционального требования, такое как performance (производительность), scalability (масштабируемость), stress (устойчивость к нештатным условиям эксплуатации) или security (безопасность) в поле Type.
    2. Присвойте Iteration значение текущего итерационного цикла.
    3. На вкладке Links (Ссылки) ассоциируйте нефункциональное требование с конкретным сценарием, чтобы упростить отслеживание.
  3. Сохраните новое нефункциональное требование.
  4. Создайте по одному нефункциональному требованию для каждой дисциплины обслуживания или типа нефункционального требования, помня при этом, что у каждого сценария может быть несколько нефункциональных требований.
  5. Убедитесь, что создали нефункциональные требования для всех сценариев, реализуемых в течение заданного итерационного цикла.

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

Дополнительные источники

•      Подробнее об описании нефункциональных требований рассказывает раздел «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

•      Более подробную информацию о рабочих элементах можно найти в статье «Managing Team Foundation Work Items» (Управление рабочими элементами Team Foundation) по адресу http://msdn2.microsoft.com/en-us/library/msl81314(VS.80).aspx.

Разложение сценариев на управляемые независимые задачи разработки

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

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

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

Дополнительные источники

•      Более подробную информацию о сценариях можно найти в разделе «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

•      Подробнее о рабочих элементах рассказывает статья «Managing Team Foundation Work Items» по адресу http://msdn2.microsoft.com/en-us/library/msl81314(VS.80).aspx.

Как задать критерий приемки для каждой задачи

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

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

•      MSF CMMI — Если используется MSF CMMI, для определения критерия приемки задачи можно использовать формальные требования. Первый шаг -определить свои требования. Затем создать задачу разработки, которая будет использоваться для реализации этих требований, и связать задачу с требованиями, чтобы разработчик мог сверяться с ними и, таким образом, прослеживать путь от требований к задаче.

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

Дополнительные источники

•      Подробнее о рабочих элементах рассказывает статья «Managing Team Foundation Work Items» по адресу http://msdn2.microsoft.com/en-us/library/msl81314(VS.80).aspx.

Как связать требования и задачи со сценариями

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

Чтобы связать новые задачи, дефекты, проблемы или нефункциональные требования со сценариями

1.     На странице New work item (Новый рабочий элемент) щелкните вкладку Links, на ней нажмите кнопку Add.

2.     В диалоговом окне Add Link (Добавить ссылку) в поле Link Type (Тип ссылки) выберите Scenario.

3.     Щелкните Browse (Просмотреть), чтобы найти сценарии группового проекта.

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

5.     В поле Comment, введите комментарий, описывающий взаимосвязь рабочего элемента. Поле Description (Описание) заполняется автоматически.

6.     Щелкните OK.

Дополнительные источники

•      Больше информации можно найти в разделе «Как: управлять проектами в Visual Studio Team Foundation Server» данного руководства.

•      Подробнее о рабочих элементах рассказывает статья «Managing Team Foundation Work Items» по адресу http://msdn2.microsoft.com/en-us/library/msl81314(VS.80).aspx.

Использование Microsoft Excel для редактирования списка рабочих элементов

Team Foundation Server не поддерживает редактирование списка рабочих элементов, поэтому приходится работать с каждым рабочим элементом в отдельности. Если требуется изменить большое количество рабочих элементов за короткий период времени — например, в ходе совещания по установке очередности работ — облегчить эту задачу поможет Microsoft Office Excel®. Рабочие элементы можно экспортировать из TFS в Excel, изменить их и затем возвратить в TFS для сохранения внесенных поправок.

Чтобы создать список рабочих элементов в Excel и редактировать его

1.   В Microsoft Office Excel в меню Team щелкните New List (Новый список).

2.   Под Connect to a Team Foundation Server (Подключиться к Team Foundation Server), выберите сервер, с которым будете соединяться, или щелкните Servers (Серверы), чтобы ввести информацию о сервере.

3.   Под Team Projects выберите групповой проект Team Foundation Server, с которым хотите работать.

4.   Документ будет связан с этим групповым проектом.

5.   Щелкните OK.

6.   Выберите тип списка по собственному усмотрению. Чтобы создать список запросов, выберите опцию Query List (Список запросов) и затем из

выпадающего списка Select a Query (Выбрать запрос) выберите запрос, доступный всей группе.

7.     Выберите столбцы, которые хотите увидеть в новом списке рабочих элементов.

8.     Импортируйте необходимые рабочие элементы. Подробнее об этом смотрите в статье «How to: Import Work Items in Microsoft Excel or Microsoft Project» (Как: импортировать рабочие элементы в Microsoft Excel или Microsoft Project) по адресу http://msdn2.microsoft.com/en-us/library/msl81676(VS.80).aspx.

9.    Теперь можно редактировать рабочие элементы и публиковать обновленные рабочие элементы в базу данных, щелкая Publish Changes (Публиковать изменения) в меню Team.

Дополнительные источники

Более подробно об использовании Microsoft Office Excel в задачах управления проектом рассказывает статья «Working with Work Item Lists in Microsoft Excel» по адресу http://msdn2.microsoft.com/en-us/library/msl81694(VS.80).aspx.

Дополнительные источники по управлению проектом Team Foundation

Более подробную информацию о шаблонах процессов MSF можно найти в материале «Process Templates» (Шаблоны процессов) по адресу http://msdn2.microsoft.com/en-us/teamsystem/aa718801.aspx.

<< Назад

Реклама
 
%d такие блоггеры, как: