Типы и рабочий процесс рабочего элемента шаблона процесса CMMI

Команды используют типы рабочих элементов (WIT), предоставленные с помощью шаблона процесса "MSF для улучшения процесса CMMI 2013 (CMMI)", чтобы планировать проекты программного обеспечения и отслеживать ход их выполнения. Команды определяют требования для управления невыполненной работой, а затем с помощью доски канбан отслеживают ход выполнения, обновляя состояние требований.

Чтобы обеспечить понимание портфеля требований, владельцы продукта могут сопоставлять требования и функции. Если команды работают по итерациям, они определяют задачи, которые автоматически связываются с требованиями.

С помощью Microsoft Test Manager и Team Web Access (TWA) тестировщики создают и выполняют тестовые случаи и определяют ошибки, чтобы отслеживать дефекты кода.

Для поддержки дополнительных процессов CMMI команды могут отслеживать запросы на изменения, риски, проблемы и заметки, зафиксированные на собраниях, посвященных проверкам.

Планирование проекта с указанием требований и оценкой трудозатрат

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

Впоследствии можно открыть каждое из требований, чтобы посмотреть подробные сведения и оценить масштабы.

Требования задают функции и элементы продуктов, которые необходимо создать командам. Определяют требования и расставляют их по приоритету обычно владельцы продукта на странице невыполненной работы по продукту. Затем команда оценивает трудозатраты, необходимые для поставки элементов с наивысшим приоритетом.

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

Поле/вкладка	Использование
Размер (см. примечание 1)	Оцените объем работ, необходимый для выполнения требования, используя любую единицу измерения, удобную для команды — размер футболки, баллы истории, время. Диаграммы скорости и средства прогноза для гибкой разработки ссылаются на значения в этом поле. Это обязательное поле для создания диаграмм скорости.
[Приоритет [обязательно] (2)	Субъективная оценка влияния требования на продукт. Допустимые значения: 1: продукт не может быть поставлен без этого элемента. 2: (по умолчанию) продукт не может быть поставлен без этого элемента, однако немедленного внимания он не требует. 3: реализация этого элемента необязательна и зависит от имеющихся ресурсов, времени и риска.
Рассмотрение [обязательно] (2)	Указывает тип решения рассмотрения, ожидаемого для рабочего элемента. Используйте это поле, если рабочий элемент находится в состоянии "Предложено", и задайте одно из следующих значений: В ожидании (по умолчанию), Подробнее, Сведения получены и Рассмотрено.
Блокировано (2)	Указывает, имеются ли у члена команды причины, не позволяющие работать над реализацией требования или задачи или разрешением ошибки, запроса на изменение или риска. Если для отслеживания блокирующей неполадки открыта проблема, можно создать ссылку на эту проблему. Можно указать Да или Нет.
Зафиксировано [обязательно] (2)	Указывает, зафиксировано ли требование в проекте. Можно указать Да или Нет (по умолчанию).
Ранг стека (1)	Используется для отслеживания относительного ранжирования требований. Последовательность элементов на странице невыполненной работы по продукту определяется в соответствии с местом добавления или перемещения элементов на странице. При перетаскивании элементов фоновый процесс обновляет это поле, которое назначено типу Order в файле ProcessConfiguration.
(Требование) Тип [обязательно] (2)	Тип реализуемого требования. Можно указать одно из следующих значений. Бизнес-цель Возможность (по умолчанию) Функциональный Интерфейс Оперативный Качество обслуживания Обеспечение безопасности Сценарий Безопасность
Описание	Предоставьте достаточно сведений для оценки объема работ, который потребуется для реализации требования. В первую очередь укажите, для кого предназначено требование, чего хотят добиться пользователи и зачем. Не описывайте процесс разработки требования. Предоставьте достаточно сведений, чтобы команда могла создавать задачи и тестовые случаи для реализации элемента. В полях HTML можно добавлять форматируемый текст и изображения.
Анализ (Оценка влияния)	Влияние на заказчика, если требование не будет реализовано. Возможно включение сведений из модели Кано касательно того, относится ли требование к категории "Неожиданное", "Обязательное" или "Очевидное". Эти сведения записываются в виде форматируемого текста в поле HTML, соответствующее оценке влияния.
Другой	Следующие поля, расположенные на вкладке Другое, не являются необходимыми. Встроено в: номер сборки продукта, содержащий требование, запрос на изменение или исправление ошибки. Пользовательский тест приемки [обязательно] (2): состояние пользовательского теста приемки. Пройден Не пройден Не готово (по умолчанию) Готово Пропущено Сведения получены Укажите Не готово, если требование имеет состояние Активно, и Готово — если требование имеет состояние Разрешено. Исходная оценка (3): количество часов или дней на выполнение задачи. Эксперты: имена членов команды, знакомых с областью, которую представляет данное требование. Дата начала, дата завершения (3): запланированные даты начала или завершения работы. Эти поля заполняются Microsoft Project, если это средство используется для планирования.

Примечания.

1. Порядок изменения назначения полей см. в разделе Настройка средств планирования Agile для командного проекта.

2. Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).

