Планирование проектов обычно выполняется по следующей схеме:
1. Концептуальное описание проекта На этом этапе формируется представление о том, какой конечный результат проекта хотят получить все заинтересованные стороны.
2. Формулирование сценариев На этом этапе с участием заказчика формулируется начальный набор сценариев использования ПО. Заказчик оценивает готовые сценарии с позиции собственных интересов.
3. Формирование набора функциональных возможностей для реализации выбранных сценариев На этом этапе сценарии разбиваются на отдельные компоненты, важные с точки зрения заказчика. Благодаря этому появляется возможность обсуждать ожидания заказчика в отношении этих компонентов.
4. Формирование набора рабочих элементов Сценарии и компоненты разбиваются на конкретные задачи. Завершение рабочего элемента означает реализацию соответствующей функции или сценария.
5. Распределение задач по областям Области выделяются на основе компонентов или в зависимости от организации конкретной команды.
6. Создание плана работ На этом этапе либо составляется полный график выполнения работ, либо производится разбиение работы на итерации.
В распоряжении руководителя проекта имеется множество разнообразных инструментов для управления процессом разработки ПО. Как правило, эти инструменты практически никак не интегрированы с инструментами, используемыми для разработки ПО. Отсутствие интеграции и взаимодействия между инструментарием и командами разработчиков - главная проблема руководителя проекта. Обычно ему приходится сталкиваться со следующими трудностями:
• Работа с разрозненными источниками информации. Инструменты для управления проектами обычно используются изолированно, что приводит к появлению разрозненных источников информации, которые не так просто объединить. Кроме того, обычно бывает сложно объединить данные по управлению проектом с данными, предоставляемыми другими членами команды, например, учесть при формировании показателей ошибки, выявленные изолированной системой отслеживания ошибок.
• Сложности со сбором показателей проекта. Показатели проекта очень важны для контроля за его состоянием, принятия обоснованных решений и получения ответа на фундаментальные вопросы, например, "Будет ли проект поставлен вовремя и будет ли выполнен бюджет?". Отвечая на ключевые вопросы, руководитель проекта обычно полагается на данные Microsoft Office Project или системы отслеживания ошибок, используемой группами разработки и тестирования. Объединить данные, предоставляемые этими несопоставимыми системами, сложно, на это уходит много времени, к тому же, в процессе сведения данных легко допустить ошибки. Для большинства показателей, формируемых инструментарием, не существует унифицированной системы хранения и доступа. Создание отчетов по таким данным – это обычно напряженный ручной труд, связанный с многократным копированием и вставкой информации из разных источников.
• Сложности с выполнением требований. Зачастую работа, запланированная для группы разработки, требования заказчика и основные нефункциональные требования к создаваемой системе существенно отличаются друг от друга. Запланированный и фактический объемы могут существенно отличаться. Из-за этих несоответствий теряются важные данные, что приводит к невыполнению требований.
• Управление процессами и изменения в них. Объяснить команде, каких процессов она должна придерживаться, очень сложно. Еще сложнее внести изменения в процессы для решения возникающих проблем, не снизив при этом производительности команды.
• Недостаток учитываемого обмена информацией и отслеживания задач. Взаимодействие и слаженность команды обычно обеспечиваются при помощи совещаний и списков задач, и текущее положение дел по их выполнению, что позволяет правильно выбрать приоритеты. При этом отслеживать процесс выполнения отдельной задачи может быть очень сложно. Также руководители проектов часто тратят массу ценного времени на извлечение информации о состоянии работ из разных планов и списков. Члены команды тратят время на отчеты о состоянии и обновление различных документов и форм.
• Контроль качества. Предсказать количество и серьезность ошибок в создаваемом ПО сложно, поэтому обычно плановые оценки и затраты основываются на "оптимистических предположениях". Эти оценки традиционно делаются с запасом, величина которого зависит от степени уверенности руководителя в текущем состоянии проекта.
Система VSTS призвана помочь в решении многих традиционных проблем, с которыми сталкиваются руководители проектов. Интегрированные в нее инструменты помогают командам совершенствовать процесс разработки ПО, а руководителям проектов - лучше контролировать этот процесс.
Основные функции 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 разделяется на следующие этапы:
1. Выбор шаблона процесса Можно использовать стандартный шаблон или создать собственный.
2. Создание командного проекта В основу проекта ляжет выбранный шаблон.
3. Добавление в командный проект групп и членов.
4. Разработка итерационного цикла проекта Включает создание итераций.
5. Преобразование сценариев в рабочие элементы TFS.
6. Выбор сценариев, которые должны быть завершены в каждой итерации.
7. Определение требований QoS Связывание требований со сценариями.
8. Разбиение сценариев с целью обеспечить разработчиков управляемыми рабочими элементами Разработчики предварительно оценивают сроки выполнения для каждого рабочего элемента.
9. Создание графика проекта График создается средствами Microsoft Project и добавляется в Team Project.
10. Определение критериев приемки Критерии завершенности рабочих элементов согласовываются с требованиями QoS.
11. Определение требований к отчетам Определяются ключевые показатели выполнения проекта и оговариваются требования к отчетам.
Безопасность и разрешения
При создании проекта в TFS в нем независимо от выбранного шаблона создаются четыре группы, каждая из которых по умолчанию располагает теми или иными правами, определяющими, что разрешается делать членам этой группы:
• Project Administrator - администратор проекта;
• Contributor - участник;
• Reader - читатель;
• Build Services - сервисы сборки.
Чтобы максимально удовлетворить требованиям по безопасности конкретной организации, в проекте можно создавать группы доступа самостоятельно. Это эффективный способ предоставить группе пользователей в командном проекте конкретный набор полномочий. Для повышения безопасности проекта следует давать группе лишь минимально необходимые права и вводите в нее только тех пользователей или другие группы, которым эти права необходимы.
Создав группу, вы добавляете ее в список, предоставляете ей соответствующие права и включаете в нее членов. По умолчанию вновь созданная группа командного проекта не получает никаких прав.
Чтобы начать работать с TFS, необходим, по крайней мере, один командный проект. Когда руководитель проекта создает новый проект, одновременно создается веб-сайт проекта с библиотеками документов, в которых содержатся шаблоны документов и отчеты. Также создается база данных рабочих элементов для отслеживания всех работ по проекту. Устанавливается шаблон методологии, определяющий правила, политики, группы доступа и запросы для всех работ по проекту. В системе управления исходным кодом создается ветвь исходного кода.
Выбирая структуру командного проекта, в первую очередь необходимо руководствоваться требованиями к ПО. Структура проекта может меняться в процессе работы. Существует три основных стратегии создания нового проекта, которые могут использоваться по отдельности или в сочетании друг с другом:
• Один проект на приложение. Это самая распространенная стратегия создания командных проектов. Такой подход уместен при разработке как крупных, так и небольших приложений, а также для параллельной разработки нескольких версий одного приложения. При таком подходе для каждого приложения, находящегося в разработке, создается по одному проекту.
• Один проект на выпускаемую версию. Этот подход удобен для больших команд, работающих над долгосрочными проектами. Новый проект создается после выпуска каждой новой версии, и все начинается с нуля. При этом не приходится беспокоиться о переносе ресурсов предыдущего проекта, включая рабочие элементы. Кроме того, этот подход позволяет улучшить шаблоны процессов или использовать новые на основании приобретенного опыта и знаний.
• Один проект на команду. Этот подход удобен в больших проектах, над которыми работают несколько команд, там, где особенно важны централизованное управление и мониторинг процесса разработки. При таком подходе отдельный проект создается для каждой команды. Каждая команда соотносится с последовательностями операций, которые определяются типами рабочих элементов TFS, и располагает единым блоком для создания отчетов.
Ввиду того, что процессы ЖЦ разработки интегрированы в VSTS, обмен рабочими элементами между членами команды можно в значительной степени автоматизировать.
Шаблоны процессов
В VSTS для определения набора инструкций и артефактов, например, руководств по процессу, шаблонов документов, стандартных рабочих элементов и т. д., используются шаблоны процессов. Шаблон процесса - это независимый набор инструкций, описывающих методологию разработки ПО для команд разработчиков. В шаблон процесса включаются следующие элементы:
• Руководство по процессу. Предоставляется для каждого шаблона и содержит контекстно-зависимую информацию, справку и указания членам команды, нуждающимся в помощи и понимании определенной деятельности. Руководство по выполнению процесса интегрировано в Visual Studio Help System.
• Шаблоны документов. Позволяют членам команды единообразно создавать новые документы (спецификации, оценки рисков и планы проектов).
• Рабочие элементы и последовательность операций. У каждого типа рабочих элементов имеется собственный набор атрибутов и правил, определяющих последовательность операций рабочего элемента и распределение работ между членами команды.
• Группы безопасности. Используются для определения прав по управлению и изменению отчетов, результатов работы, например, исходного кода и документации, и рабочих элементов. Администрировать группы безопасности проекта может его руководитель, для этого ему не обязательно быть администратором Windows.
• Политики возврата после правки. Используются для применения правил и порогов качества ко всему коду, возвращаемому в систему управления исходным кодом. Например, можно поставить условие, что весь возвращаемый код должен отвечать определенному критерию, скажем, соответствовать корпоративным стандартам написания кода, или должен подвергаться модульному тестированию.
• Отчеты. Используются для мониторинга исполнения процессов и текущего состояния проекта. В VSTS встроено множеством отчетов, включая отчеты о качестве кода, о соблюдении графика работ, об эффективности тестирования и др. Можно создавать собственные отчеты и настраивать существующие.
Рабочие элементы используются в качестве блоков работы для обмена информацией и координации совместной деятельности в команде. Выбранный шаблон процесса предоставляет исходный набор типов рабочих элементов. Руководители проекта создают и организуют дополнительные рабочие элементы, которые необходимы в проекте. Рабочий элемент может описывать задачу, риск, сценарий, ошибку или требование QoS. Для лучшей управляемости можно устанавливать связи между рабочими элементами, например, связать определенную задачу с соответствующим ей сценарием или требованием QoS (Quality of Service requirement – качество обслуживания требований).
В шаблоне процесса имеются описания типов рабочих элементов, включая набор полей для каждого типа. Правильный выбор шаблона очень важен, поскольку в ходе выполнения проекта изменить его уже нельзя. При необходимости шаблон процесса можно дополнительно настроить, включив в него все необходимые типы рабочих элементов, отсутствующие в базовом шаблоне.
В шаблонах MSF Agile и MSF CMMI предусмотрен стандартный набор рабочих элементов с задачами, достаточными для начала процесса разработки ПО.
Шаблон MSF Agile
В этом шаблоне имеются следующие типы рабочих
• Сценарий (scenario) Используется для представления взаимодействия пользователя с приложением. Описывает конкретные шаги, необходимые для достижения цели. Сценарии должны быть конкретными, поскольку возможных способов действия может быть несколько.
• Задача (task) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
• Требование QoS (Quality of Service requirement) Документирует характеристики системы, например, производительность, нагрузку, доступность, устойчивость к нештатным условиям эксплуатации, специальные возможности и удобство обслуживания.
• Ошибка (bug) Используется для информирования о потенциальной проблеме в системе.
• Риск (risk) Используется для выявления и управления рисками в проекте.
Шаблон MSF CMMI
В этом шаблоне имеются следующие типы рабочих элементов:
• Требование (requirement) Фиксирует функциональные требования, определенные на этапе сбора требований.
• Запрос на изменение (change request) Фиксирует любые запросы на внесение изменений, возникающие после этапа сбора требований.
• Проблема (issue) Проблемы, исправление которых необходимо отслеживать.
• Задача (task) Используется для представления блока работы. У каждой роли свои требования к задачам. Например, разработчик использует для распределения работ задачи разработки.
• Рецензия (review) Блок работы по составлению отзывов, например, рецензии исходного кода, проекта и пр.
• Ошибка (bug) Используется для информирования о потенциальной проблеме в системе.
• Риск (risk) Используется для выявления и управления рисками в проекте.
Интеграция с Microsoft Project
В VSTS и приложении Team Explorer имеются расширения для Microsoft Project. В крупных проектах, где задействовано большое количество ресурсов, для работы с графиком работ по проекту в TFS можно использовать Microsoft Office Project. Можно, например, управлять и планировать работы, назначать их, распределять и отслеживать, а затем, когда результаты готовы к использованию другими членами команды, публиковать их в базе данных рабочих элементов.
Интеграция с Microsoft Excel
В VSTS и приложении Team Explorer имеются расширения для Microsoft Excel. В крупных проектах, где задействовано большое количество рабочих элементов, можно использовать интеграцию с Excel: создавать рабочие элементы в электронной таблице Excel и загружать их в базу данных рабочих элементов для использования другими членами команды.
Контроль выполнения работ и отчеты
Отчеты предназначены для оперативного оценивания состояния проекта, качества разрабатываемого ПО, а также определения этапа, на котором находится проект. Отчеты формируются на основе данных из хранилища TFS и содержат показатели, поступающие от рабочих элементов, системы управления исходным кодом, тестирования и сборок.
Например, с помощью отчетов можно выяснить темпы работы команды на основании ее фактической деятельности. Задача системы создания и отображения отчетов TFS – предоставление интегрированных данных по всем компонентам VSTS, чтобы руководители проекта и члены команды могли оценить состояние проекта и предпринять соответствующие действия для его успешного выполнения.
Отчеты, доступные по умолчанию, определяются используемым шаблоном проекта, но существует также возможность создания собственных отчетов. Содержимое и использование каждого отчета из шаблона процесса, объясняется в руководстве для этого шаблона. Team Foundation Server основан на Microsoft SQL Server и использует SQL Server для хранения всех данных, связанных с рабочими элементами, атрибутами качества, тестированием, результатами тестирования и результатами сборок. Для объединения и анализа этих данных и создания отчетов в TFS используются службы SQL Server Analysis Services. Отчеты, созданные шаблоном процесса или отдельными членами команды с помощью Microsoft Office Excel или Visual Studio 2005 Report Designer, доступны при помощи SQL Server 2005 Reporting Services и портала Share Point команды.
Сценарии и решения
Рабочие элементы (work item) - основной инструмент руководителя проекта и ведущих разработчиков для отслеживания работ по проекту: что уже сделано и что еще предстоит сделать. Члены команды используют рабочие элементы для отслеживания собственной последовательности задач и для распределения работ, например, в форме ошибок или задач.
Обычно рабочие элементы в проектах используются в следующих целях:
• Формирование требований пользователей или требований QoS к приложению.
• Контроль соответствия процессов разработки и тестирования этим требованиям.
• Создание задач разработки, представляющих действия, которые необходимо выполнить для реализации компонентов и функций приложения.
• Создание ошибок для представления дефектов в реализации компонентов и функций приложения.
• Сортировка ошибок и задач для расстановки приоритетов и распределения между членами команды.
• Отслеживание задач разработки для оценки темпов продвижения к завершению кода.
• Отслеживание ошибок и других показателей качества для определения качества приложения и его готовности к поставке.
Использование рабочих элементов в проекте определяется тем, какие типы рабочих элементов заданы в проекте. Описания рабочих элементов хранятся в шаблоне процесса, выбранном при создании проекта. Можно выбрать один из двух стандартных шаблонов - MSF Agile или MSF CMMI - или настроить рабочие элементы соответственно конкретным требованиям. Типы рабочих элементов в каждом шаблоне перечислены в предыдущей лекции.
Структура рабочего элемента
Каждый тип рабочего элемента имеет типовую структуру:
• Он имеет назначение и предполагаемое использование. Например, ошибки используются для отслеживания дефектов качества, задачи - для отслеживания запланированных работ, требования QoS - для описания аспектов, не связанных с функциональностью, например, требований к безопасности, производительности и т. д.
• С ним связана последовательность операций, описываемая посредством состояний и переходов. Например, возможны состояния "Opened", "Resolved" и "Closed".
• У него есть набор полей, например, поля Priority (приоритет), Status (состояние) и Iteration (итерация), которые можно задавать, опрашивать и использовать при создании отчетов.
Последовательность операций рабочего элемента представляет все возможные состояния рабочего элемента, а также переходы между ними. Каждое состояние обычно ассоциируется с ролью TFS. Например, когдатестировщик открывает в MSF Agile новую ошибку, соответствующий рабочий элемент переходит в состояние Active. Когда разработчик исправляет ошибку, состояние рабочего элемента меняется на Resolved. Когда тестировщик подтверждает исправление ошибки, состояние меняется на Closed.
Примеры последовательностей операций
Далее приведены примеры последовательностей операций для двух самых распространенных типов рабочих элементов.
Настройка рабочих элементов
Существует несколько ситуаций, в которых может потребоваться изменение типов рабочих элементов MSF Agile или MSF CMMI:
• В рабочем элементе нет поля, которое необходимо в процессе разработки.
• Последовательность операций рабочего элемента не соответствует схеме работы команды.
• Необходим новый тип рабочего элемента.
Для разрешения этих проблем в TFS можно сделать следующее:
• Добавить (или удалить) тип рабочих элементов.
• Изменить поля существующих рабочих элементов.
• Изменить состояния и переходы существующих рабочих элементов. Подробнее о настройке рабочих элементов - в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server".