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

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

Глава 14 – Проекты MSF Agile

<< Назад

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

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

Задачи

  • Понять, когда должен использоваться шаблон процесса Microsoft® Solution Framework (MSF) для гибкой разработки ПО (MSF Agile).
  • Выяснить, как обычно группы используют шаблон процесса MSF Agile.
  • Настроить шаблон процесса MSF Agile соответственно конкретным требованиям группы.

Обзор

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

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

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

Данная глава поможет лучше понять принципы работы шаблона процесса и руководства по процессу MSF Agile. Также в ней приведены примеры успешного использования этого шаблона процесса различными группами. Чтобы извлечь максимальную пользу из этой главы, следует:

  • Прочитать раздел «Стандартные элементы MSF Agile». Чтобы подробно разобраться и понять стандартные элементы шаблона процесса MSF Agile, включая стандартные отчеты, рабочие элементы и права доступа.
  • Прочитать раздел «Примеры применения MSF Agile на практике». Чтобы увидеть, как MSF Agile успешно используется реальными группами для разработки и выпуска приложений.
  • Прочитать Главу 13 «Шаблоны процессов» . В Главе 13 «Шаблоны процессов» представлена общая информация о шаблонах процессов.

Последовательность операций для MSF Agile

Шаблон процесса MSF Agile определяет набор задач, которые должны быть выполнены в ходе итераций различными участниками жизненного цикла разработки ПО, включая бизнес-аналитиков, архитекторов, руководителей проекта, разработчиков и тестировщиков. На рис. 14.1 показаны основные работы, связанные с каждой из описанных задач.

Задача Основная работа
Создать перечень невыполненных работ по проекту Создание концептуального представления проекта
Создать архитектуру решения Создание прототипа архитектуры
Определение интерфейсов
Создание архитектуры инфраструктуры
Создать пользовательские сценарии использования Выделение сценариев
Фиксация сценариев в TFS
Расстановка приоритетов сценариев
Создать нефункциональное требование Определение целей в области безопасности
Определение целей в области производительности
Фиксация требований в TFS
Расстановка приоритетов требований
Создать план итерации Разбиение сценариев и требований на задачи разработки и тестирования
Проведение оценки задач разработки и тестирования
Планирование и распределение задач разработки и тестирования
Разработка в ходе итерации Написание кода в рамках задач разработки
Создание/обновление модульного теста для задачи разработки
Выполнение модульных тестов и проведение анализа кода
Тестирование в ходе итерации Написание тестов для проверки пригодности в рамках задач тестирования
Выполнение сценариев тестирования и проведение исследующего тестирования
Создание дефектов в состоянии «Открыт» для выявленных проблем
Проанализировать прогресс за итерацию Оценка прогресса в выполнении задач за итерацию
Сортировка дефектов, выявленных в ходе итерации
Оценка граничных значений показателей тестирования

Рис. 14.1 Задачи и ключевые работы MSF Agile

Стандартные элементы MSF Agile

При создании нового группового проекта с использованием шаблона процесса MSF Agile в основном окне Microsoft Visual Studio® отображается страница с основными положениями руководства по процессу. Это стартовая точка руководства по процессу MSF Agile. Данная информация также доступна с домашней страницы портала проекта.

Конфигурация инструментальных средств выходит за рамки описания процесса и включает рабочие элементы (такие как сценарии, нефункциональные требования (QoS), задачи, дефекты и риски), отчеты проекта, роли (группы и права доступа) и портал проекта. Шаблон MSF Agile поддерживает следующие основные элементы:

  • Рабочие элементы
  • Группы и права доступа
  • Систему контроля версий
  • Области и итерации
  • Отчеты
  • Портал

В следующих разделах более подробно рассматриваются стандартные элементы шаблона процесса MSF Agile.

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

