Использование областей и итераций в 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.

Ответ 1

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

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

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

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

Ответ 2

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

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

Итерационный путь (время) - описывает цикл версий или выпуска вашего проекта. В компании я работал для использованных версий релизов в качестве их итераций (майор, минор, сборка, пересмотр). Он помогает отслеживать рабочие элементы, чтобы отметить, что итерация должна была быть завершена. У нас была статическая итерация TBD, которая была по умолчанию для всех созданных рабочих элементов. Руководство позднее примет решение о том, где следует настраивать эти рабочие элементы и назначать их или закрывать.

Ответ 3

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

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

Правило с Agile - это функции, которые не могут быть завершены. Вы НИКОГДА не расширяете дату итерации.

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

ПРИМЕЧАНИЕ. Если вы говорите о водопаде, правила могут основываться на вехах и функциях, но с Agile время короля.

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