Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs

Visual Studio 2013

Корпоративные клиенты уже убедились в преимуществах отдельных групп Agile. Однако масштабирование этих подходов по группам и обеспечение гибкости в масштабе предприятия сталкивается с рядом проблем. Scaled Framework Agile® (SAFe™) предоставляет дорожную карту для решения этих задач масштабировании гибкости. А при наличии локально развернутого TFS 2013 можно использовать SAFe.

Для отслеживания критериев SAFe можно использовать командные проекты, созданные с помощью поставляемых с TFS шаблонами процессов. В этой статье описывается, как понятия SAFe соотносятся с TFS, как планировать и отслеживать проекты SAFe в TFS и как настроить TFS для поддержки SAFe.

Если вы знакомы с Scrum, но не знакомы с SAFe, посмотрите эти видео с Scaled Agile Framework Foundations от Инбар Орин, Lean Samurai.

Соотношение понятий SAFe и TFS

SAFe предоставляет ведение портфолио из нескольких групп agile. SAFe показывает, как видение портфолио соответствует иерархии групп, каждая из которых имеет собственные задачи. Эта платформа разбивает ситуации на функции и истории, над которыми группы работают в спринтах и достигают с помощью добавлений программ, Program Increments (PI) и серии выпусков. Кроме того, невыполненные работы портфолио могут помочь отследить, как результаты сопоставляются со стратегическими темами и связанными бюджетами.

Изображение любезно предоставлено Leffingwell, LLC.

Примеры в этой статье иллюстрируют, как добавить WIT-ситуации и невыполненные работы, настроить трехуровневую иерархию групп и сопоставить группы их соответствующим области и путям итераций. Примеры созданы из шаблона процесса TFS Agile. Однако изменения могут применяться к любому шаблону процесса TFS.

Портфолио, программы и группы SAFe соответствуют командным проектам и группам TFS

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

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

Невыполненные работы SAFe сопоставляются невыполненным работам TFS

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

Выпуски, итерации и спринты SAFe соответствуют итерациям TFS.

Серии выпусков, выпуски, итерации, добавления программ (PI) и спринты SAFe легко сопоставить путям итерации TFS. Совместное использование итераций в иерархии групп позволит управлять выпусками как единым целым.

Группа «Портфолио» отслеживает ситуации, которые могут охватывать несколько серий выпусков или PI. Группы программ отслеживают конечные результаты своей функции, которые поставляются с PI. И группы функций работают в спринтах, чтобы завершить несколько историй. С помощью TFS каждая группа выбирает, какие итерации будут поддерживать их для отслеживания конечных результатов их группы.

Стратегические темы и бюджеты SAFe сопоставляются тегам и полям TFS

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

Можно выполнять поиск и запрашивать теги в TFS, а также с помощью тегов создать многократно используемые запросы и отчеты.

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

Метрики SAFe и отчеты TFS

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

Загружаемая версия отчета о состоянии функций в разделе Масштабирование отчетов TFS для Agile и SAFe.

Планирование и отслеживание проектов SAFe в TFS

После настройки TFS для поддержки SAFe создайте взаимосвязи трассировки от историй вплоть до ситуаций. Также можно просматривать ход выполнения на уровнях групп «Портфолио», «Программа» и «Функция».

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

Группа «Программа» может сопоставить функции ситуациям с помощью панели сопоставления. Группы «Функция» могут использовать одинаковые действия для сопоставления функций историям.

Представление хода работ группы «Портфолио»

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

Группа «Портфолио» может также просматривать ход выполнения ситуаций на своей доске канбан.

Просмотр выполнения группы «Программа»

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

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

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

Поскольку большая часть работы группы «Программа» строится вокруг PI и цепочек выпуска, может оказаться полезным пользовательский отчет, отображающий даты запланированных поставок и что проектируется в любой заданной цепочке. Кроме того, если развертывание Team Foundation Server включает интеграцию с SQL Server Reporting Services или Project Server, можно воспользоваться богатыми возможностями отчетов и встроенными отчетами, которые предлагает каждая из этих служб.

Просмотр хода работ группы «Функция»

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

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

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

Представление диаграммы для запросов становится очень полезным в спринте инноваций и планирования (IP), когда группы «Функция» работают вместе, чтобы стабилизировать функции, запланированные для выпуска.

В отношении всего остального для отдельных групп «Функция» в основном все идет обычным образом. Они могут выполнять спринты в своем обычном ритме. Они могут использовать свои доски канбан и доски задач для отслеживания хода выполнения и разделения работы на управляемые фрагменты.

Однако теперь их прогресс для отдельных историй становится видимым их группам программ и управления портфолио. Административное представление отражает их действия.

Настроить TFS для поддержки SAFe

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