Шаблон процесса MSF Agile включает следующие типы рабочих элементов:

  • Дефект (Bug). Представляет проблему или потенциальную проблему приложения.
  • Риск (Risk). Представляет возможное событие или условие, которое могло бы иметь негативное воздействие на проект.
  • Сценарий (Scenario). Представляет отдельную сюжетную линию взаимодействия пользователя с создаваемой системой.
  • Задача (Task). Определяет конкретный элемент работы для члена группы.
  • Нефункциональное требование (Quality of Service Requirement). Представляет нефункциональное требование, такое как безопасность, производительность или возможность обслуживания.

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

  • Настройка: Задание прав доступа (Set up: Set Permissions). Назначение этой задачи – распределить членов группы по четырем группам доступа: Сервисы сборки, Администраторы проекта, Участники или Читатели.
  • Настройка: Миграция исходного кода (Set up: Migration of Source Code). Назначение этой задачи – перенос существующего исходного кода из Microsoft Visual SourceSafe®, если происходит перенос существующего проекта в Microsoft Visual Studio Team Foundation Server (TFS). Перенос кода должен быть завершен до предоставления членам группы возможности доступа к групповому проекту.
  • Настройка: Перенос рабочих элементов (Set up: Migration of Work Items). При переносе существующего проекта в TFS можно переносить рабочие элементы, такие как дефекты и задачи из Clearquest или файл с разделенными запятыми значениями (comma-separated value, CSV). Этот перенос рабочих элементов должен быть завершен до предоставления членам группы возможности доступа к групповому проекту.
  • Настройка: Задание политик регистрации изменений в файле в системе контроля версий (Set up: Set Check-in Policies). Назначение этой задачи – определение бизнес-правил или политик регистрации изменений исходного кода.
  • Настройка: Конфигурирование сборки (Set up: Configure Build). Назначение этой задачи – первоначальное создание дерева исходного кода и настройка сборки на периодическое выполнение (обычно ежедневное).
  • Настройка: Отправка почтового сообщения пользователям для установки проекта и начала работы над ним (Set up: Send Mail to Users for Installation and Getting Started). Назначение этой задачи – отправка членам группы сообщения по электронной почте с информацией о том, с каким TFS они должны установить соединение и над каким групповым проектом должны начать работу.
  • Создание концептуального описания проекта (Create Vision Statement). Цель этой задачи – создание концептуального представления проекта, т.е. представления желаемого конечного результата проекта, одобренного всеми заинтересованными сторонами.
  • Настройка: Создание описания проекта на портале группового проекта (Set up: Create Project Description on Team Project Portal). Назначение этой задачи – изменить стандартное описание проекта, чтобы обеспечить лучшее описание нового группового проекта, например его назначения, целей или концептуального представления.
  • Создание стереотипов пользователей (Create Personas). Назначение этой задачи – создание стереотипов, которые будут представлять пользователей, взаимодействующих с системой. Стереотипы пользователей могут использоваться как целевые пользователи системы при работе над эскизом проекта приложения.
  • Определение длительности итерации (Define Iteration Length). Назначение этой задачи – определение итерационного цикла проекта, который зависит от размера и сложности проекта.
  • Создание плана стратегии тестирования, включающего показатели качества поставляемого продукта (Create Test Approach Worksheet including Test Thresholds). Назначение этой задачи – понять стратегию тестирования в самом начале работы над проектом. Понимание используемого подхода тестирования может способствовать более эффективному планированию задач тестирования и позволит разработчикам реализовывать проект с учетом потребностей тестирования.\
  • Мозговой штурм и расстановка приоритетов в списке сценариев (Brainstorm and Prioritize Scenarios List). Цель этой задачи – определить и назначить приоритеты ключевых сценариев использования.
  • Мозговой штурм и расстановка приоритетов в списке нефункциональных требований (Brainstorm and Prioritize Quality of Service Requirements List). Цель этой задачи – определить нефункциональные требования, такие как сценарии безопасности, производительности и возможности обслуживания.
  • Настройка: Создание структуры проекта (Set up: Create Project Structure). Цель этой задачи – создание структуры проекта, отражающей области, в которых будет работать группа разработки.
  • Создание плана итераций (Create Iteration Plan). Назначение этой задачи – принятие решения о распределении работ по разработке на итерации.

