Использование областей и итераций в Team Foundation Server 2008

Если вы используете TFS 2005 или 2008, Как вы используете итерации и области пользователей?

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

вот интересная статья о областях и как команда TeamSystem использует их:

http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

но мне еще больше любопытны итерации, и я был бы признателен, если бы вы могли показать мне несколько конкретный пример.

вы создаете итерации на основе вех или на основе определенных функциональных возможностей?

Что происходит, когда вы заканчиваете v1, как вы управляете v2 или обновлениями до v1?

мы используем шаблон MSF Agile.

10
tfs tfs-workitem

3 ответов

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

поскольку мы используем SCRUM, итерации в TFS используются для определения наших циклов выпуска и спринтов в этих циклах выпуска.

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

после выпуска вполне нормально добавлять исправления/обновления ошибок в отставание при работе со следующей версией время.

enter image description here

8

пути итерации и области-это то, что вы хотите. Как вы можете описать свой проект в пространстве и времени. Простой пример:

Area Path (пробел) - может использоваться для описания частей вашей системы/проекта. Предположим, вы создаете TeamProject для приложения GUI, некоторые области будут описывать его модули (ввод данных, отчеты, GUI, печать и т. д...)

путь итерации (время) - описывает циклы версий или выпуска вашего проекта. На компании что я работал для используемых версий выпуска в качестве их итераций (major, minor, build, revision). Это помогает отслеживать рабочие элементы, чтобы отметить, какая итерация должна была быть завершена. У нас была статическая итерация TBD, которая была по умолчанию для всех созданных рабочих элементов. Позднее руководство решит, куда следует направить эти рабочие элементы, и назначит их или закроет.

8

Я предполагаю, что вы используете итерации как часть MSF Agile или какой-либо другой тип гибкой методологии. Если да, то в целом вы определяете, сколько работы может быть выполнено вашей командой в течение следующих n недель. В общем, мы использовали 3 недели, но длину итерации, может быть разным.

Как вы определяете элементы для итерации, как правило, на основе приоритета, который должен быть основан на влиянии рынка/бизнеса (горячность элемента) и простоте реализации. Оценка воздействия более тяжелый вес, но вы должны учитывать легкость реализации в своем счете, поскольку у вас может быть несколько предметов "bang for the buck".

правило с Agile-это функции, которые не могут быть завершены, отбрасываются. Вы никогда не продлеваете дату итерации.

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

Примечание: Если вы говорите водопад, правила могут быть основаны на вехах и функциональности, но с Agile, время-король.

теперь к областям: это более субъективно. Один из способов разделения на области-группировка вариантов использования. Мне нравится этот метод. Но, когда дело доходит до пользовательского интерфейса, вы также можете создавать области для определенных форм и т. д.

2