Добавление ошибок в невыполненную работу или на доску задач

  • Статья

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

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

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

Развертывание

Варианты

Visual Studio Online

  • Вариант А: разрешить командам выбирать отслеживание ошибок в невыполненной работе

Локально, с обновлением TFS 2013.4

  • Вариант А: разрешить командам выбирать отслеживание ошибок в невыполненной работе

  • Вариант Б: все команды отслеживают ошибки или дополнительные типы рабочих элементов в невыполненной работе

  • Вариант В: все команды отслеживают ошибки или другие типы рабочих элементов на доске задач

Локально, без обновления TFS 2013.4

  • Вариант Б: все команды отслеживают ошибки или другие типы рабочих элементов в невыполненной работе

  • Вариант В: все команды отслеживают ошибки или другие типы рабочих элементов на доске задач

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

Если вы вносите изменения в командные проекты, предоставленные в TFS 2012, см. версию этой статьи для Visual Studio 2012.

Вариант А: разрешить командам выбирать отслеживание ошибок в невыполненной работе (Visual Studio Online или TFS 2013.4)

Каждая команда может выбрать, требуется ли отслеживать ошибки в невыполненной работе. При подключении к локальной среде TFS ее необходимо обновить до версии TFS 2013.4. (Загрузите обновление 4 для Microsoft Visual Studio 2013).

  1. Если вы не являетесь администратором команды, станьте им.

  2. На странице администрирования команды откройте меню Параметры и установите флажок для отслеживания ошибок.

    Страница настроек команды, отслеживание ошибок в невыполненной работе

    Если этот вариант не отображается, необходимо обновить конфигурацию процесса для командного проекта.

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

Обновление конфигурации процесса для поддержки отслеживания ошибок в невыполненной работе (локальное развертывание TFS)

Если возможность отслеживать ошибки в невыполненной работе отключена на странице параметров команды, проверьте или обновите следующие XML-файлы определений для командного проекта. Для обновления этих объектов вы должны быть членом группы «Администраторы проектов».

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

    Например, следующие определения верны:

    <CATEGORY name="Bug Category" refname="Microsoft.BugCategory">
    <DEFAULTWORKITEMTYPE name="Bug" />
  </CATEGORY>
  <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory">
    <DEFAULTWORKITEMTYPE name="Product Backlog Item" />
  </CATEGORY>

    Следующие определения, напротив, неверны, так как тип рабочего элемента «ошибка» включен в категорию требований.

    <CATEGORY name="Bug Category" refname="Microsoft.BugCategory">
    <DEFAULTWORKITEMTYPE name="Bug" />
  </CATEGORY>
  <CATEGORY name="Requirement Category" refname="Microsoft.RequirementCategory">
    <DEFAULTWORKITEMTYPE name="Product Backlog Item" />
    <WORKITEMTYPE name="Bug" />
  </CATEGORY>

    Сведения об обновлении раздела «Категории» см. в статье Импорт и экспорт категорий [witadmin].

  • ProcessConfiguration. Содержит элемент BugWorkItems, который определяет категорию ошибок и сопоставляет состояния рабочего процесса ошибок с метасостояниями. Например:

    <BugWorkItems category="Microsoft.BugCategory" pluralName="Bugs" singularName="Bug">
    <States>
      <State value="Active" type="InProgress" />
      <State value="Resolved" type="Resolved" />
      <State value="Closed" type="Complete" />
    </States>
</BugWorkItems>

    Кроме того, сопоставления метасостояний должны быть согласованы в RequirementWorkItems и BugWorkItems. Например, состояние Active нельзя сопоставить с состоянием Proposed в одном типе и с состоянием InProgress в другом.

    Сведения об обновлении ProcessConfiguration см. в разделе Импорт и экспорт конфигурации процесса [witadmin].

  • Определения типов рабочих элементов. Для типов рабочих элементов, включенных в категорию ошибок, должны быть определены следующие поля.

    • Поле, используемое для отслеживания трудозатрат (type=Effort в файле ProcessConfiguration), например «Баллы истории» (Microsoft.VSTS.Scheduling.StoryPoints) или «Размер» (Microsoft.VSTS.Scheduling.Size), в зависимости от того, какой шаблон процесса, Agile или CMMI, использовался для создания командного проекта.

    • Поле, используемое для отслеживания приоритета невыполненной работы (type=Order в файле ProcessConfiguration), например «Ранг стека» (Microsoft.VSTS.Common.StackRank).

    • Для командного проекта на основе MSF for CMMI поле "Тип требования" (Microsoft.VSTS.CMMI.RequirementType), так как оно есть на панели быстрого добавления для настройки процесса.

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

