Andiamo in dettaglio
In questo post, andremo ad esaminare nel dettaglio la parte di JIRA, in cui inizieremo a vedere come configurare la gestione di un progetto, continuando quanto già pubblicato in questo post.
JIRA – configuriamolo
La prima cosa da fare, una volta installato il nostro JIRA, è quello di definire un nuovo progetto. A seconda di quanto è grande/vasto il progetto, potrebbe essere necessario fare uso di più progetti oppure ricorrere alle componenti.
Queste ultime consentono di poter definire una sorta di sottoprogetti, mantenendo tutta la storia all’interno di un unico progetto. Andremo ad esaminare in seguito queste componenti.
Viceversa, se il progetto è abbastanza grande, lo si deve spezzettare in più progetti JIRA, ognuno dedicato ad una delle parti interessate. Ad esempio, se il progetto prevede una componente web molto articolata ed una parte database complessa, allora conviene avere due progetti, e sfruttare la possibilità delle linked issue per poter legare delle issue dei due progetti, nel caso di problematiche inerenti le due aree.
Quando andiamo a definire il progetto, occorre anche capire quale tipologia necessita.
JIRA mette a disposizione diverse tipologie di progetto. Andiamo ad analizzarle per capire meglio quale tipologia utilizzare e che accorgimenti usare. Sullo standard, ovvero sulla installazione di JIRA senza addon particolari (quali JIRA AGILE o simili), abbiamo a disposizione:
Simple Issue Tracking è la soluzione più semplice da utilizzare. Consente di poter definire un semplice progetto in JIRA per tracciare le anomalie e segnalazioni. Si utilizzano le funzionalità standard di JIRA, senza utilizzare altri addon o altre funzionalità particolari. Il workflow di gestione delle issue è riassunto dal seguente diagramma.
Project Management è la soluzione per seguire un progetto dall’inizio alla fine. Questa tipologia di progetto è stata studiata per la gestione di un progetto. Rispetto alla tipologia precedente, cambia il workflow, come mostrato nella figura seguente:
Possiamo anche creare un nostro workflow, come mostrato in questo post, dove possiamo inserire gli stati di cui abbiamo necessità.
Il secondo passo, una volta definito la tipologia di progetto, è quello di definire la tipologia delle ISSUE, in modo da inserire anche tipologie che, nello standard, non sono presenti. Faccio un esempio. Se dobbiamo gestire un semplice Help Desk, senza far uso di JIRA Service Desk, potrebbe essere utile inserire l’Issue Type Segnalazione o con una descrizione simile che aiuti ad identificare le segnalazioni ricevute dall’Help Desk. Per fare ciò, selezionare da COG menù (vedi figura successiva) :
la sezione ISSUE, per poter accedere alla relativa sezione di amministrazione delle stesse:
Quindi procediamo con l’aggiunta delle ISSUE necessarie.
Definite le Issue ed il relativo Issue type scheme, ed assegnate al progetto, passiamo alla configurazione di gruppi e ruoli. Questa è la parte più delicata e viene eseguita nella sezione di amministrazione di un progetto:
Facendo riferimento alla figura, abbiamo la sezione dei Roles, dove andiamo a definire i ruoli degli utenti oltre che inserire le permission degli stessi.
Possiamo inserire le permission sia attraverso i gruppi che inserendo direttamente gli utenti. Quindi possiamo definire il Default Assignee, ovvero l’utente a cui viene assegnata di default la issue creata. A seconda delle necessità potrebbe essere utile o mantenerlo non assegnato o assegnarlo ad uno dei componenti del gruppo di lavoro.
Successivamente occorre definire le permission, andando a configurare lo scheme permission che si intende utilizzare. Normalmente, quello standard consente di poter coprire tutte le necessità di cui si abbisogna.
Le altre sezioni da impostare sarebbero:
Componenti, importanti per definire le parti principali del progetto, e che consentono di poter disporre di una classificazione più mirata delle ISSUE. Ad esempio, possiamo classificare le ISSUE dedicate al database, dalle ISSUE dedicate alla Web Server, dalle ISSUE del programma, etc etc etc.
Versioni. Chi sviluppa software sa quanto è importante classificare i rilasci in base alla versione, in modo da identificare in maniera semplice quali bug-fix sono presenti sulla versione, quali nuove funzionalità sono state inserite e quali sono state estese,
Per i progetti che non trattano sviluppo software, non è necessario settare le versioni e le componenti possono essere configurate sempre come le aree coperte dal progetto.
Altre configurazioni accessorie, non obbligatorie ma sempre comodo da sapere, sono le seguenti:
- La scelta di una icona del progetto. Non necessaria, ma quando si devono gestire più progetti, suggerisco di impostarla. Consente di poter riconoscere meglio il progetto rispetto agli altri.
- Possibilità di generare ISSUE via email, qualora si voglia sfruttare una email preesistente, per sfruttare una delle capacità di JIRA di poter generare ISSUE attraverso email.
- Nuovi campi custom. Sempre utili, qualora si voglia tracciare informazioni che non sono coperte dai campi preesistenti di JIRA.
Conclusioni
In questo post abbiamo visto come configurare JIRA per gestire un progetto. Nel prossimo post andremo ad estendere e completare la configurazione.
(1)Dislikes
(0)