Каждый проект в Team Foundation Server имеет группу по умолчанию. Можно настроить дополнительные группы для работы на уровне программы и уровне группы функций. И группа портфолио, которая управляет ситуациями, также может переопределить группы по умолчанию.

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

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

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

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

Создание областей для поддержки иерархии групп

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

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

   

3. Затем создайте вторую области на том же дочернем уровне и назовите ее как вторую группу программ.

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

   

Создание итераций для поддержки цепочек выпуска и спринтов.

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

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

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

   

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

   

Создание и настройка групп

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

Эта структура сопоставляет следующие группы SAFe группам TFS:

• Группа портфолио -> группа верхнего уровня по умолчанию, группа Fabrikam

• Группы программы -> группы второго уровня, Fiber Suite и Service Suite

• Группы функций -> группы третьего уровня, определенные ниже Fiber Suite и Service Suite

Если требуется более подробное руководство, см Управление портфелем Agile: использование TFS для поддержки невыполненной работы между несколькими командами.

Необходимо быть администратором проекта в Team Foundation Server для выполнения этих шагов.

Создание и настройка каждой группы программы

1. На странице обзора для командного проекта создайте группу. Убедитесь, что снят флажок Создайте путь области с именем группы.

   

2. Выберите группу из списка, перейдите на страницу областей и установите флажок для пути области, созданной ранее для этой группы.

   

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

   

4. Настройте итерации, которые будут активными для группы программы. В этом примере мы настроили три дополнения программы, каждое из которых с пятью двухнедельными спринтами. Четыре спринта — это регулярные спринты, а последний спринт — это спринт инноваций и планирования (IP).

   

     

   Поскольку группа программы Fiber Suite занимается щепочками выпуска, мы выбираем PI 1, 2 и 3, но мы не выбираем отдельные спринты.

5. После выбора того, какие итерации активны для группы, добавьте пользователей в новую группу. В идеальном случае необходимо добавить координаторов scrum для каждой группы программы, владельцев продукта, а также инженеров цепочек выпуска (RTE) в группы программы, такие как Fiber Suite.

   

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

Создайте и настройте каждую группу функции

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

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

   

2. Выберите группу из списка, перейдите на страницу областей и установите флажок для пути области, созданной ранее для этой группы.

   

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

   

4. Добавьте учетные записи для разработчиков, инженеров-испытателей и координатор Scrum для группы. TFS поддерживает назначение координатора scrum нескольким группам. Координатор Scrum может отслеживать работу нескольких групп.

   

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

Настройка группы портфолио

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

1. На странице областей для командного проекта измените параметры, чтобы подобласти не включались. Убедитесь, что выбран командный проект, а не группа по умолчанию, Fabrikam.

   

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

   

3. Добавьте и удалите пользователей из группы портфолио, соответствующей этому уровню. На странице обзора выберите группу по умолчанию.

   

      

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

   

Настройка процесса TFS для поддержки SAFe

В этом разделе мы добавим WIT ситуации в иерархию невыполненной работы портфеля. Также мы добавим поле Тип требования во все три WIT невыполненной работы. И мы создадим некоторые ситуации и сопоставим функции ситуациям.

Если вы заинтересовались принципами работы после добавления уровня невыполненной работы ситуации, то теперь перейти к разделу. Кроме того, если вы предпочитаете не делать шаги настройки, описанные в этом разделе, самостоятельно, у ALM Rangers журнал и пример сценария PowerShell , показано, как установить эти настройки в проекте.

Добавление ситуации в невыполненную работу портфеля

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

Во-первых, мы будем экспортировать существующий тип рабочего ЭЛЕМЕНТА и использовать его в создании нового типа рабочего ЭЛЕМЕНТА, который мы будем называть ситуацией. Также мы добавим поле Тип требования для отслеживания, какого рода ситуации: архитектура или бизнес. Далее мы добавим категорию для ситуаций. Затем будут изменены существующие элементы WIT: функции и истории пользователей, даже если они так не названы, чтобы и они включали поле Тип требования. Поле Тип требования отслеживает тип цели, который поддерживает каждый рабочий элемент. И наконец, мы добавим ситуацию в невыполненную работу портфеля группы.

Добавление Epic WIT

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

Мы будем экспортировать тип рабочего ЭЛЕМЕНТА функции и использовать в качестве основы для WIT-ситуации.

1. В режиме администратора откройте окно группной строки. Перейдите в каталог, в котором установлена Visual Studio (или Team Explorer).

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

   Для 64-разрядных версий Windows используйте %programfiles(x86)%.

2. Используйте средство witadmin, чтобы загрузить определение WIT функции, и сохраните его как Epic.xml.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Epic.xml"

3. Откройте файл Epic.xml, замените <WORKITEMTYPE name="Feature"> на <WORKITEMTYPE name="Epic">и обновите описание.

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
   <WORKITEMTYPE name="Epic">
      <DESCRIPTION>Tracks an Epic that will span Releases. </DESCRIPTION>
   