Проверка или обновление сопоставления столбцов на доске канбан

  1. Откройте страницу доски невыполненной работы по продукту (канбан-доску).

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

    Сообщение об ошибке показывает, что нужно настроить столбцы

  2. Откройте страницу "Настроить столбцы" и сопоставьте состояния рабочего процесса ошибок для каждого определенного столбца.

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

    Настройка столбцов для канбан-доски

Вариант Б: все команды отслеживают ошибки или другие типы рабочих элементов в невыполненной работе

Типы рабочих элементов, добавляемые в категорию требований, отображаются на страницах невыполненной работы. Чтобы ошибки отображались на странице невыполненной работы «Пользовательские истории» (Agile) или «Требования» (CMMI), внесите указанные ниже изменения в командный проект в локальном развертывании TFS.

  1. Добавьте поле, используемое для оценки трудозатрат, в определение ошибки или другого типа рабочего элемента: «Баллы истории» (Agile) или «Размер» (CMMI).

  2. Добавьте ошибку или другие типы рабочих элементов в категорию требований.

  3. Проверьте сопоставления метасостояний в конфигурации процесса.

Ниже показано, как добавить тип рабочего элемента «ошибка» для командного проекта на основе шаблона процесса MSF для Agile.

Добавление поля «Баллы истории»

  1. Экспортируйте файл определения типа рабочего элемента «ошибка».

    witadmin exportwitd /collection:" CollectionURL" /p:MyProject /n:bug /f:DirectoryPath/bug.xml

  2. Добавьте поле Баллы истории.

    <FIELDS>
. . . .
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
      <HELPTEXT>The size of work estimated for implementing the bug.</HELPTEXT>
   </FIELD>



. . . .
</FIELDS>

    Для командного проекта на основе MSF for CMMI добавьте поля Размер и Тип требования.

    <FIELD name="Size" refname="Microsoft.VSTS.Scheduling.Size" type="Double" reportable="measure" formula="sum" >
   <HELPTEXT>The size of work estimated for implementing this requirement</HELPTEXT>
</FIELD>
<FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
   <REQUIRED />
   <ALLOWEDVALUES>
      <LISTITEM value="Scenario" />
      <LISTITEM value="Quality of Service" />
      <LISTITEM value="Functional" />
      <LISTITEM value="Operational" />
      <LISTITEM value="Interface" />
      <LISTITEM value="Security" />
      <LISTITEM value="Safety" />
      <LISTITEM value="Business Objective" />
      <LISTITEM value="Feature" />
   </ALLOWEDVALUES>
   <DEFAULT from="value" value="Functional" />
</FIELD>

  3. Добавьте поле Баллы истории в макет формы.

    <FORM>
. . . 
   <Column PercentWidth="33">
      <Group Label="Planning">
      <Column PercentWidth="100">
      <Control FieldName="Microsoft.VSTS.Scheduling.StoryPoints" Type="FieldControl" Label="Story Points" LabelPosition="Left" />
       <Control FieldName="Microsoft.VSTS.Common.StackRank" Type="FieldControl" Label="Stack Rank" LabelPosition="Left" NumberFormat="DecimalNumbers" MaxLength="10" EmptyText="&lt;None&gt;" />
       <Control FieldName="Microsoft.VSTS.Common.Priority" Type="FieldControl" Label="Priority" LabelPosition="Left" />
       <Control FieldName="Microsoft.VSTS.Common.Severity" Type="FieldControl" Label="Severity" LabelPosition="Left" />          
       </Column>               
  </Group>

   </Column>
. . . 
</FORM>

    Для командного проекта на основе CMMI добавьте поля Размер и Тип требования в раздел FORM.

    <Control Type="FieldControl" FieldName="Microsoft.VSTS.Scheduling.Size" Label="Size" LabelPosition="Left" />
