I progetti TFS sono suddivisi in due livelli: Project Collection e Team Project.
Project Collection
Le Project Collection raccolgono un insieme di progetti ed ogni collezione è una entità separata dalle altre: qualsiasi informazione presente in una Project Collection non ha nessuna correlazione con altre Project Collection presenti nel server.
A livello fisico, ogni collection ha un suo database separato e grazie alle operazioni di Detatch/Attach è molto semplice spostarle da un server TFS ad un altro.
Il concetto di Project Collection è stato introdotto con TFS 2010, principalmente per semplificare la gestione e la manutenzione. Ad esempio quando un server inizia a contenere molti progetti, alcuni dei quali sono molto vecchi e poco usati, potrebbe essere necessario spostarli in un altro server, per alleggerire il principale. In questo scenario è sufficiente effettuare un detach della collection dal server di origine, spostare il database sul nuovo server, effettuare il reattach e cancellare i vecchi progetti dal server di origine.
Team Project
Ogni collection contiene poi uno o più Team Project, termine che identifica un "progetto" nel senso più ampio del termine, da non confondersi con il concetto di progetto che si ha in Visual Studio.
Non esiste una regola da seguire per frazionare il lavoro in Project Collection e Team Project: ogni gruppo di lavoro ha le sue metodologie. Un esempio potrebbe essere: un team project per alcune librerie base che vengono mantenute da un team, ed un team project per ogni applicazione Web che viene gestita da altri team. Se la ditta fornisce consulenza potrebbe implementare una Project Collection per ogni cliente in modo da mantenere un isolamento tra i dati. Anche se non esiste un modo univoco di gestire l'organizzazione, possiamo cercare in rete alcune suddivisioni tipiche.
All'interno di un Team Project è comunque possibile frazionare ulteriormente grazie al concetto di Aree, in questo modo si potrebbe anche usare un solo Team Project con un area per ogni libreria di base ed un'area per ogni portale. Come si può vedere le possibilità offerte sono molte ed il consiglio è quello di iniziare scegliendone una, per raffinare poi la gestione progetto dopo progetto.
Work Item
La pianificazione di un software inizia con la raccolta dei requisiti, mediante i quali si identifica cosa si vuole realizzare; una volta che si possiede un set base di requisiti si passa alla stesura delle specifiche tecniche ed il software viene decomposto in una serie di task che vengono poi assegnati ai vari sviluppatori. Qualsiasi sia il ciclo di vita scelto, l'analisi e la raccolta requisiti sono sicuramente i momenti più importanti del progetto e debbono essere gestiti con attenzione.
Durante lo sviluppo emergono poi Bug e Rischi, si ha la necessità di creare Test Case e magari User Stories se si adottano procedure agili; una attenta gestione del ciclo di vita deve quindi appoggiarsi ad uno strumento che permetta di centralizzare la gestione di tutti questi concetti in maniera efficace.
In TFS tutti questi concetti sono identificati da un'entità chiamata "Work Item" ed infatti la prima macroarea di TFS va sotto il nome di Work Item Tracking. Un Work Item non è altro che una serie di informazioni che reacchiudono il concetto di: requisito, bug, task, risk, usecase, etc., gestite interamente da TFS in maniera centralizzata.
Naturalmente esistono molte tipologie di Work Item differenti in relazione al ciclo di vita utilizzato; alcuni team non usano il concetto di risk, per altri potrebbe essere necessario avere una nuova tipologia di WI non presente nei template base ed in generale non è possibile imporre al team un "processo" da seguire durante la realizzazione del prodotto. Per questa ragione TFS permette ad ogni team di scegliere il processo che più si adatta alle proprie esigenze introducendo il concetto di Team Project, che racchiude una serie di configurazioni, tra cui le tipologie di Work Item, per guidare il team nell'implementazione di uno specifico ciclo di vita.
Di base TFS viene fornito con due processi più uno: uno di tipo CMMI ed uno agile basato su SCRUM a cui si aggiunge un nuovo Scrum 1.0 scaricabile separatamente. Una funzionalità fondamentale è infatti la possibilità di scaricare definizioni aggiuntive di processi (ad esempio questi) o prendere un processo esistente personalizzandolo per soddisfare le proprie esigenze. Questa flessibilità costituisce un grande vantaggio: è TFS ad adattarsi alle procedure del team invece di forzare il team ad adattarsi alle proprie. Prima di esaminare però la gestione dei Work Item è necessario spendere qualche parola sul come connettersi e come dialogare con TFS.