3. Работу можно задавать в часах или днях. С этим полем не связаны конкретные единицы времени.

   При использовании Microsoft Project для назначения ресурсов и отслеживания расписания можно обновлять эти поля с помощью Project.

Отслеживание хода выполнения

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

Можно настроить доску канбан так, чтобы она поддерживала дополнительные дорожки или столбцы. Или можно настроить рабочий процесс для требований и WIT-элементов задач. При этом изменятся заголовки столбцов по умолчанию.

Типичное выполнение рабочего процесса для требования выглядит следующим образом.

• Владелец продукта создает требование в состоянии Предложено с причиной по умолчанию Новое требование.

• Владелец продукта обновляет состояние на Активно, когда начинается работа по его реализации.

• Команда меняет состояние на Разрешено после завершения разработки кода и прохождения системных тестов.

• Наконец, команда или владелец продукта переносит требование в состояние Закрыто, когда владелец продукта согласен, что оно реализовано согласно условиям приемки и прошло все проверочные тесты.

Сопоставление требований функциям

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

На странице невыполненной работы компонента можно быстро добавлять компоненты, так же, как и требования.

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

На вкладке Требования записываются ссылки на сопоставленные требования.

Поле	Использование
Ценность для бизнеса	Укажите число, которое отражает относительную ценность функции по сравнению с другими функциями. Чем больше число, тем выше ценность для бизнеса.
Конечная дата	Укажите дату, к которой функция должна быть реализована.

Если на странице невыполненной работы включено Сопоставление, можно перетаскивать требования на компонент, который они реализуют.

Это сопоставление создает ссылки "родитель-потомок" между функциями и требованиями. Ссылки записываются на вкладке Требования.

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

Определение задач, необходимых для реализации требований и отслеживания производительности и сгорания команды

Если управление работой команды организовано в виде последовательности итераций, можно использовать страницу невыполненной работы спринта, чтобы разбивать работу на отдельные задачи.

Дайте задаче имя и оцените связанный с ней объем работы.

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

Поле	Использование
Тип задачи (см. примечание 1)	Выберите тип реализуемой задачи из следующих допустимых значений: Корректирующее действие Действие по уменьшению Плановый
Дисциплина (1)	Выберите дисциплину, которую представляет эта задача, когда команда оценивает производительность спринта по действиям. Анализ Разработка Тест Обучение пользователей Взаимодействие с пользователем Это поле также используется для вычисления производительности по дисциплине. Оно присвоено типу type="Activity" в файле ProcessConfiguration. (2) Дополнительные сведения см. в разделе Реализация задач разработки.
Исходная оценка (3)	Оценка объема работ, необходимого для выполнения задачи. Как правило, после присвоения значения это поле не изменяется.
Оставшаяся работа (3)	Показывает, сколько часов или дней работы остается до завершения задачи. Обновляйте это поле по мере выполнения работы. Оно используется для вычисления диаграмм производительности, диаграммы сгорания спринта и формирования отчета Отчет "Сгорание и темп работ". Если задача делится на подзадачи, укажите длительность в часах только для подзадач. Можно определить работу в любых удобных для команды единицах измерения.
Завершенная работа (3)	Объем работы, затраченный на реализацию задачи.

