Valore di Microsoft Team System all'interno di un solo Dev Team

Question

Microsoft Team System sembra essere un'ottima piattaforma per l'implementazione di sistemi orientati ai processi, tuttavia se si elimina l'accesso per gli utenti BA, PM e Business e se lo si utilizza semplicemente all'interno di un team Dev, ha più valore di un semplice utilizzando Visual Studio Professional, SourceSafe, uno strumento di rilevamento dei difetti e un server di integrazione continua come CruiseControl o TeamCity?

Answer 1

Sì. Ogni tecnologia sostitutiva che hai citato è qualcosa che è supportato dal pacchetto Team System (in questa versione o in quella successiva). Tutti questi componenti sono progettati per integrarsi e funzionare l'uno con l'altro in TFS. Questa è un'alta priorità del team TFS per tutti i componenti. Il risultato è un insieme di funzionalità che nella maggior parte dei casi si integrano perfettamente tra loro.

Non ho familiarità con molti degli altri progetti che hai citato, ma è improbabile che si integrino l'uno con l'altro dei corrispondenti componenti TFS. Questo non vuol dire che non hanno integrazione o funzionano male come prodotti. Solo che non sono progettati per funzionare l'uno con l'altro. Quindi l'interazione non sarà nitida come i componenti TFS.

È abbastanza prezioso per continuare a utilizzare TFS? Non so perché sarebbe fortemente dipendente da quanto apprezzi questa integrazione.

Answer 2

Uno dei maggiori punti di forza di TFS per il mio team è la coerenza che fornisce al nostro ciclo di vita complessivo del prodotto. Consentiamo a BA, PM e utenti aziendali di avere determinati livelli di accesso a TFS, ma anche se non lo facessimo, il prodotto sarebbe comunque di grande valore da utilizzare. La capacità di gestire i nostri flussi di lavoro all'interno di TFS e applicare coerenza in tutto il team di sviluppo è eccezionale.

Alcune delle funzionalità che TFS ci offre: sicurezza, reportistica, gestione del flusso di lavoro, build integrate, avvisi e-mail, diramazione / unione.

Potresti farlo con un mucchio di altri strumenti? Probabilmente, ma non sarebbe così facile da gestire e mantenere e probabilmente non saresti in grado di estrarre il tipo di dati necessari per riportare e tracciare come puoi con TFS.

A proposito, se stai contando su Visual SourceSafe come repository ti consiglio vivamente di cercare altrove. Per esperienza personale e aziendale, posso attestare che non può essere considerato come un archivio stabile / robusto.

I miei pensieri.

Answer 3

Sicuro che ha valore. Ci sono un sacco di funzionalità client solo negli SKU del team (non lasciatevi ingannare dal nome - sono principalmente solo le nuove versioni "super premium" del lavello della cucina, che hanno anche il bel vantaggio di includere una CAL server per TFS.) Specifiche esatte disponibili qui: http: // www .microsoft.com / VisualStudio / it-IT / prodotti / TeamSystem / default.mspx

Osservando specificamente le funzionalità di collaborazione, c'è ancora un chiaro valore in un sistema i cui componenti sono stati progettati per "solo funzionare". insieme. L'installazione è semplificata (anche se ha una strada da percorrere); le interfacce utente sono coerenti e accessibili l'una dall'altra; il backend alimenta un servizio di reporting / analisi unificato. Se hai un team numeroso, la perf / scalabilità complessiva supera di gran lunga ciò di cui la tipica suite OSS è in grado al momento.

La domanda è se valga la pena $$. Perché usare Visual Studio Professional invece di SharpDevelop? Perché SourceSafe invece di Git? Perché non Blocco note e cartelle con etichette speciali?

Tutti i prodotti commerciali sono commerciali per un motivo (ok, forse non SourceSafe!). Se vuoi qualcosa con un ampio set di funzionalità, stretta integrazione, supporto ben definito e amp; test del ciclo di vita, buona vestibilità e amp; finire, ecc. quindi di solito vale la pena spendere i $$ e lasciare che il personale di sviluppo continui con il proprio lavoro. Se non ti dispiace fare setup & amp; risoluzione dei problemi, passaggio tra più applicazioni come parte del flusso di lavoro di sviluppo, perdita della capacità di interrogare & amp; riferire sulle statistiche del team nel suo insieme, ecc., quindi, andare sempre open source - molti strumenti di sviluppo OSS sono molto solidi al giorno d'oggi.