СМ-Консалт
 

Глава 12

Статьи Технологии Microsoft: .NET, Visual Studio Team System Коллективная разработка с использованием Visual Studio Team Foundation Server Часть V - Управление проектом

Глава 12 -  Рабочие элементы

Содержание


Полезные материалы в тему статьи:



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

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

Задачи

  • Изучить назначение и структуру рабочих элементов.
  • Описать последовательность операций рабочего элемента.
  • Научиться настраивать рабочие элементы соответственно конкретным требованиям группы.

Обзор

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

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

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

Что использовать данную главу с максимальной пользой, необходимо:

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

Сценарии и решения

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

Обычно рабочие элементы в проектах используются для:

  • Формирования требований пользователей или нефункциональных требований (QoS) для приложения.
  • Отслеживания соответствия требованиям процессов разработки и тестирования.
  • Создания задач разработки, представляющих работу, которая должна быть выполнена для реализации компонентов и функциональности приложения.
  • Создания дефектов для представления дефектов реализации компонентов и функциональности приложения.
  • Сортировки дефектов и задач соответственно приоритетам и для равномерного их распределения между членами группы.
  • Отслеживания задач разработки для оценки темпов продвижения в направлении к статусу «Написание кода полностью завершено».
  • Отслеживания дефектов и других показателей качества для определения качества приложения и его готовности к поставке.

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

Структура рабочего элемента

Каждый тип рабочего элемента можно описать следующим образом:

  • Он имеет назначение и предполагаемое использование. Например, дефекты используются для отслеживания дефектов качества, задачи - для отслеживания запланированных работ, требования QoS - для описания критических аспектов, не связанных с функциональностью, таких как требования к безопасности и производительности, и .т.д.
  • Он имеет последовательность операций, описанную посредством состояний и переходов. Например, шаги от статуса «Opened» (Открыт) к статусу «Resolved» (Решен) и «Closed» (Закрыт).
  • У него есть набор полей, которые можно устанавливать1 и запрашивать, и по которым можно составлять отчет. Например, поля Priority (Приоритет), Status (Статус) и Iteration (Итерация).

Типы рабочих элементов

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

Типы рабочих элементов шаблона MSF Agile

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

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

Типы рабочих элементов шаблона MSF CMMI

MSF CMMI содержит следующие типы рабочих элементов:

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

Последовательность операций рабочего элемента

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

Примеры последовательностей операций

Далее приведены примеры последовательностей операций двух самых распространенных типов рабочих элементов.

Задача MSF CMMI

Задача MSF CMMI может находиться в следующих состояниях:

  • Proposed (предложена). Например, предложена разработчиком, тестировщиком или архитектором.
  • Active (активна). Например, принята ведущим разработчиком или руководителем.
  • Resolved (решена). Например, решена разработчиком.
  • Closed (закрыта). Например, протестирована и закрыта тестировщиком.


На рис. 12.1 показаны все состояния и возможные переходы между ними.

 

Рис. 12.1 Переходы между состояниями рабочего элемента MSF CMMI

Дефект MSF Agile

Дефект MSF Agile может находиться в следующих состояниях:
  • Active (активен). Например, открыт тестировщиком.
  • Resolved (решен). Например, решен разработчиком.
  • Closed (закрыт). Например, протестирован и закрыт тестировщиком.
На рис. 12.2 показаны все состояния и возможные переходы между ними.

 

 

Рис. 12.2 Переходы между состояниями рабочего элемента MSF Agile

 Как настраивать рабочие элементы

Существует несколько сценариев, при которых может потребоваться изменить типы рабочих элементов, описанные в MSF Agile или MSF CMMI:

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

Для поддержания этих сценариев в TFS можно сделать следующее:

  • Добавлять/удалять типы рабочих элементов.
  • Изменять поля в существующих рабочих элементах.
  • Изменять состояния и переходы в существующих рабочих элементах.

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

Заключение

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

Шаблоны процессов MSF Agile и MSF CMMI предоставляют набор стандартных типов рабочих элементов. Для удовлетворения требованиям процесса существует возможность настроить предлагаемые или создать новые типы рабочих элементов

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

1 - любое из допустимых значений - прим. переводчика

03.01.2009

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта