{"id":87327,"date":"2015-06-03T08:50:27","date_gmt":"2015-06-03T07:50:27","guid":{"rendered":"https:\/\/artigianodelsoftware.wordpress.com\/?p=87327"},"modified":"2015-06-03T08:50:27","modified_gmt":"2015-06-03T07:50:27","slug":"gestiamo-un-progetto-con-i-prodotti-atlassian-2","status":"publish","type":"post","link":"https:\/\/artigianodelsoftware.it\/blog\/2015\/06\/03\/gestiamo-un-progetto-con-i-prodotti-atlassian-2\/","title":{"rendered":"Gestiamo un progetto con i prodotti Atlassian – 2"},"content":{"rendered":"
\"image_pdf\"<\/a><\/a><\/div>
\n

Andiamo in dettaglio<\/h1>\n<\/blockquote>\n

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\u00e0 pubblicato in questo post<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

\n

JIRA – configuriamolo<\/h1>\n<\/blockquote>\n

La prima cosa da fare, una volta installato il nostro JIRA, \u00e8 quello di definire un nuovo progetto. A seconda di quanto \u00e8 grande\/vasto il progetto, potrebbe essere necessario fare uso di pi\u00f9 progetti oppure ricorrere alle componenti<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

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.<\/p>\n

Viceversa, se il progetto \u00e8 abbastanza grande, lo si deve spezzettare in pi\u00f9 progetti JIRA, ognuno dedicato ad una delle parti interessate. Ad esempio, se il progetto prevede una componente\u00a0web molto articolata ed una parte database complessa, allora conviene avere due progetti, e sfruttare la possibilit\u00e0 delle linked issue<\/a> per poter legare delle issue dei due progetti, nel caso di problematiche inerenti le\u00a0due aree.<\/p>\n

Quando andiamo a definire il progetto, occorre anche capire quale tipologia necessita.<\/p>\n

\"\"<\/a><\/p>\n

 <\/p>\n

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:<\/p>\n

Simple Issue Tracking<\/strong><\/em><\/a> \u00e8 la soluzione pi\u00f9 semplice da utilizzare. Consente di poter definire un semplice progetto in JIRA per tracciare le anomalie e segnalazioni. Si utilizzano le funzionalit\u00e0 standard di JIRA, senza utilizzare altri addon o altre funzionalit\u00e0 particolari. Il workflow di gestione delle issue \u00e8 riassunto dal seguente diagramma.<\/p>\n

\"\"<\/a><\/p>\n

Project Management<\/strong><\/em> <\/a>\u00e8 la soluzione per seguire un progetto dall’inizio alla fine. Questa tipologia di progetto \u00e8 stata studiata per la gestione di un progetto.\u00a0Rispetto alla tipologia precedente, cambia il workflow, come mostrato nella figura seguente:<\/p>\n

\"\"<\/a><\/p>\n

Possiamo anche creare un nostro workflow, come mostrato in questo post<\/a>, dove possiamo inserire gli stati di cui abbiamo necessit\u00e0.<\/p>\n

Il secondo passo, una volta definito la tipologia di progetto, \u00e8 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\u00a0Segnalazione<\/strong><\/em> o con una descrizione simile che aiuti ad identificare le segnalazioni ricevute dall’Help Desk. Per fare ci\u00f2, selezionare da COG men\u00f9 (vedi figura successiva) :<\/p>\n

\"Cog\"<\/a><\/p>\n

 <\/p>\n

la sezione\u00a0ISSUE,\u00a0<\/strong><\/em> per poter accedere alla relativa sezione di amministrazione delle stesse:<\/p>\n

\"JIRA-02-01\"<\/a><\/p>\n

Quindi procediamo con l’aggiunta delle ISSUE necessarie.<\/p>\n

Definite le Issue ed il relativo Issue type scheme, ed assegnate al progetto, passiamo alla configurazione di gruppi e ruoli. Questa \u00e8 la parte pi\u00f9 delicata e viene eseguita nella sezione di amministrazione di un progetto:<\/p>\n

\"JIRA-02-02\"<\/a><\/p>\n

Facendo riferimento alla\u00a0figura, abbiamo la sezione dei\u00a0Roles<\/strong><\/em>, dove andiamo a definire i ruoli degli utenti oltre che inserire le permission degli stessi.<\/p>\n

\"JIRA-02-03\"<\/a><\/p>\n

Possiamo inserire le permission sia attraverso i gruppi che inserendo direttamente gli utenti. Quindi possiamo definire il\u00a0Default Assignee,\u00a0<\/strong><\/em>ovvero l’utente a cui viene assegnata di default la issue creata. A seconda delle necessit\u00e0 potrebbe essere utile o mantenerlo non assegnato o assegnarlo ad uno dei componenti del gruppo di lavoro.<\/p>\n

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\u00e0 di cui si abbisogna.<\/p>\n

\"JIRA-02-04\"<\/a><\/p>\n

Le altre sezioni da impostare sarebbero:<\/p>\n

Componenti<\/strong><\/em>, importanti per definire le parti principali del progetto, e che consentono di poter disporre di una classificazione pi\u00f9 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.<\/p>\n

Versioni.\u00a0<\/b><\/em>Chi sviluppa software sa quanto \u00e8 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\u00e0 sono state inserite e quali sono state estese,<\/p>\n

\"JIRA-02-05\"<\/a><\/p>\n

Per i progetti che non trattano sviluppo software, non \u00e8 necessario settare le versioni e le componenti possono essere configurate sempre come le aree coperte dal progetto.<\/p>\n

Altre configurazioni accessorie, non obbligatorie ma sempre comodo da sapere, \u00a0sono le seguenti:<\/p>\n