Valor del sistema de equipo de Microsoft dentro de solo un equipo de desarrollo

Question

Microsoft Team System parece ser una gran plataforma para la implementación de sistemas orientados a procesos, sin embargo, si se le quita el acceso a los BA, los PM y los usuarios de negocios y simplemente lo utiliza dentro de un equipo de desarrollo, ¿tiene más valor que solo ¿Está utilizando Visual Studio Professional, SourceSafe, una herramienta de seguimiento de defectos y un servidor de integración continua como CruiseControl o TeamCity?

Answer 1

Sí. Cada tecnología de reemplazo que ha mencionado es algo que es compatible con el paquete Team System (ya sea en esta versión o en la siguiente). Todos estos componentes están diseñados para integrarse y trabajar entre sí en TFS. Esta es una alta prioridad del equipo TFS para todos los componentes. El resultado es un conjunto de características que en la mayoría de los casos se integran perfectamente entre sí.

No estoy familiarizado con varios de los otros proyectos que mencionaste, pero es poco probable que se integren tan bien entre sí como con los componentes de TFS correspondientes. Esto no quiere decir que no tengan integración o tengan un desempeño deficiente como productos. Solo que no están diseñados para trabajar juntos. Por lo tanto, la interacción no será tan nítida como los componentes de TFS.

¿Es esto lo suficientemente valioso como para continuar usando TFS? No lo sé porque dependería en gran medida de cuánto valore esta integración.

Answer 2

Uno de los grandes puntos de venta de TFS para mi equipo es la coherencia que proporciona a nuestro ciclo de vida general del producto. Permitimos que los BA, los PM y los usuarios comerciales tengan ciertos niveles de acceso a TFS, pero incluso si no lo tuviéramos, el producto aún sería de gran valor para su uso. La capacidad para administrar nuestros flujos de trabajo dentro de TFS y hacer cumplir la coherencia en todo el equipo de desarrollo es excelente.

Algunas de las características que TFS proporciona son: seguridad, informes, administración de flujo de trabajo, compilaciones integradas, alertas de correo electrónico, ramificación / fusión.

¿Podrías lograrlo con un montón de otras herramientas? Probablemente, pero no sería tan fácil de administrar y mantener, y probablemente no sería capaz de extraer el tipo de datos necesarios para informar y rastrear la forma en que puede con TFS.

En una nota al margen, si contara con Visual SourceSafe como su repositorio, le sugeriría buscar en otra parte. Por experiencia personal y de negocios, puedo dar fe de que no se puede contar como un repositorio estable / sólido.

Mis pensamientos.

Answer 3

Claro que tiene valor. Hay un montón de funciones de cliente solo en las SKU del equipo (no dejes que el nombre te engañe, son principalmente las nuevas versiones súper premium de cocina y fregadero, que también tienen la ventaja de incluir una CAL de servidor para TFS.) Las especificaciones exactas están disponibles aquí: http: // www .microsoft.com / visualstudio / en-us / products / teamsystem / default.mspx

Mirando específicamente a las funciones de colaboración, de nuevo, hay un valor claro en un sistema cuyos componentes fueron diseñados para que " simplemente funcionen " juntos. La configuración está simplificada (aunque tiene un camino por recorrer); las interfaces de usuario son coherentes y accesibles entre sí; el backend alimenta un servicio de análisis / reporte unificado. Si tiene un equipo grande, el rendimiento / escalabilidad general también supera en gran medida a lo que puede ofrecer la suite OSS típica en este momento.

La pregunta es si vale la pena para usted. ¿Por qué usar Visual Studio Professional en lugar de SharpDevelop? ¿Por qué SourceSafe en lugar de Git? ¿Por qué no Bloc de notas y carpetas especialmente etiquetadas?

Todos los productos comerciales son comerciales por una razón (bueno, ¡quizás no SourceSafe!). Si desea algo con un amplio conjunto de características, integración estrecha, soporte bien definido y amp; Ciclo de vida de prueba, buen ajuste y amp; finalice, etc., entonces generalmente vale la pena gastar el $$ y dejar que su personal de desarrollo continúe con su trabajo. Si no te importa hacer la configuración & amp; resolviéndose problemas, cambiando entre varias aplicaciones como parte del flujo de trabajo de desarrollo, perdiendo la capacidad de consultar & amp; informe sobre las estadísticas del equipo en su conjunto, etc. y, por supuesto, use el código abierto - muchas herramientas de desarrollo OSS son muy sólidas en la actualidad.