Team Foundation Server - Какой шаблон процесса для меня?

Ответ 1

Вы уже используете процесс разработки программного обеспечения, например scrum? Если да, вы можете попробовать этот шаблон командного процесса над здесь.

Насколько велика ваша проектная команда и проект? Корпорация Майкрософт опубликовала один из своих внутренних шаблонов процессов (MPT) поверх здесь. Вы можете получить некоторое руководство и вдохновение из этого шаблона.

Как упоминается tangurena. Люди используют стандартные шаблоны, немного меняют ошибку и сохраняют там некоторые документы. Я бы рекомендовал держать процесс "светлым".

Однако шаблон процесса не все.

Вот некоторые идеи, что я сделал бы (в вашем случае):

• Создайте некоторые рабочие элементы высокого порядка (функции/истории), которые могут создавать участники (ограничения и группы пользователей TFS - ваш друг). Затем они могут получить доступ к своим запрошенным функциям через веб-доступ к рабочему элементу TFS. Таким образом вам не нужна CAL для них.

• Создайте несколько отчетов, которые показывают запланированную работу, присоединяющуюся к выпускам.

• Установите автоматизацию сборки и создайте отчеты (примечания к выпуску a.k.a.) из ваших рабочих элементов в соответствии со строками.

Каковы были самые большие преимущества и недостатки, с которыми вы столкнулись?

Imho самым большим недостатком является то, что вы начинаете верить, что шаблон - ваша серебряная пуля. Это не так, это ваша отправная точка. TFS-экосистема предлагает вам множество возможностей для создания собственных программных продуктов, соответствующих вашим потребностям. Просто проверьте TFS API.

Ответ 2

Вот еще один хороший гибкий шаблон (оригинал находится на SSW, но вам нужно обойти стенд входа).

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

Ответ 3

В общих чертах, я бы одобрил как небольшой процесс, который вы можете управлять. Чем больше состояний, тем больше полей у вас есть, тем больше вероятность, что информация в них просто неверна.

Мы работаем с нашей собственной версией в шаблоне Agile. Большинство из того, что мы с ним сделали, это удалить материал.

Вы можете использовать TFS API для записи сборок в базу данных, что должно позволить вам объединить TeamCity и TFS. Кроме этого, я бы, скорее всего, пошел с веб-интерфейсом, который поставляется с TFS, я не думаю, что для этого вам понадобится стороннее программное обеспечение.

Ответ 4

K.I.S.S.! Я создал настраиваемый рабочий элемент, основанный на Agile. И это, всего лишь один рабочий элемент. Существует "системная серьезность", которую используют ИТ, и "Приоритет бизнеса", который использует клиент/клиент. Существует также "Тип запроса". С этими тремя вместе со встроенными Area и Iteration вся команда, включая клиентов, может запрашивать рабочие элементы, чтобы получить только те элементы, которые им нужны для выпуска, с которым они связаны (или все они независимо от выпуска).

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

Клиент использует TFS Web Access (неограниченный CAL), а разработчики (мне и еще 1) используют VS. На моей последней работе я создал ту же самую настройку, команда разработчиков была командой из 5 человек, и там она работала еще лучше! Я тоже был там руководителем и техническим PM.

Самое большое преимущество заключалось в создании очень гибкой системы для всех, при использовании одного типа рабочего элемента для всего. Недостатком была бы кривая обучения для клиента, но как только они знали, как использовать ее больше всего. Предложение было бы изучить более дешевые инструменты там для аналогичной реализации, но наша дисконтная карта .edu с MS can not be beat.

Ответ 5

Я должен сказать, что вы должны определить систему, которую вы будете использовать для своей компании SDLC. Шаблон процесса - это просто инструмент и без хорошего понимания лежащего в его основе процесса он не поможет и может усложнить ситуацию. Принятие пользователя имеет решающее значение для успеха SDLC и шаблона процесса.

Мы используем Scrum для Team System. Мы выбрали это из-за нашего опыта работы с Scrum в качестве методологии SDLC. В Интернете есть несколько отличных книг и статей, которые помогут вам ускориться. Scrum свяжет участников бизнеса в процессе.

В нашей системе диспетчер продуктов находится в общей сумме элементов товарного отставания и работает с самим собой и техническим директором, чтобы определить их приоритет в элементах отставания Sprint.

Единственное изменение, которое мы внесли в шаблон процесса, заключалось в том, чтобы добавить состояние "Failed Test" и соответствующий рабочий процесс.

Ответ 6

Это может быть не лучший шаблон для вас, но я все еще хотел упомянуть его здесь: XP для Team System. Это в основном упрощенная версия MSF для Agile Software Development:

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