<Control Type="FieldControl" FieldName="Microsoft.VSTS.CMMI.RequirementType" Label="Type" LabelPosition="Left" />

  4. Импортируйте обновленное определения ошибки.

    witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"

Добавление типа рабочего элемента «ошибка» в категорию требований

  1. Экспортируйте определение категорий. Если у вас нет разрешений администратора TFS, получите их.

    witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"

  2. Добавьте тип рабочего элемента "ошибка" в категорию требований.

    <CATEGORY refname="Microsoft.RequirementCategory" name="Requirement Category">
    <DEFAULTWORKITEMTYPE name="User Story" />
    <WORKITEMTYPE name="Bug" />
</CATEGORY>

  3. Импортируйте файл категорий.

    witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"

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

  1. Экспортируйте определение конфигурации процесса.

    witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f: "DirectoryPath/ProcessConfiguration.xml"

  2. Проверьте, определено ли состояние "Разрешено" в разделе RequirementBacklog.

    <RequirementBacklog category="Microsoft.RequirementCategory" pluralName="Stories" singularName="User Story">
    <States>
      <State value="New" type="Proposed" />
      <State value="Active" type="InProgress" />
      <State value="Resolved" type="InProgress" />
      <State value="Closed" type="Complete" />
    </States>. . . 

  </RequirementBacklog>

    Если вы настроили ошибку, добавив дополнительные состояния, то добавьте сопоставления для каждого добавленного состояния. Всегда сопоставляйте последнее состояние в переходе вперед с type="Complete".

  3. Импортируйте конфигурацию процесса.

    witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"

Проверка возможности добавления ошибок в невыполненную работу по продукту

  • Откройте страницу невыполненной работы по продукту или обновите страницу, если она уже открыта.

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

    Обновленная панель с добавленным типом рабочего элемента "ошибка"

Настройка канбан-доски для сопоставления состояний ошибок с дорожками

  1. Откройте страницу доски невыполненной работы по продукту (канбан-доску).

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

    Сообщение об ошибке показывает, что нужно настроить столбцы

  2. Откройте страницу "Настроить столбцы" и сопоставьте состояния рабочего процесса ошибок для каждого определенного столбца.

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

    Сопоставление состояний рабочего процесса ошибки для каждого столбца

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

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

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

  1. Добавьте обязательные поля в определение типа рабочего элемента «ошибка».

  2. Добавьте тип рабочего элемента «ошибка» в категорию задач.

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

Ниже показано, как сделать это для командного проекта на основе шаблона процесса MSF для Agile.

Добавление обязательных полей

  1. Если у вас нет прав администратора для командного проекта, войдите в группу «Администраторы проекта».

  2. Откройте окно командной строки там, где установлены Visual Studio или Team Explorer, и введите следующее:

    cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE

    В 64-разрядной версии Windows замените %programfiles% на %programfiles(x86)%. Team Explorer можно загрузить бесплатно.

  3. Экспортируйте определение типа рабочего элемента "ошибка".

    witadmin exportwitd /collection:"CollectionURL" /p:MyProject  /n:bug /f: "DirectoryPath/bug.xml"

    Пример CollectionURL — http://MyServer:8080/tfs/TeamProjectCollectionName.

  4. Добавьте поле Действие. Если этого не сделать, конфигурация не будет является допустимой. При необходимости добавьте поля планирования, чтобы можно было отслеживать оставшуюся и завершенную работу. Поля Microsoft.VSTS.Scheduling.XXX используются в готовых отчетах, но не в инструментах планирования Agile. Если команда не использует эти поля, не следует добавить их.

    <FIELDS>