Отчеты

С шаблоном процесса MSF Agile доступны следующие отчеты по умолчанию:

  • Дефекты по приоритетности (Bugs by Priority). Правильно ли были выявлены дефекты? Этот отчет показывает соотношение выявленных высокоприоритетных дефектов к выявленным дефектам с низким приоритетом.
  • Частоты дефектов (Bug Rates). Насколько эффективно происходит выявление, исправление и закрытие дефектов? Данный отчет показывает общую тенденцию по выявлению новых дефектов, задержке исправления дефектов и исправлению дефектов.
  • Сборки (Builds). Каково качество сборки? Данный отчет представляет список доступных сборок, включая информацию об их качестве и другие данные.
  • Скорость выполнения проекта (Project Velocity). Насколько быстро группа выполняет работу? Данный отчет показывает, насколько быстро группа выполняет запланированную работу, и представляет темпы ежедневного изменения проекта.
  • Показатели качества (Quality Indicators). Каково качество ПО? Данный отчет сводит воедино результаты тестирования, дефекты, покрытие кода тестами и коэффициент изменения кода для удобства отслеживания качества и состояния проекта.
  • Результаты нагрузочного тестирования (Load Test Summary). Данный отчет представляет результаты нагрузочного тестирования приложения.
  • Регрессии (Regressions). Данный отчет представляет список всех тестов, которые ранее были пройдены успешно, но теперь дают сбой.
  • Реактивации (Reactivations). Сколько рабочих элементов было реактивировано? Данный отчет показывает рабочие элементы, которые были разрешены или закрыты преждевременно.
  • Взаимосвязанные рабочие элементы (Related Work Items). Какие рабочие элементы зависят от других рабочих элементов? Данный отчет представляет список рабочих элементов, связанных с другими рабочими элементами, что позволяет отследить зависимости.
  • Оставшаяся работа (Remaining Work). Сколько еще работы надо сделать, и когда она будет завершена? Данный отчет показывает объем еще невыполненной, выполненной и завершенной работы с течением времени. Проецирование тенденций изменения объема оставшейся работы в будущее позволяет предсказать момент окончания работы над кодом.
  • Незапланированная работа (Unplanned Work). Каков объем незапланированных работ? Данный отчет представляет соотношение общего объема работ к оставшемуся и распознает запланированную и незапланированную работу.
  • Очередность работ (Triage). Для каких рабочих элементов необходимо установить очередность работ? В данном отчете представлены рабочие элементы, до сих пор находящиеся в состоянии «Предложенный».
  • Рабочие элементы (Work Items). Какие рабочие элементы являются активными? В этом отчете представлен список всех активных рабочих элементов.
  • Рабочие элементы по владельцу (Work Items by Owner). По сколько рабочих элементов назначено каждому члену группы? Данный отчет показывает распределение рабочих элементов по членам группы.
  • Рабочие элементы по состоянию (Work Items by State). Сколько активных, разрешенных и закрытых рабочих элементов в проекте? Данный отчет представляет список активных, разрешенных и закрытых рабочих элементов.

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

В шаблоне процесса MSF Agile доступны следующие группы по умолчанию:

  • Читатели (Readers). Члены этой группы имеют права доступа только для чтения.
  • Участники (Contributors). Члены этой группы могут добавлять, изменять и удалять элементы группового проекта.
  • Сервисы сборки (Build Services). Члены этой группы обладают правами доступа к сервису сборки для группового проекта. Эта группа используется только для учетных записей сервисов.
  • Администраторы проекта (Project Administrators). Члены этой группы могут осуществлять в групповом проекте все операции.

Система контроля версий

