Опубликован: 25.03.2010 | Уровень: специалист | Доступ: платный
Лекция 11:

Введение в управление проектами

< Лекция 10 || Лекция 11: 12 || Лекция 12 >
Аннотация: В этой лекции: возможности Microsoft® Visual Studio® Team System по управлению проектами; стратегия создания командного проекта; создание и управление проектами в Visual Studio Team System.

Обзор

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

В Visual Studio Team System и Team Foundation Server (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. Определение требований QoS Связывание требований со сценариями.
  8. Разбиение сценариев с целью обеспечить разработчиков управляемыми рабочими элементами Разработчики предварительно оценивают сроки выполнения для каждого рабочего элемента.
  9. Создание графика проекта График создается средствами Microsoft Project и добавляется в Team Project.
  10. Определение критериев приемки Критерии завершенности рабочих элементов согласовываются с требованиями QoS.
  11. Определение требований к отчетам Определяются ключевые показатели выполнения проекта и оговариваются требования к отчетам.

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

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

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

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

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

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

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

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

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

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

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

< Лекция 10 || Лекция 11: 12 || Лекция 12 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?

Евгений Летенков
Евгений Летенков
Россия, Москва, РУДН, 2005
Алексей Корзинин
Алексей Корзинин
Россия