. . . 
   <FIELD name="Activity" refname="Microsoft.VSTS.Common.Activity" type="String" reportable="dimension">
      <HELPTEXT>Type of work involved</HELPTEXT>
         <SUGGESTEDVALUES>
            <LISTITEM value="Development"/>
            <LISTITEM value="Testing"/>
            <LISTITEM value="Requirements"/>
            <LISTITEM value="Design"/>
            <LISTITEM value="Deployment"/>
            <LISTITEM value="Documentation"/>
         </SUGGESTEDVALUES>
   </FIELD>
   <FIELD name="Remaining Work" refname="Microsoft.VSTS.Scheduling.RemainingWork" type="Double" reportable="measure" formula="sum">
      <HELPTEXT>An estimate of the number of units of work remaining to complete this task</HELPTEXT>
   </FIELD>
   <FIELD name="Original Estimate" refname="Microsoft.VSTS.Scheduling.OriginalEstimate" type="Double" reportable="measure" formula="sum">
      <HELPTEXT>Initial value for Remaining Work - set once, when work begins</HELPTEXT>
   </FIELD>
   <FIELD name="Completed Work" refname="Microsoft.VSTS.Scheduling.CompletedWork" type="Double" reportable="measure" formula="sum">
      <HELPTEXT>The number of units of work that have been spent on this task</HELPTEXT>
   </FIELD>
   <FIELD name="Start Date" refname="Microsoft.VSTS.Scheduling.StartDate" type="DateTime" reportable="dimension">
      <HELPTEXT>The date to start the task</HELPTEXT>
   </FIELD>
   <FIELD name="Finish Date" refname="Microsoft.VSTS.Scheduling.FinishDate" type="DateTime" reportable="dimension">
      <HELPTEXT>The date to finish the task</HELPTEXT>
   </FIELD>
. . . 
</FIELDS>

    Для командного проекта, основанного на MSF для CMMI, необходимо добавить поле "Дисциплина" и поле планирования.

    <FIELD name="Discipline" refname="Microsoft.VSTS.Common.Discipline" type="String" reportable="dimension">
        <ALLOWEDVALUES>
          <LISTITEM value="Analysis" />
          <LISTITEM value="User Experience" />
          <LISTITEM value="User Education" />
          <LISTITEM value="Development" />
          <LISTITEM value="Test" />
        </ALLOWEDVALUES>
        <HELPTEXT>The discipline to which the task belongs</HELPTEXT>
      </FIELD>

  5. Добавьте поле "Действие" и поле планирования в форму рабочего элемента. Можно просто скопировать элемент Groups, определенный в типе рабочего элемента "Задача", и заменить Groups здесь.

    <FORM>
. . . 
      <Group Margin="(10,0,0,0)">
          <Column PercentWidth="30">
            <Group Label="Status">
              <Column PercentWidth="100">
                <Control FieldName="System.AssignedTo" EmptyText="&lt;No one&gt;" Type="FieldControl" Label="Assi&amp;gned To" LabelPosition="Left" />
                <Control FieldName="System.State" Type="FieldControl" Label="Stat&amp;e" LabelPosition="Left" />
                <Control FieldName="System.Reason" Type="FieldControl" Label="Reason" LabelPosition="Left" />
              </Column>
            </Group>
          </Column>
          <Column PercentWidth="20">
            <Group Label="Planning">
              <Column PercentWidth="100">
                <Control FieldName="Microsoft.VSTS.Common.StackRank" Type="FieldControl" Label="Stack Rank" LabelPosition="Left" NumberFormat="DecimalNumbers" MaxLength="10" EmptyText="&lt;None&gt;" />
                <Control FieldName="Microsoft.VSTS.Common.Priority" Type="FieldControl" Label="Priority" LabelPosition="Left" />
                <Control FieldName="Microsoft.VSTS.Common.Activity" Type="FieldControl" Label="Activity" LabelPosition="Left" EmptyText="&lt;None&gt;" />
              </Column>
            </Group>
          </Column>
          <Column PercentWidth="30">
            <Group Label="Classification">
              <Column PercentWidth="100">
                <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
                <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
              </Column>
            </Group>
          </Column>
          <Column PercentWidth="20">
            <Group Label="Effort (Hours)">
              <Column PercentWidth="100">
                <Control FieldName="Microsoft.VSTS.Scheduling.OriginalEstimate" Type="FieldControl" Label="Original Estimate" LabelPosition="Left" />
                <Control FieldName="Microsoft.VSTS.Scheduling.RemainingWork" Type="FieldControl" Label="Remaining" LabelPosition="Left" />
                <Control FieldName="Microsoft.VSTS.Scheduling.CompletedWork" Type="FieldControl" Label="Completed" LabelPosition="Left" />
              </Column>
            </Group>
          </Column>
        </Group>

. . . 
</FORM>

  6. Импортируйте обновленное определения ошибки.

    witadmin importwitd /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/bug.xml"

