TFS 2015: Как использовать CMMI (Portfolio-) Типы элементов ведения журнала backlog

Question

Мы используем TFS 2015 вместе с шаблоном процесса CMMI для отслеживания рабочих элементов наших проектов клиентов (где мы не только поставляем программное обеспечение).

Должен сказать, что я не совсем уверен, как правильно использовать различные типы элементов управления (Портфолио) для работы с Backlog, и до сих пор у меня есть два основных вопроса.

1. Есть ли общее правило, когда следует использовать Требования, характеристики или Эпики?

Я видел here, что есть родитель/ребенок releationship между ними, но это не совсем понятно, для меня, когда мне нужно добавить еще один уровень абстракции выше требований (-> Особенности) или функции (-> Былины).

Первоначально я думал об использовании требований ниже Требования в отставании. В первую очередь могут возникнуть требования клиентов, которые приводят к требованиям к продукту, что может в конечном итоге привести к требованиям к программному обеспечению. Основная идея в архивировании VSO, по-видимому, состоит в том, чтобы иметь только «Задачи» ниже «Требования» и никаких дополнительных требований (по крайней мере, веб-интерфейс VSO, похоже, не поддерживает добавление требований ниже Требования по умолчанию).

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

Любое объяснение было бы весьма полезным.

Answer 1

Существует нет общих правил относительно этих портфелей для CMMI. Но вы можете использовать информацию об Agile Process в качестве ссылки. См. Эту ссылку: https://softwareengineering.stackexchange.com/questions/182158/relationship-between-user-story-feature-and-epic

И как вы видите в инструкции по шаблону процесса CMMI. Это все отношения между родителями и детьми. Таким образом, в вашем случае вы можете рассматривать требования клиентов как «Эпические», которые могут разбиться на несколько «Особенностей» (Требования к продукту), а «Особенности» могут разбиться на несколько «Требования» (Требования к программному обеспечению)

Если вы хотите добавить требование как требование родителя/ребенка, например, добавить требование B к требованию A в качестве требования к ребенку, вы можете:

1. Открытое требование A из веб-интерфейса.
2. Нажмите кнопку «Ссылки».
3. Нажмите кнопку «Ссылка на ...».
4. Выберите тип связи «Ребенок» и введите идентификатор требования B.
5. Нажмите кнопку «ОК» и сохраните изменения.

Answer 2

Как упоминалось Эдди, нет никаких строгих правил, когда следует использовать какой тип. У Scaled Agile Framework есть большое руководство, которое вы можете использовать.

Для моей функциональной команды в Microsoft мы используем Epics для захвата всей стратегической работы (6-9 месяцев). Специализированные команды отслеживают свою работу над отставанием функции. Это разъединяемые единицы.И только те элементы, которые мы планируем работать в течение следующих 3 месяцев, появятся в журнале «Требования». Но это именно то, что работает для моей команды.