Рабочее место менеджера проекта, инструментальные средства. Формирование технического задания, структурной схемы и основных функций тестового проекта в среде MS Project. График реализации проекта

Создание классификации рабочих элементов проекта

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

Рис. 7.13. Определение дочерних классов

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

В VSTS предусмотрена возможность определять итерации проекта, то есть этапы его жизненного цикла. В зависимости от выбранной ме¬тодики Team System по умолчанию создаст несколько итераций с именами типа Iteration 0, Iteration 1 и т. д. Их можно пере¬именовать, но дополнительные метаданные с этими стандартными итерациями связать.

Рис. 7.14. Определение итераций проекта

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

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

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

Одной из самых мощных функций Team System является поддерж¬ка политик подтверждения — эффективного средства контроля над проектом и его командой со стороны руководителя проекта, архитектора или ведущего разработчика. Грамотное применение политик позволяет получить более качественный код. Однако в этом деле важно соблюдать меру: если вы переборщите с коли¬чеством и жесткостью политик, они станут обременительными для разработчиков, которые будут пытаться обойти их всеми правдами и неправдами. Кроме того, руководитель, знакомящий команду с политиками, должен проявить определенную диплома¬тичность.

Рис. 7.15. Определение политик подтверждения

Некоторые из политик подтверждения, поддерживаемых Team System, перечислены ниже.

Clean Build (Чистая сборка). Для того чтобы подтверждение стало возможным, код должен компилироваться без ошибок.

Static Analysis (Статический анализ). Прежде чем производить подтверждение, необходимо выполнить статический анализ кода.

Testing Policy (Политика тестирования). Подтверждению должно предшествовать проведение одного или нескольких тестов.

Work Item s (Рабочие элементы). Код следует связать с одним или несколькими рабочими элементами.

Notes (Заметки). С кодом должны быть ассоциированы одна или несколько пометок (имя рецензента, вопросы, состояние, время и т. д.).

Custom (Пользовательская). Допускается создание поль¬зовательских политик подтверждения, наличия и доступности сервисов, устойчивость к перегрузкам, удобство обслуживания и поддержки;

Task (Задача) — работа, которую необходимо выполнить;

Bug (Ошибка) — потенциальная проблема, существующая или ранее имевшая место в системе;

Risk (Риск) — вероятное событие или условие, которое может отрицательно сказаться на результатах проекта.

Для добавления рабочих элементов и управления ими руководитель проекта или любой другой член команды использует одно из трех клиентских приложений: Visual Studio 2005, Microsoft Excel или Microsoft Project.

Добавление рабочих элементов и управление ими

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

С технической точки зрения рабочий элемент представляет со¬бой запись в базе данных, используемую Visual Studio 2008 Team Foundation Server для отслеживания назначений и состояния ра¬бот. Методика MSF for Agile Software Development определяет пять типов рабочих элементов:

• Scenario (Сценарий) — одна (конкретная) последовательность действий пользователя при взаимодействии с системой;
• Quality of Service (QoS) requirement (Требования к каче¬ству) — описание характеристик системы, таких как произво¬дительность, нагрузочная способность, параметры
• Task (Задача) — работа, которую необходимо выполнить;
• Bug (Ошибка) — потенциальная проблема, существующая или ранее имевшая место в системе;
• Risk (Риск) — вероятное событие или условие, которое может отрицательно сказаться на результатах проекта.

Для добавления рабочих элементов и управления ими руководитель проекта или любой другой член команды использует одно из трех клиентских приложений: Visual Studio 2008, Microsoft Excel или Microsoft Project.