MSF Agile использует следующие стандартные настройки системы контроля версий:

  • Изъятие версии файла для редактирования из системы контроля версий одновременно несколькими пользователями. По умолчанию MSF Agile допускает изъятие версии файла для редактирования из системы контроля версий одновременно несколькими пользователями, что обеспечивает возможность одновременной работы над одним файлом нескольких членов группы. Все возникающие в результате этого конфликты должны разрешаться в момент регистрации изменений.
  • Права доступа. Права доступа к системе контроля версий по умолчанию:
    • Администраторы проекта. Обладают всеми правами доступа.
    • Сервисы сборки. Имеют права на чтение, задержку внесения изменения, регистрацию изменений, маркировку, начало сборки и редактирование сборки.
    • Участники. Имеют права на чтение, задержку внесения изменений, регистрацию изменений, изъятие версии файла для редактирования, маркировку и запуск сборки.
    • Читатели. Имеют право на доступ только для чтения.

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

Стандартный шаблон процесса MSF Agile не определяет структуру классификации ни для областей, ни для итераций. Рекомендуется выделять области, исходя из компонентов или функциональных возможностей проекта. За итерации можно принять временные циклы, для которых будет повторяться определенный набор основных действий, таких как планирование, разработка и тестирование.

Примеры применения MSF Agile на практике

Следующие примеры показывают, как процесс MSF Agile был адаптирован и использован группой patterns & practices (шаблоны и практики) в рамках корпорации Microsoft, а также группой разработки, не входящей в состав Microsoft.

Пример 1: Группы patterns & practices

Следующий пример представляет выполнение типового проекта группой patterns & practices с использованием процесса MSF Agile.

Новый проект, итерация 0

  • Руководитель, ответственный за выпуск продукта:
    1. Проводит сбор требований, взаимодействуя с заказчиками и основными заинтересованными сторонами, и фиксирует их в документе Microsoft Office Word под названием Project Back Log (Перечень невыполненных работ по проекту).
    2. В Microsoft Office PowerPoint® создает концептуальное описание проекта.
    3. Методом мозгового штурма совместно с заказчиками и различными заинтересованными сторонами определяет сценарии, которые обеспечат выполнение требований и реализацию концептуального описания проекта.
    4. Совместно с руководителем проекта и другими заинтересованными сторонами определяет приоритетность сценариев.
  • Руководитель проекта:
    1. Фиксирует сценарии как рабочие элементы в TFS.
    2. В зависимости от размера проекта выбирает продолжительность итерационного цикла и объемы поставок.

Предварительное планирование

  • Руководитель проекта на основании приоритетов сценариев выбирает те из них, которые будут разрабатываться во время итераций.
  • Руководитель, ответственный за выпуск продукта, вместе с руководителем проекта вырабатывает нефункциональные требования (QoS) для сценария. QoS затем связываются со сценариями.

Планирование итерации

  • Руководитель проекта:
    1. Совместно с разработчиками и другими членами группы разбивает сценарии на задачи разработки.
    2. Фиксирует задачи разработки в TFS и связывает их со сценариями.
    3. Определяет критерий приемки для каждой задачи разработки.
    4. Разбивает требования QoS на задачи тестирования.
    5. Фиксирует задачи тестирования в TFS и связывает их с QoS.
    6. Определяет критерий приемки для каждой задачи тестирования.
    7. Планирует и распределяет задачи между исполнителями.
  • Разработчик проводит предварительную оценку времени, необходимого на выполнение каждой из задач разработки.

Важно – Если для реализации задачи (разрабатываемой пользовательской истории) по предварительным оценкам может потребоваться больше одного-двух дней, ее следует разбить на подзадачи.

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

Во время итерации

  • Руководитель проекта управляет итерацией.
  • Разработчик пишет код задачи разработки и, выполнив критерий приемки, закрывает эту задачу.
  • Тестировщик выполняет назначенные задачи тестирования и создает новые дефекты (рабочие элементы) для всех выявленных проблем.