Примечания.

1. Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).

2. Порядок изменения назначения полей см. в разделе Настройка средств планирования Agile для командного проекта.

3. Работу можно задавать в часах или днях. С этим полем не связаны конкретные единицы времени.

   При использовании Microsoft Project для назначения ресурсов и отслеживания расписания можно обновлять эти поля с помощью Project.

Отслеживание хода выполнения тестов по пользовательским историям и фиксация дефектов кода

Требования к тестам

Из Test Manager или TWA можно создавать тестовые случаи, которые автоматически связываются с требованием или ошибкой.

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

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

Отслеживание дефектов кода

Ошибки можно создавать из TWA, Visual Studio или при тестировании с помощью Test Manager. Дополнительные сведения см. в разделе Отслеживание ошибок.

Поле/вкладка	Использование
Основная причина	Выберите причину ошибки из следующих допустимых значений: Ошибка кода Ошибка структуры Ошибка спецификации Ошибка обмена данными Неизвестно Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).
Шаги для воспроизведения	Запишите достаточно сведений, чтобы другие члены команды могли полностью понять значение проблемы, а также убедиться, что они исправили ошибку. Сюда входят действия, необходимые для поиска или воспроизведения ошибки и ожидаемого поведения. Опишите критерии, которые команда должна использовать, чтобы убедиться, что дефект кода исправлен.
Важность	Выберите одно из следующих допустимых значений, представляющих субъективную оценку влияния ошибки на проект. 1 — критическая 2 — высокая 3 — средняя 4 — низкая Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).
Сведения о системе Найдено в сборке Интегрировано в сборку	Когда средство Test Manager создает ошибки, оно автоматически заносит в поля Сведения о системе и Найдено в сборке сведения о программной среде и сборке, в которых возникла ошибка. Подробнее об определении программных сред см. в статье Настройка тестовых компьютеров для выполнения тестов или сбора данных. После разрешения ошибки используйте поле Встроено в сборку, чтобы указать имя сборки, включающей код, исправляющий ошибку. Чтобы открыть получить доступ к раскрывающемуся меню, содержащему все запущенные сборки, можно обновить определения FIELD для полей "Найдено в сборке" и "Интегрировано в сборку" так, чтобы они ссылались на глобальный список. Глобальный список обновляется автоматически при каждом запуске сборки. Дополнительные сведения см. в разделе Поля, поддерживающие интеграцию с тестированием, сборками и управлением версиями. Сведения о том, как определять имена построений, см. в разделе Использование номеров сборок для назначения завершенным сборкам значимых имен.

Отслеживание запросов на изменение, рисков, проблем и заметок, зафиксированных на собраниях, посвященных проверкам

С помощью следующих объектов WIT команды могут отслеживать сведения, рекомендуемые процессом CMMI.

• Создавайте запросы на изменение, когда предлагается изменение любого результата работы, подлежащего управлению изменениями. Дополнительные сведения по использованию запросов на изменения см. в разделах Управление изменениями и Справочник по полям запросов на изменение (CMMI).

  

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

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

  

  Дополнительные сведения см. в разделах Управление проблемами и Справочник по полям ошибок, проблем и рисков (CMMI).

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

  

  Дополнительные сведения см. в разделах Управление рисками и Справочник по полям ошибок, проблем и рисков (CMMI).

