Типы и рабочий процесс рабочего элемента шаблона процесса Scrum
Для планирования проекта по разработке программного обеспечения и отслеживания дефектов ПО с помощью Scrum команды используют типы рабочих элементов "Элемент невыполненной работы" (PBI) и "Ошибка". Для лучшего понимания портфеля функций, сценариев или взаимодействия с пользователем владельцы продуктов и руководители программ могут сопоставлять PBI и ошибки с функциями. Если команды работают в спринтах, они определяют задачи, которые автоматически связываются с PBI и ошибками.
С помощью Microsoft Test Manager и Team Web Access (TWA) тестировщики создают и выполняют тестовые случаи и создают ошибки, чтобы отслеживать дефекты кода. Препятствия используются для отслеживания блокирующих проблем.
Определение невыполненной работы с использованием PBI и ошибок
При определении элемента невыполненной работы необходимо сосредоточиться на значимости для заказчиков и избегать описания путей разработки этой функции командой. Владелец продукта может расставлять приоритеты элементов невыполненной работы в зависимости от ценности элемента для бизнеса, трудозатрат или зависимости от других элементов. Список невыполненных работ по продукту меняется по мере изменения бизнес-требований. Как правило, команды подробно описывают только элементы с наивысшим приоритетом или элементы, назначенные текущему и следующему спринту.
Элементы PBI и ошибки можно создавать на панели быстрого добавления, которая расположена на странице невыполненной работы по продукту.
Впоследствии можно открыть каждый из элементов PBI или каждую из ошибок, чтобы указать дополнительные сведения и оценить масштабы. Определив приоритетность элементов PBI и ошибок на странице невыполненной работы (которая фиксируется в поле "Приоритет невыполненной работы"), владельцы продукта могут указать, каким элементам следует отдавать более высокий приоритет.
Указав Трудозатраты для PBI и ошибок, команды могут использовать функции прогнозирования и диаграммы скорости для оценки будущих спринтов или трудозатрат. Определяя Ценность для бизнеса, владельцы продукта могут устанавливать приоритеты отдельно от изменяемого ранжирования стека невыполненной работы.
Используйте приведенные инструкции для этих важных полей. Сведения о создании ошибок см. в разделе Отслеживание дефектов кода далее в этой статье.
Поле/вкладка |
Использование |
---|---|
Оцените объем работ, необходимый для выполнения PBI, используя любую единицу измерения, удобную для команды — размер футболки, баллы истории, время. Диаграммы скорости и средства прогноза для гибкой разработки ссылаются на значения в этом поле. Это обязательное поле для создания отчетов Выполнение выпуска и Скорость. Дополнительные инструкции см. в техническом документе Оценка. |
|
Укажите число, которое отражает относительную ценность PBI по сравнению с другими PBI. Чем больше число, тем выше ценность для бизнеса. |
|
Описание (PBI) |
Предоставьте достаточно сведений для оценки объема работ, который потребуется для реализации элемента. Сконцентрируйтесь на том, для кого предназначена функция, чего желают достичь пользователи и почему. Не описывайте, как должна быть разработана функция. Предоставьте достаточно сведений, чтобы команда могла создавать задачи и тестовые случаи для реализации элемента. |
Определите, что значит «Готово», описав критерии, которые команда должна использовать для того, чтобы проверить, полностью ли реализован элемент PBI (исправлена ошибка). Перед началом работы над PBI или ошибкой следует как можно более четко определить условия приемки клиентом. Диалоги команды с клиентами для определения условий приемки способствуют общему пониманию командой ожиданий клиентов. Условия приемки можно использовать в качестве основы для приемочных тестов; это позволяет команде эффективнее оценить, выполнен ли элемент удовлетворительным образом. |
Дополнительную информацию об использовании страницы невыполненной работы по продукту см. здесь.
Отслеживание хода выполнения
Команды могут использовать канбан-доску для отслеживания хода выполнения PBI и ошибок и доску задач спринта для отслеживания хода выполнения задач. При перетаскивании элементов в новый столбец состояния поля Состояние и Причина рабочего процесса обновляются.
Типичное выполнение рабочего процесса для PBI и ошибок выглядит следующим образом.
Владелец продукта создает PBI или инженер-испытатель создает ошибку в состоянии Новая с причиной по умолчанию Новый элемент невыполненной работы.
Владелец продукта переводит элемент в состояние Утверждено, когда он достаточно подробно описан и готов к оценке трудозатрат командой. Чаще всего элементы в верхней части списка невыполненных работ по продукту находятся в утвержденном состоянии, в то время как элементы посередине и снизу — в состоянии "Новый".
Команда меняет состояние на Зафиксировано, если члены команды принимают решение выполнять работу в течение спринта.
Элемент переводится в состояние Готово, когда команда выполнила все связанные с ним задачи и владелец продукта согласен, что элемент был реализован согласно условиям приемки.
Благодаря обновлению состояния рабочего процесса команды знают, какие элементы новые, какие — выполняются, а какие — завершены. Большинство объектов WIT поддерживает переход вперед и назад из каждого состояния рабочего процесса.
Можно настроить доску канбан так, чтобы она поддерживала дополнительные дорожки или столбцы. Или можно настроить рабочий процесс для PBI и WIT-элементов задач. При этом изменятся заголовки столбцов по умолчанию.
Сведения об использовании этих инструментов см. в разделах Работа на доске канбан и Работа в спринтах.
Сопоставление PBI с функциями
При управлении набором продуктов или взаимодействиями с пользователями может быть нужно просмотреть область и ход выполнения работы по портфелю продуктов. Это можно сделать, определив функции и сопоставив PBI с ними.
На странице невыполненной работы функции можно быстро добавлять функции так же, как и PBI.
Рабочий элемент функции содержит поля, которые аналогичны предоставляемым для PBI. В дополнение к приоритету и ценности для бизнеса можно указать конечную дату, к которой должна быть реализована функция.
Если на странице невыполненной работы включено сопоставление, можно перетаскивать элементы PBI в функцию, которую они реализуют.
Это сопоставление создает ссылки "родитель-потомок" между функциями и PBI. Ссылки записываются на вкладке Реализация.
С помощью невыполненных работ портфеля можно переходить от одной невыполненной работы к другой, чтобы получить сведения с необходимым уровнем детализации. Кроме того, невыполненные работы портфеля можно использовать для просмотра свертки работы, выполняемой несколькими командами, при настройке иерархии команд.
Определение задач, необходимых для реализации PBI и ошибок
Когда управление работой команды организовано в виде спринтов, можно использовать страницу невыполненных работ спринта для разбиения работы, которую необходимо выполнить, на определенные задачи.
Дайте задаче имя и оцените связанный с ней объем работы.
С помощью Scrum команды планируют работу и определяют задачи в начале каждого спринта, и каждый участник команды выполняет часть этих задач. Задачи могут включать разработку, тестирование и другие виды работ. Например, разработчик может определить задачи по реализации PBI, а инженер-испытатель — задачи по созданию и выполнению тестовых случаев.
Если команды оценивают работу в часах или днях, они определяют задачи и поля Оставшаяся работа и Активность (необязательно).
Поле |
Использование |
---|---|
Показывает, сколько часов или дней работы остается до завершения задачи. Обновляйте это поле по мере выполнения работы. Оно используется для вычисления диаграмм производительности, диаграммы сгорания спринта и формирования отчета Выполнение спринта (Scrum). Если задача делится на подзадачи, указывайте длительность оставшейся работы только для подзадач. Можно определить работу в любых удобных для команды единицах измерения. |
|
Выберите тип действия, который представляет эта задача, когда команда оценивает производительность спринта по активности. Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню). |
Отслеживание хода выполнения теста
Элементы невыполненной работы тестового продукта
Из Test Manager или TWA можно создавать тестовые случаи, которые автоматически связываются с PBI.
Тестовый случай содержит несколько полей, многие из которых автоматизированы и интегрированы с Test Manager и процессом сборки. Описание всех полей см. в разделе Справочник по полям интеграции сборки и тестирования.
На вкладке Протестированные элементы невыполненной работы перечислены все элементы PBI и ошибки в тестовом случае. Связав PBI и ошибки с тестовыми случаями, команда может отслеживать ход выполнения при тестировании каждого элемента.
Отслеживание дефектов кода с помощью ошибок
Ошибки можно создавать из TWA, Visual Studio или при тестировании с помощью Test Manager.
Поле/вкладка |
Использование |
---|---|
Запишите достаточно сведений, чтобы другие члены команды могли полностью понять значение проблемы, а также убедиться, что они исправили ошибку. Сюда входят действия, необходимые для поиска или воспроизведения ошибки и ожидаемого поведения. Опишите критерии, которые команда должна использовать, чтобы убедиться, что дефект кода исправлен. |
|
Субъективная оценка влияния ошибки на проект. Допустимые значения:
Сведения об изменении пунктов меню см. в статье Настройка списка выбора (раскрывающегося меню). |
|
Когда средство Test Manager создает ошибки, оно автоматически заносит в поля Сведения о системе и Найдено в сборке сведения о программной среде и сборке, в которых возникла ошибка. Подробнее об определении программных сред см. в статье Настройка тестовых компьютеров для выполнения тестов или сбора данных. После разрешения ошибки используйте поле Встроено в сборку, чтобы указать имя сборки, включающей код, исправляющий ошибку. Чтобы открыть получить доступ к раскрывающемуся меню, содержащему все запущенные сборки, можно обновить определения FIELD для полей "Найдено в сборке" и "Интегрировано в сборку" так, чтобы они ссылались на глобальный список. Глобальный список обновляется автоматически при каждом запуске сборки. Дополнительные сведения см. в разделе Поля, поддерживающие интеграцию с тестированием, сборками и управлением версиями. Сведения о том, как определять имена построений, см. в разделе Использование номеров сборок для назначения завершенным сборкам значимых имен. |
Определение общих полей рабочих элементов и вкладок
Следующие поля и вкладки присутствуют в большинстве форм рабочих элементов. Каждая вкладка используется для отслеживания конкретных сведений, таких как Журнал, Ссылки или Вложения. Эти три вкладки содержат журнал изменений, представление связанных рабочих элементов и возможность просматривать и вкладывать файлы соответственно.
Единственное обязательное поле — Заголовок. При сохранении рабочего элемента система присваивает ему уникальный Идентификатор.
Поле/вкладка |
Использование |
---|---|
Заголовок (обязательное) |
Введите описание (255 символов или меньше). Заголовок можно изменить впоследствии. |
Назначьте рабочий элемент участнику команды, ответственному за выполнение работы. В зависимости от рабочего контекста, в раскрывающемся меню будут только члены команды или участники командного проекта. |
|
Используйте сначала значение по умолчанию. По мере выполнения работы, обновляйте его в соответствии с текущим состоянием. Сведения об изменении раскрывающегося списка состояний см. в разделе Изменение рабочего процесса для типа рабочего элемента. |
|
Сначала используйте значение по умолчанию. Обновляйте его при изменении состояния. Каждое состояние связано с причиной по умолчанию. Сведения об изменении раскрывающего списка причин см. в разделе Изменение рабочего процесса для типа рабочего элемента. |
|
Выберите путь к области, связанной с продуктом или командой, или оставьте это поле пустым и назначьте его на планировочном собрании. Чтобы изменить раскрывающийся список областей, см. статью Добавление и изменение области и путей итерации. |
|
Выберите спринт или итерацию, когда должна быть завершена работа, или оставьте это поле пустым и назначьте его позже на планировочном собрании. Сведения об изменении раскрывающего списка итераций см. в разделе Добавление и изменение области и путей итерации. |
|
Используется для отслеживания относительного ранжирования элементов PBI и ошибок. Последовательность элементов на странице невыполненной работы по продукту определяется в соответствии с местом добавления или перемещения элементов на странице. При перетаскивании элементов фоновый процесс обновляет это поле, которое назначено типу Order в файле ProcessConfiguration. |
|
Добавьте все типы ссылок, например гиперссылки, наборы изменений, исходные файлы и т. д. На этой вкладке также перечислены все ссылки, определенные для рабочего элемента, даже определенные на других вкладках управления ссылками. |
|
Здесь можно указать более подробные сведения, добавив к рабочему элементу файлы, например цепочки электронных сообщений, документы, изображения, файлы журналов и другие типы файлов. |
|
Просматривайте журнал аудита, который ведет система, и записывайте дополнительную информацию. Сведения добавляются в журнал при каждом обновлении рабочего элемента. История включает в себя дату изменения, автора и список измененных полей. Также в поле журнала можно добавить форматированный текст. |
Сведения о других полях см. в разделе Индекс полей рабочего элемента.
Начало отслеживания работы
Чтобы начать отслеживать работу, у вас должен быть командный проект. Чтобы создать его, щелкните здесь.
Чтобы начать отслеживать работу, выполните одну или несколько из указанных ниже задач.
Чтобы ознакомиться со стандартными задачами, связанными с рабочими элементами, обратитесь к статье Начало работы с использованием рабочих элементов.
Чтобы создать невыполненную работу, воспользуйтесь TWA. См. раздел Создание списка невыполненной работы.
Чтобы создать структуру разбиения работ, воспользуйтесь Project или Excel.
Чтобы узнать, какой клиент следует использовать, см. статью Выбор клиента Team Foundation для поддержки требуемых задач.
Вопросы и ответы
В. Какое состояние рабочего процесса поддерживает Scrum?
О. Данные диаграммы показывают основные состояния прогрессии и регрессии «Функция», «Элемент невыполненной работы», «Ошибка» и «Задача». Для настройки рабочего процесса перейдите сюда.
Функция ![]() |
Элемент невыполненной работы по продукту ![]() |
Ошибка ![]() |
Задача ![]() |
Вопрос. Как устранить ошибку как дублирующуюся?
Ответ. Установите состояние "Удалено" и укажите причину "Дублируется".
Вопрос. Как добавить ссылку на существующую ошибку из средства Test Runner?
Ответ. См. раздел об обновлении существующей ошибки при использовании Test Runner.