После итерации

  • Руководитель проекта:
    1. Оценивает темпы выполнения проекта и пересматривает приоритеты сценариев, оставшихся незавершенными после итерации.
    2. Предоставляет заинтересованным сторонам отчет о состоянии проекта.
    3. На основании приоритетов принимает решение о том, какие сценарии должны разрабатываться в следующей итерации.
  • Руководитель, ответственный за выпуск продукта:
    1. Добавляет вновь обнаруженные сценарии.
    2. Пересматривает приоритеты сценариев (где это необходимо).
    3. Совместно с руководителем проекта вырабатывает QoS-требования для проекта и связывает их со сценариями.

Пример 2: Привлечение конечного пользователя продукта

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

Новый проект, итерация 0

  • Бизнес-аналитик:
    1. Создает краткое (в одну страницу) концептуальное представление проекта.
    2. Выбирает пользователя в рамках своей организации, который может использоваться для получения исходных данных о продукте, и создает стереотипы пользователей системы.
    3. Путем мозгового штурма совместно с пользователем вырабатывает сценарии (только названия).
    4. Совместно с пользователем назначает приоритеты сценариев.
    5. Пишет сценарии для следующей итерации.
  • Руководитель проекта:
    1. Собирает разработчиков и получает от них предварительные оценки времени, необходимого на разработку. Даются примерные оценки по порядку величин.
    2. Проверяет, не приведет ли оценка затрат к изменению приоритетов.
    3. Планирует сценарии для следующей итерации.
  • Архитектор разбивает сценарии на архитектурные задачи.
  • Разработчик:
    1. Разбивает сценарии на задачи разработки.
    2. Определяет подходящую стратегию сборки (использует сборку в результате процесса непрерывной интеграции, если это возможно).
  • Тестировщик разбивает сценарии на задачи тестирования.

Во время итерации

  • Руководитель проекта:
    1. Управляет выполнением итерацией.
    2. Управляет выполнением проекта.
  • Архитектор определяет архитектуру решения.
  • Разработчик, реализовывает задачу по разработке.
  • Тестировщик, тестирует сценарий.

После итерации 0

В данной точке задачи немного меняются.

  • Бизнес-аналитик:
    1. Обновляет состав стереотипов пользователей системы (где это необходимо).
    2. Добавляет все вновь выявленные сценарии.
    3. Пересматривает приоритеты сценариев (где это необходимо).
    4. Пишет сценарии для предстоящей итерации.
  • Руководитель проекта:
    1. Проводит предварительную оценку для каждого нового сценария.
    2. Планирует сценарии для следующей итерации.
  • Архитектор разбивает сценарии на архитектурные задачи.
  • Разработчик:
    • Разбивает сценарии на задачи разработки.
    • Обновляет процесс сборки (с использованием процесса непрерывной интеграции, если возможно).
  • Тестировщик разбивает сценарии на задачи тестирования.

Настройка шаблона процесса MSF Agile

Существует два метода настройки шаблона процесса MSF Agile соответственно конкретным требованиям организации:

  • Настройка XML-файлов вручную. Настройка вручную чревата большим количеством ошибок, но, тем не менее, обеспечивает наиболее тонкую настройку шаблонов процессов. Более подробно об этом рассказывается в статье «Customizing Process Templates» по адресу http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx .
  • Process Template Editor (Редактор шаблонов процессов). Самая последняя версия Visual Studio 2005 Team Foundation Server Power Tool ― это набор расширений, инструментов и утилит командной строки, улучшающих работу с TFS – предоставляет графическое средство для просмотра и настройки шаблонов процессов. Подключившись к TFS, можно использовать этот инструмент для настраивания описаний типов рабочих элементов и глобальных списков активного проекта. Более подробно смотрите в разделе «Как: настроить шаблон процесса в Visual Studio Team Foundation Server».

Заключение

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

Если стандартный шаблон процесса не удовлетворяет требованиям конкретного процесса, его можно настроить двумя способами: вручную, настраивая XML-файлы описания процесса, или используя Process Editor Tool, поставляемый с TFS Power Tools.

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

<< Назад

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