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

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

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

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

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

Определение пользовательских историй и оценка трудозатрат с помощью баллов историй

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

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

Панель быстрого добавления, страница невыполненной работы "Истории"

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

Форма рабочего элемента для описания функциональности пользователей

Определив Баллы истории, команды могут использовать функцию прогнозирования и диаграммы скорости для оценки будущих спринтов или трудозатрат. Определив приоритетность пользовательских историй на странице невыполненной работы (которая фиксируется в поле "Ранг стека"), владельцы продукта могут указать, каким элементам следует отдавать более высокий приоритет.

Используйте следующие инструкции при заполнении формы. Так же обозначаются требуемые поля.

Поле/вкладка

Использование

Оценка описания

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

Диаграммы скорости и средства прогноза для гибкой разработки ссылаются на значения в этом поле. Это обязательное поле для создания отчета о скорости.

Дополнительные руководство см. в документе Оценка.

Риск

Субъективная оценка относительной неуверенности в успешной реализации этой пользовательской истории. Допустимые значения:

  • 1 — высокая

  • 2 — средняя

  • 3 — низкая

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

Сведения (пользовательские истории)

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

Шаги для воспроизведения (ошибки)

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

Подумайте, нужно ли включить описание значения "Готово", описав критерии, которые команда должна использовать для того, чтобы проверить, полностью ли реализована пользовательская история (исправлена ошибка).

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

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

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

Канбан-доска с обновлением состояния истории

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

Типичное выполнение рабочего процесса для пользовательской истории:

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

  • Команда меняет состояние на Активно, если члены команды принимают решение выполнять работу в течение спринта.

  • Пользовательская история перемещается в Разрешено, когда команда завершила все связанные задачи и модульные тесты для прохода истории.

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

Благодаря обновлению рабочего процесса команды знают, какие элементы новые, какие — выполняются, а какие — завершены. Большинство объектов WIT поддерживает переход вперед и назад из каждого состояния рабочего процесса.

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

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

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

Панель быстрого добавления, страница невыполненной работы портфеля компонентов

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

Форма рабочего элемента "Функция" для Agile

Вкладка Реализация сохраняет ссылки на сопоставленные пользовательские истории.

Поле

Использование

Приоритет

Субъективная оценка отношения функции к бизнесу. Допустимые значения:

  • 1: продукт не может поставляться без функции.

  • 2: (по умолчанию) продукт не может быть поставлен без функции, однако немедленного внимания функция не требует.

  • 3: реализация этой функции не является обязательной и зависит от имеющихся ресурсов, времени и риска.

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

Ценность для бизнеса

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

Конечная дата

Укажите дату, к которой функция должна быть реализована.

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

Сопоставление пользовательской истории функции

Это сопоставление создает ссылки "родительский-дочерний" от функции к пользовательским историям, зафиксированным на вкладке Реализация.

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

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

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

Ссылка "Добавить задачу" на странице невыполненной работы спринта

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

Форма рабочего элемента для задачи

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

Если команды оценивают работу в часах или днях, они определяют задачи и поля Оставшаяся работа и Активность (необязательно).

Поле/вкладка

Использование

Исходная оценка (см. примечание 1)

Оценка объема работ, необходимого для выполнения задачи. Как правило, после присвоения значения это поле не изменяется.

Оставшаяся работа

Объем работ, оставшийся для выполнения задачи. Обновляйте это поле по мере выполнения работы. Он используется для вычисления схем производительности, диаграмм сгорания спринта и следующих отчетов: Сгорание и темп работ, Оставшаяся работа и Состояние всех итераций.

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

Завершенная работа

Объем работы, затраченный на реализацию задачи.

Действие

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

Реализация

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

Это действие также поддерживает несколько отчетов, таких как Отчет "Обзор описаний функциональности" (гибкая разработка) и Отчет "Ход реализации требований" (CMMI).

Примечания.

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

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

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

Тестированные пользовательских историй

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

Выбор набора тестов и добавление тестового случая

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

Форма рабочего элемента для тестового случая

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

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

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

Форма рабочего элемента ошибки (шаблон гибкого процесса)

Поле/вкладка

Использование

Шаги для воспроизведения

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

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

Важность

Субъективная оценка влияния ошибки на проект. Допустимые значения:

  • 1 — критическая

  • 2 — высокая

  • 3 — средняя

  • 4 — низкая

Сведения об изменении пунктов меню см. в статье Определение списка выбора.

Сведения о системе

Найдено в сборке

Интегрировано в сборку

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

Чтобы открыть получить доступ к раскрывающемуся меню, содержащему все запущенные сборки, можно обновить определения FIELD для полей "Найдено в сборке" и "Интегрировано в сборку" так, чтобы они ссылались на глобальный список. Глобальный список обновляется автоматически при каждом запуске сборки. Дополнительные сведения см. в разделе Поля, поддерживающие интеграцию с тестированием, сборками и управлением версиями.

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

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

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

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

Поле/вкладка

Использование

Заголовок [обязательное]

Введите описание (255 символов или меньше). Заголовок можно изменить впоследствии.

Кому назначено

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

Состояние

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

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

Причина

Сначала используйте значение по умолчанию. Обновляйте его при изменении состояния. Каждое состояние связано с причиной по умолчанию.

Сведения об изменении раскрывающего списка причин см. в разделе Изменение рабочего процесса для типа рабочего элемента.

Область

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

Сведения об изменении раскрывающего списка областей см. в разделе Добавление и изменение области и путей итерации.

Итерация

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

Сведения об изменении раскрывающего списка итераций см. в разделе Добавление и изменение области и путей итерации.

Все ссылки

Добавьте все типы ссылок, например гиперссылки, наборы изменений, исходные файлы и т. д.

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

Вложения

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

Журнал

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

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

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

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

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

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

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

В. Как отследить значение для бизнеса?

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

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

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

Функция

Состояния рабочего процесса компонента, шаблон процесса Agile

Описание функциональности пользователей

Состояния рабочего пользовательской Истории, шаблон процесса Agile

Ошибка

Состояния рабочего процесса ошибки, шаблон процесса Agile

Задача

Состояния рабочего процесса задачи, шаблон процесса Agile

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

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

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

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