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

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

Глава 11 — Управление проектом

<< Назад

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

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

Задачи

  • Изучить возможности, предоставляемые Microsoft® Visual Studio® Team System (VSTS) для руководителей проектов.
  • Выбрать стратегию создания проекта группы.
  • Создавать и управлять проектами с использованием Visual Studio Team System.

Обзор

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

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

Как использовать данную главу

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

  • Прочитайте разделы «Обзор системы управления проектами» и «Задачи, традиционно решаемые системой управления проектами», чтобы понять, какие проблемы пытается решать система управление проектами TFS.
  • Раздел «Стратегии работы над групповым проектом» поможет выбрать стратегию создания и организации группового проекта.
  • Остальные разделы помогут лучше понять шаблоны процессов, рабочие элементы и другие возможности управления проектами.

Обзор системы управления проектами

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

  1. Концептуальное описание проекта. На этом этапе создается представление о том, какой конечный результат от проекта хотят получить все заинтересованные стороны.
  2. Формирование сценариев. На этом этапе на базе исходных данных заказчиков вырабатывается исходных набор сценариев использования разрабатываемого программного обеспечения. Также здесь выполняется оценка того, заинтересован ли заказчик в таких сценариях.
  3. Формирование набора функциональных возможностей для поддержания выработанных сценариев. На данном этапе сценарии разбиваются на отдельные элементы, имеющие значение для заказчиков, таким образом, появляется возможность обсуждать ожидания заказчика относительно этих элементов.
  4. Формирование набора рабочих элементов. На данном этапе сценарии и функциональные возможности разбиваются на конкретные задачи. Иными словами, завершение рабочих элементов будет означать реализацию соответствующей функции или сценария.
  5. Распределение задач по областям. На данном этапе задачи распределяются по областям. Эти области выделяются на базе функциональных возможностей или в зависимости от организации конкретной группы.
  6. Создание плана работ. На данном этапе либо создается полный график выполнения работ, либо производится разбиение всей работы на итерации.

Задачи, традиционно решаемые системой управления проектами

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

  • Работа с разрозненными источниками информации. Инструменты управления проектами обычно используются изолированно, что приводит к возникновению разрозненных источников информации, которые не так просто интегрировать. Также обычно сложно свести воедино данные инструментов управления проектами с данными, предоставляемыми другими членами группы, например, учесть дефекты, выявленные изолированной системой отслеживания дефектов, при формировании показателей.
  • Сложности со сбором показателей проекта. Сбор показателей проекта очень важен для отслеживания статуса, принятия обоснованных решений и ответа на фундаментальные вопросы, такие как «Будет ли проект поставлен вовремя и будет ли выполнен бюджет?». Отвечая на такие ключевые вопросы, руководитель проекта обычно полагается на данные, полученные от 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 можно представить следующими этапами:

  1. Выбор шаблона процесса. Можно использовать или поставляемый стандартный шаблон, или создать собственный.
  2. Создание группового проекта. В основу проекта ляжет ваш шаблон процесса.
  3. Добавление в групповой проект соответствующих групп и членов.
  4. Принятие решения о продолжительности итерационного цикла проекта. Включает создание итераций в групповом проекте.
  5. Регистрация сценариев в TFS как рабочих элементов.
  6. Определение того, какие сценарии должны быть завершены в каждой итерации.
  7. Определение нефункциональных требований. Связь нефункциональных требований со сценариями.
  8. Разбиение сценариев на истории с целью обеспечить разработчиков управляемыми рабочими элементами. Разработчики предоставляют предварительные оценки по срокам выполнения для каждого рабочего элемента.
  9. Создание графика выполнения проекта. Создается график выполнения проекта (с помощью Microsoft Project) и добавляется в Team Project.
  10. Определение критериев приемки. Определяются критерии приемки рабочих элементов (соотносящиеся с требованиями QoS).
  11. Определение требований к отчетам. Определяются ключевые показатели выполнения проекта и оговариваются требования к составляемым отчетам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблоны процессов MSF для гибкой разработки ПО и MSF для совершенствования процесса согласно CMMI

С VSTS поставляются следующих два шаблона процессов.

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

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

Безопасность и права доступа

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

  • Project Administrator (Администратор проекта)
  • Contributor (Участник)
  • Reader (Читатель)
  • Build Services (Сервисы сборки)

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

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

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

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

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

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

Шаблон процесса MSF для гибкой разработки ПО

Типы рабочих элементов, предоставляемые данным шаблоном процесса:

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

Шаблон процесса MSF для совершенствования процесса согласно CMMI®

Типы рабочих элементов, предоставляемые данным шаблоном процесса:

  • Требование — Фиксирует требования, определенные на этапе сбора требований.
  • Запрос о необходимости внесения изменения — Фиксирует любые запросы на внесение изменений, возникающие после сбора требований.
  • Проблема — Представляет проблемы проектов, которые должны отслеживаться.
  • Задача — Представляет единицу работы, которая должна быть выполнена. У каждой роли собственные требования к задаче. Например, разработчик использует задачи разработки для распределения работ.
  • Рецензия — Представляет единицы работы по составлению отзывов, например, рецензия исходного кода, рецензия проектирования и т.д.
  • Дефект — Используется для сообщения о потенциальной проблеме в системе.
  • Риск — Используется для выявления и управления рисками в проекте.

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

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

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

Подробнее об этом рассказывается в статье «Working with Work Items in Microsoft Project» (Работа со списками рабочих элементов в 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» (Работа со списками рабочих элементов в Microsoft Excel) (http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx ).

Ход выполнения работ и составление отчетов

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

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

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

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

Заключение

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

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

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

  • Более подробно об управлении и организации проектов по разработке ПО с использованием VSTS рассказывает статья «Visual Studio 2005 Team System: Software Project Management» (Visual Studio 2005 Team System: Управление проектом по разработке ПО) по адресу http://msdn2.microsoft.com/en-us/library/aa302181.aspx .
  • Более подробная информация об использовании Microsoft Office Excel для решения задач по управлению проектами приведена в статье «Working with Work Item Lists in Microsoft Excel» по адресу http://msdn2.microsoft.com/en-us/library/msl81694(VS.80).aspx .
  • Подробнее об использовании Microsoft Office Project для решения задач по управлению проектами рассказывает статья «Working with Work Items in Microsoft Project» по адресу http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx .

<< Назад

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