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

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

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

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

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

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

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

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

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

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

Поле/вкладка	Использование
Баллы истории	Оцените объем работ, необходимый для завершения пользовательской истории, с помощью любой единицы измерения, которую предпочитает ваша команда, например размер футболки, баллы истории или время. Диаграммы скорости и средства прогноза для гибкой разработки ссылаются на значения в этом поле. Это обязательное поле для создания отчета о скорости. Дополнительные инструкции см. в техническом документе Оценка.
Риск	Субъективная оценка относительной неуверенности в успешной реализации этой пользовательской истории. Допустимые значения: 1 - высокий 2 - средний 3 - низкий Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).
Сведения (пользовательские истории)	Работая с пользовательскими историями, указывайте достаточно сведений для оценки требуемого для реализации истории объема работы. Сконцентрируйтесь на том, для кого предназначена функция, чего желают достичь пользователи и почему. Не описывайте, как должна быть разработана функция. Предоставьте достаточно сведений, чтобы команда могла создавать задачи и тестовые случаи для реализации элемента. Шаги для воспроизведения (ошибки) Работая с ошибками, запишите достаточно сведений, чтобы другие члены команды могли понять все последствия проблемы и узнать, должны ли они исправлять ошибку. Сюда входят действия, необходимые для поиска или воспроизведения ошибки и ожидаемого поведения. Подумайте, нужно ли включить описание значения "Готово", описав критерии, которые команда должна использовать для того, чтобы проверить, полностью ли реализована пользовательская история (исправлена ошибка). Перед началом работы над пользовательской историей или ошибкой следует как можно более четко определить условия приемки клиентом. Диалоги команды с клиентами для определения условий приемки способствуют общему пониманию командой ожиданий клиентов. Условия приемки можно использовать в качестве основы для приемочных тестов; это позволяет команде эффективнее оценить, выполнен ли элемент удовлетворительным образом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поле	Использование
Приоритет	Субъективная оценка отношения функции к бизнесу. Допустимые значения: 1: продукт не может поставляться без функции. 2: (по умолчанию) продукт не может быть поставлен без функции, однако немедленного внимания функция не требует. 3: реализация этой функции не является обязательной и зависит от имеющихся ресурсов, времени и риска. Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню) [перенаправление].
Ценность для бизнеса	Укажите число, которое отражает относительную ценность функции по сравнению с другими функциями. Чем больше число, тем выше ценность для бизнеса.
Конечная дата	Укажите дату, к которой функция должна быть реализована.

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

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

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

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

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

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

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

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

Поле/вкладка	Использование
Исходная оценка (см. примечание 1)	Оценка объема работ, необходимого для выполнения задачи. Как правило, после присвоения значения это поле не изменяется.
Оставшаяся работа	Объем работ, оставшийся для выполнения задачи. Обновляйте это поле по мере выполнения работы. Он используется для вычисления схем производительности, диаграмм сгорания спринта и следующих отчетов: Сгорание и темп работ, Оставшаяся работа и Состояние всех итераций. Если задача делится на подзадачи, укажите длительность в часах только для подзадач. Можно определить работу в любых удобных для команды единицах измерения.
Завершенная работа	Объем работы, затраченный на реализацию задачи.
Действие	Выберите тип действия, который представляет эта задача, когда команда оценивает производительность спринта по активности. Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню).
Реализация	На этой вкладке собираются связи типа "родители-потомки" между пользовательскими историями и задачами. При добавлении задач в пользовательскую историю с помощью доски задач спринта можно автоматически создавать ссылки на историю. Используя задачи, можно отслеживать ход выполнения работы, производимой для завершения истории. Это действие также поддерживает несколько отчетов, таких как Отчет "Обзор описаний функциональности" (гибкая разработка) и Отчет "Ход реализации требований" (CMMI).

Примечания.

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

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

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

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

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

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

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

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

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

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

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

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

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

Поле/вкладка	Использование
Заголовок [обязательное]	Введите описание (255 символов или меньше). Заголовок можно изменить впоследствии.
Кому назначено	Назначьте рабочий элемент участнику команды, ответственному за выполнение работы. В зависимости от рабочего контекста, в раскрывающемся меню будут только члены команды или участники командного проекта.
Состояние	Когда создается рабочий элемент, значение состояния по умолчанию равно первому состоянию в рабочем процессе. По мере выполнения работ обновляйте его, чтобы отразить текущее состояние. Информацию об изменении раскрывающегося списка состояний см. в разделе Change the workflow for a work item type.
Причина	Сначала используйте значение по умолчанию. Обновляйте его при изменении состояния. Каждое состояние связано с причиной по умолчанию. Информацию об изменении раскрывающегося списка причин см. в разделе Change the workflow for a work item type.
Область	Выберите путь к области, связанной с продуктом или командой, или оставьте это поле пустым и назначьте его на планировочном собрании. Информацию об изменении раскрывающегося списка областей см. в разделе Add and modify area and iteration paths.
Итерация	Выберите спринт или итерацию, когда должна быть завершена работа, или оставьте это поле пустым и назначьте его позже на планировочном собрании. Информацию об изменении раскрывающегося списка итераций см. в разделе Add and modify area and iteration paths.
Все ссылки	Добавьте все типы ссылок, например гиперссылки, наборы изменений, исходные файлы и т. д. На этой вкладке также перечислены все ссылки, определенные для рабочего элемента, даже определенные на других вкладках управления ссылками.
Вложения	Здесь можно указать более подробные сведения, добавив к рабочему элементу файлы, например цепочки электронных сообщений, документы, изображения, файлы журналов и другие типы файлов.
Журнал	Просматривайте журнал аудита, который ведет система, и записывайте дополнительную информацию. Сведения добавляются в журнал при каждом обновлении рабочего элемента. История включает в себя дату изменения, автора и список измененных полей. Также в поле журнала можно добавить форматированный текст.

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

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

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

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

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

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

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

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

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

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

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

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

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

Это поле не отображается в форме рабочего элемента. Подробнее см. в разделе Создание списка невыполненной работы.

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

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

Функция

Пользовательская история

Ошибка

Задача

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

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

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

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