4. Измените <Tab Label="Implementation"> или для CMMI раздел <Tab Label="Requirements">, заменив следующие строки на <Filter WorkItemType="Feature" />.

   • Agile <Filter WorkItemType="User Story" />

   • Scrum: <Filter WorkItemType="Product Backlog Item" />

   • CMMI: <Filter WorkItemType="Requirement" />

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

   <Tab Label="Implementation">
      <Control Type="LinksControl" Name="Hierarchy" Label="" LabelPosition="Top">
         <LinksControlOptions>
             <WorkItemLinkFilters FilterType="include">
                <Filter LinkType="System.LinkTypes.Hierarchy" FilterOn="forwardname" />
             </WorkItemLinkFilters>
             <WorkItemTypeFilters FilterType="include">
                <Filter WorkItemType="Feature" />
             </WorkItemTypeFilters>
             <ExternalLinkFilters FilterType="excludeAll" />
             <LinkColumns>
                <LinkColumn RefName="System.ID" />
                <LinkColumn RefName="System.Title" />
                <LinkColumn RefName="System.AssignedTo" />
                <LinkColumn RefName="System.State" />
                <LinkColumn LinkAttribute="System.Links.Comment" />
             </LinkColumns>
          </LinksControlOptions>
   

5. Добавьте поле Тип требования к определению WIT ситуации. Для этого мы собираемся воспользоваться существующим полем (созданным для поддержки проектов CMMI, но тем не менее полезным для наших целей здесь) Microsoft.VSTS.CMMI.RequirementTypeи добавим его в раздел FIELDS ситуации.

   Найдите раздел FIELDS и добавьте следующий код:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
      <REQUIRED />
      <ALLOWEDVALUES>
         <LISTITEM value="Architecture" />
         <LISTITEM value="Business" />
      </ALLOWEDVALUES>
      <DEFAULT from="value" value="Business" />
      <HELPTEXT>Indicates whether this supports business or architectural objectives.</HELPTEXT>
   </FIELD>
   

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

   <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" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   

7. Сохраните и затем импортируйте файл.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Epic.xml"

Добавьте категорию Epic

Теперь, когда у нас есть ситуация WIT, мы добавим категорию для ситуаций. TFS управляет невыполненными работами на основе категорий.

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

   witadmin exportcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

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

   <CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
      <DEFAULTWORKITEMTYPE name="Epic" />
   </CATEGORY>
   

3. Как и раньше, импортируйте файл.

   witadmin importcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

Добавьте поле Тип требования для отслеживания работы бизнеса и архитектуры

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

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

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Feature.xml"

2. Добавьте поле Тип требования, как это делалось ранее с WIT ситуацией. Найдите раздел FIELDS и добавьте следующий код:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
       <REQUIRED />
       <ALLOWEDVALUES>
           <LISTITEM value="Architecture" />
           <LISTITEM value="Business" />
       </ALLOWEDVALUES>
       <DEFAULT from="value" value="Business" />
        <HELPTEXT>Indicates whether this supports business or architectural objectives</HELPTEXT>
   </FIELD>
   

3. Добавьте поле к форме в ту же позицию, что добавили для ситуации. Например:

   <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" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   </Column>
   

4. Сохраните и затем импортируйте файл.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Feature.xml"

5. Повторите шаги с 1 по 4 для истории пользователя и определений WIT элемента невыполненной работы продукта. При необходимости измените определение WIT «Ошибка», если необходимо отслеживать, какие требования поддерживают ошибки, или для отслеживания ошибок в невыполненной работе.

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

Далее мы добавим ситуации в иерархию рабочих элементов, составляющих невыполненную работу.

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

   witadmin exportprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

2. Откройте файл и добавьте раздел PortfolioBacklog для ситуации в разделе PortfolioBacklogs. В то же время измените элемент PortfolioBacklog для FeatureCategory так, чтобы ситуации стали родительским элементом для функций.

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

   <PortfolioBacklogs>
     <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
         <States>
         <State value="New" type="Proposed" />
         <State value="Active" type="InProgress" />
         <State value="Resolved" type="InProgress" />
         <State value="Closed" type="Complete" />
         </States>
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   </PortfolioBacklog>        
   

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

           <State type="Proposed" value="New" />
           <State type="InProgress" value="In Progress" />
           <State type="Complete" value="Done" />
   

   А для CMMI проектов требуется сопоставить состояния рабочего процесса Предложено, Активно, Разрешено и Закрыто.

           <State value="Proposed" type="Proposed" />
           <State value="Active" type="InProgress" />
           <State value="Resolved" type="InProgress" />
           <State value="Closed" type="Complete" /> 
   

