Riferimento rapido

La presente guida di riferimento illustra i concetti, i termini e gli elementi visivi principali per consentire di acquisire immediatamente dimestichezza con il prodotto.

Questo argomento include le seguenti sezioni:

Terminologia e concetti

Rational Team Concert le risorse utente sono archiviate in un repository, al quale possono accedere solo utenti autorizzati.

Il repository contiene aree progetti che fanno riferimento alle risorse utente per un progetto. Ogni area progetto ha un processo associato, che regola l'esecuzione del progetto e personalizza il comportamento di Jazz . Il processo è definito da una configurazione e da una descrizione. La configurazione del processo definisce le iterazioni del progetto e il relativo comportamento durante tali iterazioni. La descrizione del processo corrisponde a un sito Web in cui viene illustrato il processo.

Questo diagramma mostra la relazione di alto livello tra le aree progetti, le aree team, gli spazi di lavoro del repository e altre risorse utente.

Esistono diversi processi predefiniti da scegliere provenienti da: Scrum, OpenUp e Simple. È anche possibile definire dei processi personali o modificare un processo esistente. Per ulteriori informazioni, consultare Modelli di processo.

Da un'area progetto, è possibile accedere alle risorse utente del progetto.

Le aree progetti sono suddivise in un insieme di aree team, che descrivono i team al lavoro sul progetto. Ogni area team dispone di un elenco di membri e dei relativi ruoli del processo all'interno del team. Un utente può essere membro di più team. Ogni area team può definire personalizzazioni del processo per adattare il processo alle esigenze del team e dei relativi team secondari.

Nei progetti più semplici, tutte le attività si trovano su un'unica sequenza temporale principale con un solo flusso. È comunque possibile creare sequenze temporali, ad esempio per attività di manutenzione. Ogni sequenza temporale dispone delle proprie aree team e personalizzazioni del processo.

Il lavoro pianificato viene descritto dagli elementi di lavoro. I tipi di elementi di lavoro utilizzati in un'area progetto vengono definiti dal processo. Ad esempio, il processo Scrum definisce i seguenti tipi di elemento di lavoro:

  • Difetto
  • Attività
  • Story
  • Epico
  • Traccia elemento di build
  • Impedimento
  • Elemento di adozione
  • Retrospettiva

Ogni tipo di elemento di lavoro può disporre di proprie transizioni di stato e campi personalizzati. Gli elementi di lavoro vengono archiviati per categorie elementi di lavoro, consentendone l'organizzazione per aree funzionali. Ogni area progetti definisce l'elenco delle categorie elementi di lavoro disponibili. Ogni area team è associata alla categoria elementi di lavoro dell'area funzionale della quale è responsabile il team.

È possibile trovare gli elementi di lavoro eseguendo delle query. Le query possono essere private (dell'utente) o condivise con il team.

Il lavoro in un'area progetti viene svolto in una sequenza di iterazioni. Ogni iterazione può avere una data di inizio e di fine. Una delle iterazioni viene definita come iterazione corrente dal processo. Durante la pianificazione del lavoro, un elemento di lavoro viene destinato a una particolare iterazione. È possibile pianificare tutto il lavoro che deve fare parte di un'iterazione creando un piano di iterazione. È possibile pianificare tutto il lavoro per una release che è suddivisa in iterazioni in un piano di release.

Per lavorare sui file del progetto nel controllo origine si utilizza uno spazio di lavoro del repository . Lo spazio di lavoro del repository viene caricato per copiare i file e le cartelle sul computer in uso. Il Jazz Team Server tiene traccia di tutte le modifiche apportate ai file controllati dall'origine tramite serie di modifiche. Ogni serie di modifiche contiene i file e le cartelle modificati, con il relativo commento e fa riferimento agli elementi di lavoro associati che hanno motivato le modifiche. Verificare le relative impostazioni di modifica per caricare i file e le cartelle modificati dallo spazio di lavoro IDE allo spazio di lavoro del repository. Le impostazioni di modifica sottoposte a check-in sono archiviate bel repository ma non sono ancora condivise con il resto del team di sviluppo finché non vengono trasferite le impostazioni di modifica. Il processo di check-in e di trasferimento fornisce una protezione supplementare alle relative modifiche, dando la flessibilità per effettuare continuamente modifiche senza trasferirle immediatamente.

I team utilizzano un flusso per archiviare la copia principale dei file del progetto; ogni spazio di lavoro del repository contiene una copia. Uno spazio di lavoro del repository e il flusso del team sono collegati. Le serie di modifiche del proprio spazio di lavoro del repository vengono consegnate al flusso per essere incorporate nella copia principale; si tratta delle serie di modifiche in uscita. Le serie di modifiche in entrata invece sono quelle trasferite al flusso da altri membri del team. Le serie di modifiche in entrata vengono accettate per incorporare le relative modifiche nel proprio spazio di lavoro del repository e nel proprio spazio di lavoro IDE.

La base del file controllato dall'origine è composta dall'accrescimento costante delle serie di modifiche, ognuna delle quali si basa sulla rispettiva versione precedente. La cronologia delle modifiche è la sequenza di serie di modifiche per uno spazio di lavoro del repository o per un flusso.

La base del file controllato dall'origine può essere partizionata in uno o più componenti separati, ognuno con la propria struttura ad albero di cartelle e file e la propria cronologia delle modifiche. Gli spazi di lavoro del repository e i flussi semplici sono composti da un solo componente. Più componenti sono utili per i team che sviluppano software suddiviso in livelli, in cui le varie parti si evolvono in maniera semi indipendente e sono distribuite separatamente.

invece consente di acquisire baseline simultanee tra tutti i componenti. La creazione di una baseline di un singolo componente in uno spazio di lavoro del repository consente di acquisire un momento preciso di interesse. La creazione di un' istantanea

Ogni team può avere la propria build, descritta in una definizione build associata all'area team. La definizione build definisce l'intervallo della build, lo script di build da utilizzare e lo spazio di lavoro del repository da utilizzare per recuperare i file. Una build può essere eseguita su diversi motori di build. Una build può essere promossa a release. Gli utenti possono quindi archiviare gli elementi di lavoro per una particolare release.

È possibile utilizzare i feed per sapere su cosa stanno lavorando gli altri colleghi oppure per avere notizie sugli altri team. Quando vengono modificate delle risorse utente nel repository, vengono inviati automaticamente degli avvisi di evento ai feed.

Client

È possibile lavorare in una qualsiasi delle seguenti interfacce utente del client:


Feedback

Queste informazioni sono state utili? È possibile fornire un feedback su Jazz.net (è richiesta la registrazione): commenta nei forum o segnala un bug