Системная ценность Microsoft Team только для команды разработчиков

Question

Microsoft Team System, по-видимому, отличная платформа для внедрения систем, ориентированных на процессы, однако, если вы отключите доступ для базовых, PM и бизнес-пользователей и будете использовать его только в команде разработчиков, будет ли от этого больше пользы, чем от простого использования Visual Studio Professional, SourceSafe, инструмента отслеживания дефектов и сервера непрерывной интеграции, такого как CruiseControl или TeamCity?

Answer 1

ДА.Каждая технология замены, о которой вы упомянули, поддерживается пакетом Team System (либо в этой версии, либо в следующей).Все эти компоненты предназначены для интеграции и работы друг с другом в TFS.Это высокий приоритет команды TFS для всех компонентов.В результате получается набор функций, которые в большинстве случаев легко интегрируются друг с другом.

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

Достаточно ли это ценно, чтобы продолжать использовать TFS?Не знаю, потому что это сильно зависело бы от того, насколько вы цените эту интеграцию.

Answer 2

Одним из важных моментов продажи TFS для моей команды является согласованность, которую он обеспечивает нашему жизненному циклу продукта. Мы разрешаем BA, PM и бизнес-пользователям иметь определенные уровни доступа к TFS, но даже если мы этого не сделаем, продукт все равно будет иметь большую ценность для использования. Возможность управлять нашими рабочими процессами в TFS и обеспечивать согласованность действий всей команды разработчиков.

Некоторые функции, которые обеспечивает TFS, которые мы используем: безопасность, отчетность, управление рабочим процессом, интегрированные сборки, оповещения по электронной почте, ветвление / слияние.

Не могли бы вы справиться с мешаниной других инструментов? Возможно, но управлять им и обслуживать их будет не так просто, и вы, вероятно, не сможете получить данные, необходимые для составления отчетов и отслеживания, с помощью TFS.

Если вы считаете, что Visual SourceSafe является вашим хранилищем, я настоятельно рекомендую поискать в другом месте. Исходя из личного и делового опыта, я могу засвидетельствовать, что на него нельзя рассчитывать как на стабильное / надежное хранилище.

Мои мысли.

Answer 3

Конечно, это имеет значение. Только в составе командных SKU есть множество клиентских функций (не позволяйте названию обмануть вас - это в основном только новые версии «super premium» для кухонных раковин, которые также имеют приятный бонус - включение серверной клиентской лицензии). для TFS.) Точные спецификации доступны здесь: http: // www .microsoft.com / VisualStudio / EN-US / продукты / teamsystem / default.mspx

Если обратить особое внимание на функции совместной работы, опять-таки, в системе, компоненты которой были спроектированы так, чтобы «просто работать», была очевидная ценность. друг с другом. Настройка упрощена (хотя есть пути); пользовательские интерфейсы последовательны и доступны друг другу; бэкэнд обеспечивает единую службу отчетов / анализа. Если у вас большая команда, общая производительность / масштабируемость также намного превосходит возможности типичного пакета OSS на данный момент.

Вопрос в том, стоит ли он вам $$. Зачем использовать Visual Studio Professional вместо SharpDevelop? Почему SourceSafe вместо Git? Почему не Блокнот и специально помеченные папки?

Все коммерческие продукты являются коммерческими по какой-то причине (хорошо, может быть, не SourceSafe!). Если вам нужно что-то с широким набором функций, тесной интеграцией, четко определенной поддержкой & amp; жизненный цикл тестирования, хорошая подгонка и закончить и т. д. тогда обычно стоит потратить $$ и позволить вашему персоналу-разработчику продолжить свою работу. Если вы не возражаете против установки & amp; устранение неполадок самостоятельно, переключение между несколькими приложениями в рамках рабочего процесса разработки, утрата возможности запрашивать & amp; отчет о статистике команды в целом и т. д., затем непременно перейдите с открытым исходным кодом - многие инструменты разработки OSS в настоящее время очень надежны.