3. Далее, добавьте parent="Microsoft.EpicCategory" в PortfolioBacklog category="Microsoft.FeatureCategory". Кроме того, добавьте поле Тип требования в раздел Columns .

   <PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   
   </PortfolioBacklogs>
   

4. Добавьте поле Тип требования к разделу Columns в разделе RequirementsBacklog .

   <RequirementBacklog singularname="User Story" pluralName="User Stories" category="Microsoft.RequirementCategory">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50"/>
        <Column refname="Microsoft.IterationPath" width="200"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
      . . .
   </RequirementBacklog>
   

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

   Мы выбрали цвет, соответствующий оранжевому (шестнадцатеричный код = FF7B00). Префикс шестнадцатеричного кода цвета FF.

   <WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
   

6. Сохраните и затем импортируйте файл.

   witadmin importprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

Обновить путь области для существующих рабочих элементов

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

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

   

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

   

3. Сохраните все рабочие элементы, которые были изменены.

   

Дополнительные сведения о массовом изменении рабочих элементов см. здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

Также возможно массовое изменение рабочих элементов и управление их иерархией в Microsoft Excel.

Поскольку сопоставление работы целям бизнеса или архитектуры является важным аспектом SAFe, необходимо обязательно задать тип требования = архитектура для любой функции, которая сопоставляется с ситуацией архитектуры. (Так как значение по умолчанию — бизнес, не нужно изменять тип для любого элемента, который поддерживает ситуацию бизнеса.) Можно также добавить теги для отслеживания инвестиций.

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

Ресурсы

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

• Шаблоны процессов с поддержкой SAFe: Ссылка для загрузки трех шаблонов процессов, которые предоставляет TFS — Scrum , Agile и CMMI — с добавленными настройками, описанными в этом документе.

• Обновление и публикация шаблонов процессов TFS 2013 с помощью PowerShell: запись в блоге от Gordon Beeming, предоставляющая сценарий PowerShell, который может использоваться для применения изменений, описанных в этом документе.

• Scaled Agile Framework: Сайт ресурсов SAFe.

• SAFe за 7 минут: видео Инбар Орен, Lean Samurai.

• Масштабирование Agile и отчеты SAFe TFS: Загружаемый отчет хода выполнения функции, который работает с шаблоном процесса Scrum для локальных развертываний TFS 2012 и 2013.

• Управление портфелем Agile: использование TFS для поддержки невыполненной работы между несколькими командами: технический документ, в котором показано, как настроить TFS для поддержки нескольких групп и нескольких списков невыполненной работы.

• Поиск рабочих элементов с использованием запросов (необходимо обновить): : Описываются способы настройки TFS для поддержки развертывания, с суммированием значений выбранных полей для всех дочерних рабочих элементов родительского узла. Поскольку TFS поддерживает несколько уровней вложения, при выполнении развертывания нужно убедиться, что значения не посчитаны дважды.

• Встроенные отчеты(SQL Server Reporting Services): Краткое описание отчетов TFS для мониторинга прогресса и качества кода

• Синхронизация Team Foundation Server и Project Server Синхронизация Team Foundation Server с Project Server: описывает, как руководители проектов и группы разработки могут использовать средства, которые они предпочитают, и прозрачно совместно использовать информацию, направляя поток данных от рабочих элементов в Team Foundation Server к задачам планов корпоративных проектов в Project Server.

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

Об авторах

Gordon Beeming — разработчик программного обеспечения в Derivco в солнечном городе Дурбан, Южная Африка. Он проводит большую часть времени за клавиатурой в Visual Studio или на отдыхе со своим семейством. Его блог находится на 31og.com, следуйте за ним в Twitter с twitter.com/gordonbeeming.

Брайан Blackman основной консультант в Microsoft Premier Developer, занят обеспечением успеха независимых поставщиков программных продуктов и корпоративных партнеров. Он имеет звания MBA и CSM, CSP MCSD (C++) и MCTS и Visual Studio ALM Ranger. Если он не занят Ruck Mastering и участием в проектах Visual Studio ALM круг, он проводит время за написанием кода, созданием и проведением семинаров и в консультациях в различных сферах, особенно помогает организациям в переходе к гибким разработкам.

Грегг Бур — главный руководитель программ в корпорации Майкрософт. Грегг является владельцем продукта для компонента Agile Management в TFS.

Катрин Эллиотт — старший разработчик технической документации в корпорации Майкрософт.

Сьюзан Феррелл — старший разработчик технической документации и Visual Studio ALM Ranger.

Вилли-Питер Шауба — руководитель программы Visual Studio ALM Rangers в центре разработки Майкрософт Канады. С середины 80-х он стремится к простоте и удобству поддержки при разработке программного обеспечения. Его блог blogs.msdn.com/b/willy-peter_schaub и следуйте за ним в Twitter на twitter.com/wpschaub.