Как Microsoft DevDiv использует TFS - часть 3
В предыдущих постах я рассказывал о наших процессах. Сегодня я собираюсь познакомить вас с реализацией этих процессов в TFS.
На картинке ниже дано примерное представление того, как они выглядят. Прочтите эту статью, чтобы получить большее представление о процессах.
Мы используем рабочие элементы (work items) для отслеживания информации, представленной ниже.
Рабочий Элемент Value Proposition (Ценность)
Обратите внимание на следующее:
- Сценарии (Scenarios) реализуются путем добавления специального поля сценариев в рабочем элементе типа Value Prop (Ценность) и установкой значения ALLOWEDVALUES списку сценариев. Поскольку количество сценариев (также известных, как бизнес цели) ограниченно довольно небольшим и при том фиксированным числом, такой подход представляется целесообразным.
- Отношения между Ценностью и Опытом (Experience) контролируются при помощи ссылок друг на друга этих типов рабочих элементов.
- Тип рабочего элемента Value Prop должен содержать несколько полей и, прежде всего — поле Описание (Description), поясняющее для чего собственно данная ценность была описана.
Рабочий элемент Experience (Опыт)
Обратите внимание на следующие моменты:
- Рабочий элемент Experience связан с родительским элементом Value Prop.
- Рабочий элемент Experience ссылается на дочерние элементы типа Функционал (Features).
Рабочий элемент Feature (Функционал)
На что обратить внимание:
- Тип Feature ссылается на родительский тип Experience.
- Тип Features должен содержать множество полей, описывающих его. Поле Description задает краткое содержание данного элемента для облегчения поиска.
- Для более подробного описания пользователь может перейти на одно-страничную спецификацию данного функционала. Данный документ представлен в виде внешней ссылки в специальном поле.
Что дальше...
Далее мы поговорим о том, как процессы планирования работали в Orcas.
Дополнение
Я получил вопрос от Michiel по поводу этой статьи. Вопрос был следующий: как задается соотношение между рабочими элементами? Например, Scenario к Value Prop, Value Prop к Experience, Experience к Feature?
Для случая Scenario к Value Prop мы использовали список ALLOWEDVALUES. Мы добавили поле Scenario к рабочему элементу Value Prop и задали ALLOWEDVALUES в качестве типа этого поля. ALLOWEDVALUES привязан к типу GLOBALLIST, который является списком сценариев.
Для всех других типов соотношений мы использовали ссылки одного рабочего элемента на другой. Таким образом, мы создавали ссылки между рабочими элементами Value Prop и Experience. Такие соотношения просто показывают ссылки в специальном разделе формы рабочего элемента. Вы, возможно, заметили, что шаблоны рабочих элементов MSF по умолчанию содержат закладку Links, однако те рабочие элементы, что мы обсуждали выше, содержат список ссылок на той же закладке, что и описание. Такой подход — всего лишь вопрос дизайна. Вы можете отображать списки ссылок там, где вам будет удобнее.
Может возникнуть логичный вопрос: «Как вы предотвращаете создание ссылок из Value Prop на Feature напрямую? Как вы поддерживаете правильную иерархию?».
Ответ таков: через отчеты об исключениях (exception reporting). Несколько человек просматривают отчеты, которые отображают неправильную ссылочность и удаляют такие ссылки. Возможно не самое лучшее решение, однако именно так мы и поступали.
Грегг Боер. Оригинал статьи.
Technorati Tags: TFS