• Создайте проверку для документирования результатов проверки разработки или кода. Члены команды могут записывать сведения о том, как структура или код соответствуют стандартам в плане правильности имен, уместности кода, расширяемости, сложности кода, сложности алгоритмов и безопасности кода.

  

  Дополнительные сведения см. в разделах Реализация задач разработки и Справочник по полям собрания по обзору (CMMI).

Определение общих полей рабочих элементов и вкладок

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

Единственное обязательное поле — Заголовок. При сохранении рабочего элемента система присваивает ему уникальный Идентификатор.

Поле/вкладка	Использование
Заголовок (обязательное)	Введите описание (255 символов или меньше). Заголовок можно изменить впоследствии.
Кому назначено	Назначьте рабочий элемент участнику команды, ответственному за выполнение работы. В зависимости от рабочего контекста, в раскрывающемся меню будут только члены команды или участники командного проекта.
Состояние	Используйте сначала значение по умолчанию. По мере выполнения работы, обновляйте его в соответствии с текущим состоянием. Сведения об изменении раскрывающегося списка состояний см. в разделе Изменение рабочего процесса для типа рабочего элемента.
Причина	Сначала используйте значение по умолчанию. Обновляйте его при изменении состояния. Каждое состояние связано с причиной по умолчанию. Сведения об изменении раскрывающего списка причин см. в разделе Изменение рабочего процесса для типа рабочего элемента.
Область	Выберите путь к области, связанной с продуктом или командой, или оставьте это поле пустым и назначьте его на планировочном собрании. Сведения об изменении раскрывающего списка областей см. в разделе Добавление и изменение области и путей итерации.
Итерация	Выберите спринт или итерацию, когда должна быть завершена работа, или оставьте это поле пустым и назначьте его позже на планировочном собрании. Сведения об изменении раскрывающего списка итераций см. в разделе Добавление и изменение области и путей итерации.
Все ссылки	Добавьте все типы ссылок, например гиперссылки, наборы изменений, исходные файлы и т. д. На этой вкладке также перечислены все ссылки, определенные для рабочего элемента, даже определенные на других вкладках управления ссылками.
Вложения	Здесь можно указать более подробные сведения, добавив к рабочему элементу файлы, например цепочки электронных сообщений, документы, изображения, файлы журналов и другие типы файлов.
Журнал	Просматривайте журнал аудита, который ведет система, и записывайте дополнительную информацию. Сведения добавляются в журнал при каждом обновлении рабочего элемента. История включает в себя дату изменения, автора и список измененных полей. Также в поле журнала можно добавить форматированный текст.

Сведения о других полях см. в разделе Индекс полей рабочего элемента.

Начало отслеживания работы

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

Чтобы начать отслеживать работу, выполните одну или несколько из указанных ниже задач.

• Чтобы ознакомиться со стандартными задачами, связанными с рабочими элементами, обратитесь к статье Начало работы с использованием рабочих элементов.

• Чтобы создать невыполненную работу, воспользуйтесь TWA. См. раздел Создание списка невыполненной работы.

• Чтобы создать структуру разбиения работ, воспользуйтесь Project или Excel.

• Чтобы узнать, какой клиент следует использовать, см. статью Выбор клиента Team Foundation для поддержки требуемых задач.

Вопросы и ответы

В. Какие состояния рабочего процесса поддерживает CMMI?

О. Данные диаграммы показывают основные состояния прогрессии и регрессии «Функция», «Требование», «Ошибка» и «Задача». Для настройки рабочего процесса перейдите сюда.

Функция

Требование

Ошибка

Задача

Вопрос. Как устранить ошибку как дублирующуюся?

Ответ. Установите состояние "Удалено" и укажите причину "Дублируется".

Вопрос. Как добавить ссылку на существующую ошибку из средства Test Runner?

Ответ. См. раздел об обновлении существующей ошибки при использовании Test Runner.