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

Ответов (3)

Решение

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

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

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

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

введите описание изображения здесь

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

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

В Agile есть правило: функции, которые невозможно выполнить, отбрасываются. Вы НИКОГДА не продлеваете дату итерации.

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

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

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

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

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

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