Добавление типа рабочего элемента «ошибка» в категорию задач

  1. Экспортируйте определение категорий.

    witadmin exportcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"

  2. Добавьте ошибку в категорию задачи.

    <CATEGORY refname="Microsoft.TaskCategory" name="Task Category">
    <DEFAULTWORKITEMTYPE name="Task" />
    <WORKITEMTYPE name="Bug" />
</CATEGORY>

    Примечание

    Тип рабочего элемента «ошибка» может принадлежать сразу к двум категориям — к категории ошибок и к категории задач.

  3. Импортируйте файл категорий.

    witadmin importcategories /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/categories.xml"

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

  1. Экспортируйте определение конфигурации процесса.

    witadmin exportprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"

  2. Добавьте сопоставление метасостояний для состояния "Разрешено" в раздел TaskBacklog.

    <TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task">
    <States>
      <State value="New" type="Proposed" />
      <State value="Active" type="InProgress" />
      <State value="Resolved" type="InProgress" />
      <State value="Closed" type="Complete" />
    </States>
. . . 

  </TaskBacklog>

    Если вы настроили ошибку, добавив дополнительные состояния, то добавьте сопоставления для каждого добавленного состояния. Всегда сопоставляйте последнее состояние в переходе вперед с type="Complete".

  3. Импортируйте конфигурацию процесса.

    witadmin importprocessconfig /collection:"CollectionURL" /p:MyProject /f:"DirectoryPath/ProcessConfiguration.xml"

Проверка возможности добавления ошибок на доску задач

  1. Откройте страницу доски задач или обновите страницу, если она уже открыта.

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

    Доска задач с добавленным типом рабочего элемента "ошибка"

  3. Чтобы добавить существующие ошибки на доску задач, откройте пользовательскую историю. В этом примере пользовательская История имеет заголовок Bug debt. На вкладке ВСЕ ССЫЛКИ выберите ошибки для включения в спринт.

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

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

    Совет

    Ошибки нельзя добавлять с помощью вкладки Реализация, поскольку она предназначена только для задач.Для поддержки добавления ошибок с помощью вкладки Реализация измените раздел FORM типа рабочего элемента "пользовательская история", включив фильтр для ошибок.

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

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

В. Какие другие средства можно использовать для редактирования XML-файлов определений?

О. С помощью средства командной строки witadmin можно импортировать и экспортировать файлы определений, как показано в этом разделе. К другим средствам, с помощью которых можно выполнять эту задачу, относятся редактор процессов, доступный при загрузке TFS Power Tools или диспетчер TFS Team Project Manager — проект ресурсов сообщества на CodePlex. С помощью TFS Team Project Manager можно быстро экспортировать, изменять и импортировать XML-файлы определений, не используя интерфейс командной строки.

В. Что произойдет, если удалить тип рабочего элемента «ошибка» из категории требований для командного проекта на основе Scrum?

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

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

Вопрос. Что нужно знать о сопоставлениях метасостояний?

О. Процедуры, описанные в варианте Б и В, дают представление о том, как вносить изменения в командный проект, основанных на шаблонах процессов Agile и CMMI, предоставляемых TFS 2013. Модель состояний добавляемых типов рабочих элементов должна соответствовать сопоставлениям метасостояний, указанных в файле ProcessConfiguration. Если модель состояний и сопоставления метасостояний не соответствуют друг другу, необходимо добавить определения, как описано здесь.

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

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

  1. Измените определение рабочего элемента ошибки: добавьте поля "Действие" и "Оставшаяся работа" в разделы FIELDS и FORM.

  2. Измените определение категорий: добавьте ошибку в категорию задач и удалите ее из категории требований.

  3. Измените определение конфигурации процесса: сопоставьте состояние «Разрешено» с категорией задач и удалите его из категории требований.

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

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

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

  • Задача не была связана с родительским элементом невыполненной работы. На странице невыполненной работы спринта будут отображаться только те ошибки и задачи, которые вы связали с родительским элементом невыполненной работы (Scrum), пользовательской Историей (Agile) или требованием (CMMI), в качестве пути итерации которых указан спринт.

  • Задача является родительской для другой задачи. При создании иерархии задач отображаются только задачи дочернего уровня внизу иерархии.

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

Вопрос. Как используются поля "Приоритет невыполненной работы" или "Ранг стека"?

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