Gestiamo un progetto

Vedremo in questo post, come possiamo utilizzare gli strumenti Atlassian per gestire un progetto, non necessariamente IT, e come impostare le varie informazioni di corredo.

Di cosa abbiamo bisogno

Le componenti principali sono:

• Confluence
• JIRA

Ulteriori addon potranno essere utilizzati per raffinare il risultato e migliorare la produttività.

Confluence sarà utilizzato prevalentemente per creare la documentazione del progetto, dove andremo ad indicare tutti i requisiti, documenti del progetto, annotazioni, verbali di riunioni, grafici. In una sola parola TUTTO  :-D. L’uso della macro Roadmap è sicuramente utile per aiutare lo sviluppo e pianificarlo al meglio.

Altre caratteristiche, quali i Template per generare le pagine per i verbali delle riunioni, requisiti, informazioni etc, sono altrettanto utili e valide per impostare tutte le informazioni di corredo al progetto.

Confluence ci mette a disposizione una serie di template pronti all’uso. Quelli relativi alla registrazione dei verbali di riunione sono uno di questi.

JIRA sarà invece utilizzato per la gestione vera e propria dello stesso. In particolare, possiamo andare a gestire il progetto oppure, nella eventualità che il progetto sia abbastanza vasto, abbiamo la possibilità di poter gestire più progetti o di scomporre un progetto in componenti, di più facile gestione.

Qui possiamo scegliere la tipologia di progetto di cui abbiamo bisogno, quali caratteristiche deve possedere, come deve essere organizzato.

Abbiamo la massima libertà di scelta ed organizzazione. Qualora disponiamo anche degli addon AGILE, possiamo anche creare le varianti AGILE SCRUM e KANBAN.

Possiamo creare i vari task, che compongono il progetto, ed assegnarli alle persone dedicate alla realizzazione

definendo anche la tipologia delle issue in base a quanto serve ai nostri obbiettivi.

 Conclusioni

Concludiamo questa prima parte qui. Nei prossimi post andremo più nel dettaglio e vedremo come configurare il tutto.

Asset manager in azienda

In questo post iniziamo a vedere come possiamo utilizzare i prodotti della Atlassian per la gestione di un ASSET Manager. Riprendiamo quanto già esposto in questo post e lo estendiamo alla luce di quanto ha riportato la Atlassian nel proprio blog. Da ciò, mi sono ispirato per cercare di trovare una versione …. lite, in modo da poterlo usare anche in realtà un pò più piccole o non tanto grandi :-). Si tratta del primo di una serie di post dedicati all’argomento.

Di cosa abbiamo bisogno

Riassumiamo brevemente quanto abbiamo bisogno:

• JIRA
• JIRA Service Desk
• Confluence
• Gliffy

JIRA  – Fornisce la struttura base su cui memorizzare le informazioni dei vari strumenti.

JIRA Service Desk – Sarà utilizzato per gestire il supporto per i vari oggetti dell’asset. Sarà prevalentemente utilizzato come supporto.

Confluence – Sarà usato per creare la documentazione di corredo per i vari oggetti dell’asset. In particolare sarà utile per documentare il tutto.

Gliffy – Sarà utilizzato per creare i grafici per descrivere meglio la situazione aziendale.

In questo primo post andremo a vedere come configurare la parte JIRA.

 JIRA – Andiamo in dettaglio

Iniziamo ad implementare l’asset manager. Il primo passo è di creare un progetto su cui andremo a creare gli oggetti. Come?? semplice :-). Le varie Issue saranno gli asset veri e propri. Es. Creeremo una issue per classificare uno specifico notebook, uno specifico server, uno specifico monitor, etc etc etc.

Negli esempi della Atlassian, viene suggerito di chiamare il progetto TAG . Si tratta di un simple tracking project, non ci serve molto di più.

Una volta creato il progetto, occorre definire le ISSUE TYPE  cui il progetto farà riferimento. Che cosa significa questo? semplicemente andiamo a definire le issue come se si trattasse dei vari componenti dell’ASSET: computer, tablet, stampanti, monitor, server, etc etc etc etc. Nel nostro esempio abbiamo definito i seguenti tipi:

Per fare questo, occorre andare nella sezione di amministrazione del progetto TAG, quindi accedere alla sezione che gestisce gli Issue Type e definire i nuovi tipi di issue, associando loro una icona opportuna:

Una volta che gli issue type sono definiti, associarli ad un opportuno insieme (nel nostro caso ASSET Issue Type), che sarà poi associato al progetto TAG (come mostrato in figura).

A questo punto, definiamo quali campi andremo a visualizzare nei vari screen, ovvero nelle varie schermate che sono richiamate dalle procedure di JIRA. Ad Esempio, quando creiamo una nuova issue o quando la andiamo a modificare. Andiamo a settare i campi dello screen, come mostrato in figura:

Selezionando uno qualsiasi degli screen, possiamo selezionare quali campi vogliamo impostare:

Il prossimo passo è quello di definire il Workflow  cui farà riferimento il progetto TAG. Andiamo quindi a creare un nuovo workflow, selezionando un esempio di come potrebbe essere gestito un Asset in maniera molto semplice e rapida. Chiaramente è modificabile per ogni tipo di esigenza, da quella che richiede anche la possibilità di semplificare il workflow, a quella che richiede di complicarlo per gestire delle situazioni particolari.

In questo caso, abbiamo i seguenti stati:

• Richiesta  –  L’utente fa richiesta
• Disponibile  –  L’asset è disponibile
• Assegnato  –  L’asset è stato assegnato all’utente
• Supporto  –  L’asset è sotto supporto per riparazione o manutenzione
• Dismissione  –  L’asset è obsoleto e deve essere dismesso
• Dismesso  –  L’asset è stato dismesso e può essere rimosso dal magazzino.

Una volta creato il Workflow, lo possiamo associare al progetto, attivandolo e rendendolo operativo. Il tutto molto facilmente :-).

Se abbiamo a disposizione l’addon JIRA AGILE, possiamo anche aggiungere la AGILE KanBan Board, per poter gestire, in modo visuale, la gestione degli stati :-). La seguente immagine fornisce un esempio:

Qui ho aggiunto solo alcuni esempi, per fornire una idea. Immaginatevelo con i vari asset. Per aziende molto grandi, non è proponibile utilizzare questa soluzione, ma per piccole e medie realtà, questa soluzione è assolutamente valida. In aggiunta, se si fa uso delle Componenti, possiamo anche ottenere delle visualizzazioni dedicate per tipologia di Asset :-). Basta lasciare correre la fantasia.

Conclusione

In questo primo post abbiamo visto come configurare il progetto JIRA per poter gestire i dati degli asset. Nel prossimo post andremo ad usarlo e successivamente passeremo a configurare la seconda parte: JIRA Service Desk per gestire eventuali segnalazioni a chi gestisce l’asset in azienda.

Automation

In questo post andiamo ad esaminare le novità che sono presenti in JIRA Service Desk 2.4. Vi rimando ai precedenti post, dove potete esaminare le potenzialità del prodotto già descritte

Novità

Iniziamo con il dettagliare questa importante novità: Automation . Vediamo di che cosa si tratta.

Fondamentalmente sono stati introdotti dei meccanismi che automatizzano diverse operazioni, che possono essere abbastanza pensanti da ripetere manualmente, e che aiutano a ridurre gli errori ed ad aumentare la produttività.

In aggiunta, è stato aggiunto in indicatore numerico che consente di poter valutare l’importanza della segnalazione, migliorando la produttività ed indirizzando le azioni dove effettivamente serve.

Migliorie minori…

Oltre a quanto già indicato, sono state rilasciate le seguenti migliorie, minori come intervento, ma non meno importanti 🙂

E’ stata migliorata la possibilità di poter impostare il logo della propria azienda.

E’ stato esteso l’uso del Rich Text Editor anche nei commenti, evitando agli agenti di dover ricorrere sempre al wiki markup per poter impostare le risposte

Conclusioni

Abbiamo delle novità molto accattivanti. La possibilità, di poter automatizzare determinate operazioni, è sicuramente importante. Nei prossimi post andremo a saggiare queste novità e cercheremo di capire come si comportano e che limiti presentano.

Reference

Si rimanda al seguente video della Atlassian, per maggiori dettagli.

http://www.youtube.com/watch?v=ryoVNiHt8F8

Maggiori informazioni sulla versione 2.4 sono reperibili qui.

Domande & Risposte

Proseguiamo quanto iniziato in questo post, dove abbiamo iniziato a fornire delle risposte ad alcune domande che mi sono state poste nel corso della mia esperienza.

JIRA Cloud o Server?

Il suggerimento è il medesimo di Confluence. Se abbiamo una organizzazione piccola, cloud è sicuramente la nostra risposta. Nessuna preoccupazione, un prezzo accettabilissimo e tutte le funzioni pressoché disponibili 🙂

La versione Cloud risponde in pieno alle esigenze anche di gruppi di lavoro abbastanza ampi, anche remoti. Se invece l’organizzazione dispone di un numero molto alto di persone, la versione Server è sicuramente la migliore soluzione.

Conviene usare JIRA Service Desk?

La risposta è sicuramente SI :-). JIRA Service Desk combina le caratteristiche di un ottimo service desk e trouble ticket manager, con la potenza di JIRA e della organizzazione. La semplicità di uso, descritta nei post, è sicuramente un grande vantaggio, allo stesso modo della licenza che la Atlassian fornisce per utilizzare questi prodotti.

Aggiungendo che tutti i prodotti Atlassian sono fruibili anche da tablet, con la stessa facilità di uso, ne fa un prodotto irrinunciabile.

AGILE o non AGILE con JIRA?

Dipende. In questo caso, l’unico consiglio che posso dare è il seguente. Seguite la strada più semplice in assoluto per voi. Non usate le metodologie Agile solo perché l’azienda concorrente le usa e si trova bene o per semplice moda.

Questo è un errore. Piuttosto scavate a fondo nelle metodologie in uso, analizzatele e, solo dopo attenta analisi, usate altra metodologia o una sottoparte della Agile, quella che effettivamente calza a pennello con le persone in azienda, con i clienti, con quello che siete.

Se volete fare uso di AGILE, JIRA mette a disposizione addon molto belli e pratici, che nella vita lavorativa di tutti i giorni aiutano gli sviluppatori e i project manager.

Asset manager? possibile con JIRA?

La risposta è SI :-D. Con JIRA è possibile gestire degli ASSET manager, in maniera molto semplice. Già in questo post, ho dimostrato che, partendo da un esempio che la Atlassian stessa pubblicava, riuscivo a dimostrare che era possibilissimo gestire delle risorse riusabili. Nei prossimi post vedremo anche degli esempi reali che mostrano come poter fare. Riporto qui quello che la Atlassian ha creato per gestire il proprio Asset 🙂

Conclusioni

Ho cercato di riassumere alcune domande che mi sono state poste nel corso della mia esperienza lavorativa. Spero che possano essere utili. Nei prossimi post cercherò di aggiungere altre domande/risposte.

Chiamate REST

In questo post, iniziamo ad affrontare un tema molto importante, che riguarda come poter utilizzare le chiamate REST per poter programmare i vari prodotti della Atlassian. Si tratta del primo di tanti post che saranno dedicati all’argomento.

Un pò di definizioni

Partiamo fornendo alcune definizioni, che saranno utili per chiarire un pò di cose. La definizione di REST può essere reperita a questo link, da fonte WIKIPEDIA. Un altro esempio che consiglio è anche questo link, dove trovare alcuni esempi e definizioni. Altra definizione importante è quella di JSON, ovvero di un sistema di interscambio dei dati molto adatto per queste architetture.

Fondamentalmente, REST indica una architettura utilizzata per lo scambio di informazioni, per andare direttamente al dunque :-).

I vari prodotti della Atlassian, quali Confluence e JIRA, mettono a disposizione un insieme di API, già preconfezionate, attraverso il quale scambiare/reperire informazioni dai vari prodotti.

Iniziamo …

Vediamo adesso come partire per sfruttare queste informazioni. Iniziamo subito con un esempio pratico, che utilizza Confluence, per meglio chiarire il tutto. Per richiamare le API occorre sfruttare una URL come il seguente esempio:

http://192.168.114.140:8090/confluence/rest/api/XXXXXXXXX

dove XXXXXXXXX rappresenta la api che si vuole richiamare.

Ovviamente, si tratta di un esempio di URL che ho ricavato dalla mia installazione di test. Se andiamo ad usare una api molto semplice, quale CONTENT, che restituisce il contenuto del nostro Confluence, questo è il risultato:

Lanciando la API, senza fornire alcun parametro, quello che otteniamo è un JSON, che rappresenta il contenuto del nostro Confluence. Se iniziamo a raffinare la chiamata, passando uno dei parametri quale l’ID:

http://192.168.114.140:8090/confluence/rest/api/content/884738?status

Quello che otteniamo è il contenuto della seguente pagina:

che avevo creato per mostrare un esempio di page properties :-).

Quindi?

Quello che otteniamo è un grande risultato. A questo punto si apre un ventaglio di opportunità. Possiamo a questo punto leggere/scrivere tutta una serie di informazioni sul nostro Confluence, semplicemente sfruttando queste API. In questo modo si possono realizzare nuove funzionalità per tutti gli strumenti della Atlassian.

Conclusioni

Abbiamo visto, in questo post, in primo esempio di come poter accedere a queste api, di quali cose sono necessarie conoscere per poterle utilizzare e che risultati forniscono. Nei prossimi post Esamineremo degli esempi di utilizzo e di come poter utilizzare e chiamate REST per realizzare delle nuove funzionalità.

Prosegue il viaggio

Proseguiamo, in questo post, quanto iniziato dal primo e secondo post su JIRA Service Desk. Verdremo come configurare ed usare le SLA, la repostistica. Quindi spiegheremo un semplice esempio di che cosa succede, da quando si apre un ticket a quando lo si risolve.

 Terminologia

Diamo la definizione di alcuni termini, per meglio chiarire alcuni concetti.

Iniziamo con il termine SLA, ovvero Service Level Agreement. Vi rimando al link precedente per una definizione ufficiale. Si tratta degli indicatori della qualità del servizio. JIRA Service Desk consente di poterli configurare attraverso le proprie pagine di amministrazione, nonché di monitotarle attraverso opportuni strumenti 🙂

Configurazione

Accedendo alla dashboard di gestione, possiamo impostare le configurazioni. Se selezioniamo il TAB SLA, accediamo alla definizione delle metriche.

Selezionando New Metric è possibile inserire una nuova metrica, configurarla in modo abbastanza semplice. Vediamo come.

Una volta selezionato New Metric, possiamo impostare quale nome assegnare alla metrica (nella immagine precedente, ho scelto di chiamarla Esempio SLA, ma utilizzate il nome che vi è più comodo.

Fatto ciò, occorre selezionare quali stati del task JIRA sono indicati per fare, letteralmente, partire l’orologio che conta le tempistiche della SLA.  Una volta impostato tutti i parametri, selezioniamo Create e la nuoa SLA è creata.

Il sistema richiederà qualche istante, per eseguire il ricalcolo (vedi figura precedente), per controllare se esistono delle richieste che in qualche modo si riferiscono alla nuova metrica.

Prossimo passo?

Dopo aver configurato le metriche, vediamo come utilizzarle per generare dei report e vedere a questo punto il risultato della nuova metrica. Per fare ciò , basta semplicemente collegarsi alla sezione Reports e creare un nuovo report basato sulla metrica che abbiamo creato.

Selezioniamo New Report e procediamo con la creazione del nuovo report, semplicemente accedendo alla autocomposizione che ci aiuta nella generazione.

Selezioniamo Add Series e aggiungiamo tutte le informazioni per generare il nuovo report.

Fatto ciò, Questo è il risultato:

Conclusione

Abbiamo visto un esempio di come definire un nuovo SLA e come costruire un report basato su di esso. Nei prossimi passi vedremo altre funzionalità di questo prodotto.

JIRA Service Desk 2.3 – Ultime novità

In questo post proseguiamo quanto riportato qui, cercando di approfondire le ultime novità su questo prodotto della Atlassian.

Quali ulteriori novità?

Neanche un mese dalla uscita della versione 2.2, cerchiamo di elencare le novità introdotte 🙂

• Gli utenti possono invitare altri utenti per farli partecipare alle discussioni sulle richieste. Prima era consentito ai soli agenti poter eseguire queste operazioni. In questo modo, gli agenti hanno la possibilità di poter comunicare la risoluzione del problema ad un numero di utenti maggiore, ridurre il numero delle segnalazioni e concentrarsi solo sui veri problemi;
• Rimane invariata, per quanto riguarda le licenze, il discorso che, nell’ambito del JIRA Service Desk, la questione che solo gli utenti Agenti vengono contati per determinare le licenze;
• Gli Agenti possono aprire delle segnalazioni a nome di utenti specifici Gli agenti hanno quindi la possibilità di poter creare delle segnalazioni per nome e conto di utenti, continuano a poter invitare altri utenti nella segnalazione, consentendo di ridurre il numero di segnalazioni e concentrando il lavoro solo dove è necessario. Un bel passo avanti 🙂
• Supporto per le email di solo testo. Con questa nuova versione di JIRA Service Desk, viene data la possibilità di poter gestire delle email senza HTML. Questo per venire incontro agli utenti che utilizzano dei sistemi di lettura automatica di email o che sono …. affezionati alle email di solo testo 
• Migliorata la console di amministrazione. Viene data agli amministratori la possibilità di gestire meglio le email semplificando la console stessa e aumentandone la chiarezza. Viene data la possibilità di poter visualizzare maggiori informazioni, LOG e dettagli delle email utilizzate.
• Sono stati risolti un discreto numero di …. bug 🙂

Conclusioni

Viene confermato che la Atlassian non smetterà mai di sorprenderci con nuove features, nuove funzionalità e nuove caratteristiche non indifferenti. Sono sicuro che, tra non molto tempo, torneremo a parlare di nuove sorprese 🙂

Riferimenti

Maggiori informazioni possono essere rintracciate qui. Altre informazioni sono reperibili a questa pagina

Altro esempio di uso

Mostreremo, in questo post, come realizzare una semplice gestione della contabilità, sfruttando Confluence e JIRA. L’obbiettivo è di combinare le funzionalità offerte dai due sistemi e di metterli a disposizione di tutti coloro che intendono gestire una semplice contabilità. Si va da piccolo professionista, alla azienda strutturata.

Di cosa abbiamo bisogno

Elenchiamo quello di cui abbiamo bisogno 🙂

• Confluence (Cloud o Server)
• Team Calendar
• JIRA

Vediamo nel dettaglio come sfruttare questi strumenti.

Confluence

Useremo Confluence come repository dei nostri documenti. Come mostrato nei diversi esempi di uso, nei precedenti posts di questo blog, Confluence si presta molto bene nella gestione di documenti. Le pagine possono essere utilizzati per creare delle agevoli Dashboard, da usare per aggregare tutte le informazioni.

Allo stesso modo con cui abbiamo creato una scheda cliente, possiamo creare un repository per le fatture. A tale scopo, dedichiamo uno space alle fatture, dove la pagina principale sarà la Dashboard riassuntiva di tutte le fatture emesse, mentre le singole fatture saranno memorizzate su singola pagina. Sfruttando il meccanismo delle Page Properties, avremo sempre a disposizione un report riassuntivo con il quale potremo sempre visualizzare lo stato delle fatture, e capire se e quando sono state pagate, se sono da pagare, il cliente, etc.

La seguente immagine mostra un esempio di Dashboard che può essere realizzata.

In questo esempio si può vedere come io ho organizzato la mia gestione delle fatture. Opportune Page Properties mi consentono di poter definire tutte le informazioni di cui abbisogno. Si va dal nome del cliente (che a questo punto, può essere una pagina a se stante di un altro Space Confluence, con tutte le indicazioni del cliente), alla data di emissione, anno riferimento, se il cliente è di buona o pessima qualità (ahimè occorrono anche queste informazioni) e, come conseguenza, se si è dovuti ricorrere ad un avvocato per il recupero crediti.

Ovviamente questo è un esempio abbastanza completo, ma non è il solo. Qui ci si può sbizzarrire con la propria fantasia o applicare le proprie conoscenze per poter avere a disposizione un quadro completo della situazione.

Team Calendar

Come per altri esempi, il Team Calendar è sicuramente utile per gestire gli appuntamenti aziendali, le scadenze fiscali o altre scadenze di vario genere.

Abbiamo anche la possibilità di poter generare più Calendari distinti, a seconda delle necessità. Si potrebbe avere a disposizione un calendario per le scadenze fiscali, un calendario per le scadenze di una divisione o di un ufficio, un calendario per gli eventi ed un calendario per le ferie del personale, etc etc etc :-). Lasciate correre la fantasia.

JIRA

JIRA viene usato per tracciare le varie attività. Ovviamente, JIRA può anche essere utilizzato per gestire progetti NON IT, non di sviluppo software. 🙂

Impostando i vari task, abbiamo la tracciatura completa delle varie attività. In aggiunta, inserendo le ore dedicate, abbiamo il controllo completo delle varie attività.

Quindi??

Semplicemente eseguendo una estrazione delle attività, attraverso JQL, possiamo ricavare il totale delle ore e determinare le fatture da emettere ai vari clienti.

Conclusioni

Confluence e JIRA si dimostrano dei software poliedrici, che consentono anche a persone non IT di poter essere validi strumenti per lo svolgimento delle operazioni di tutti i giorni, aiutando gli utenti nel loro lavoro e fungendo da supporto non indifferente per loro. Quanto riportato in questo post, può essere implementato sia nella versione Cloud, che nella versione Server.

Nei prossimi post, cercheremo di fornire ulteriori esempi di utilizzo di questi software.

Continuiamo il viaggio

Proseguiamo, in questo post, l’esempio di uso di JIRA Service Desk, mostrando come eseguire la configurazione del Customer Portal.

Customer Portal

Il Customer Portal è la porta di accesso degli utenti verso il Service Desk. Da esso, i vari customer possono veicolare le richieste o andare a visionare le richieste che hanno inviato ai vari agenti.

La configurazione viene eseguita dalla dashboard principale del Service Desk. Solo gli amministratori possono eseguire questa operazione.

Selezionando Settings -> Channel: Portal Settings, si accede alla sezione di gestione dello stesso, come mostrato nella figura successiva. Da qui, possiamo impostare tutte le modifiche di cui necessitiamo.

Possiamo impostare il nome del Portale (ArtigianoDelSoftware Support e trasformarlo come meglio crediamo), inserire un testo introduttivo ad hoc, inserire un logo.

Altra cosa, possiamo anche modificare lo schema di colori, andando a selezionare (come indicato in figura soprastante) JIRA Service Desk Configuration Page. Questo ci reindirizzerà alla pagina di configurazione

dove possiamo … giocare con la grafica del nostro Customer Portal, rendendolo anche più piacevole per gli utenti.

Come ulteriore configurazione, possiamo inserire anche un link al Knowledge Base, semplicemente andando a inserire l’opzione presene sul menù

In questo caso, saranno considerate le Application Link configurate su JIRA. In questo esempio abbiamo il link a Confluence, e di conseguenza sarà più agevole impostare il tutto. Infatti, se selezioniamo Confluence, sarà richiesto quale space dello stesso sarà usato per le ricerche di KB:

Prossimi Passi

Nel prossimo post, andremo ad impostare le caratteristiche del Service Desk, quali le SLA che deve avere, quali metriche leggere, etc.

Esempio di uso

Primo, di una miniserie di post, dedicati all’utilizzo di JIRA Service Desk. In questo post vedremo come installare e realizzare la prima configurazione dello strumento.

https://www.atlassian.com/docroot/wac/resources/wac/videos/jsd2/JSD-001.webm

Definizioni

Forniamo un pò di definizioni, che saranno utili per comprendere i vari aspetti dello strumento.

• Agent, si tratta fondamentalmente degli utenti che recepiscono le segnalazioni e che rispondono agli utenti finali;
• Customer, si tratta dell’utente finale, che inoltra le richieste vere e proprie.

Licenze

In termini di licenze, per l’utilizzo di Jira Service Desk è necessario contare il numero di Agenti, mentre è possibile disporre di un numero illimitato di Customer. La seguente pagina fornisce tutte le indicazioni del caso.

Addon

Altro concetto fondamentale, che deve essere ben chiaro, è che si tratta di un Addon per JIRA. Occorre quindi che si disponga di JIRA per poterlo usare. NON può essere utilizzato Standalone. Dal sito della Atlassian, è possibile scaricare le versioni di JIRA con già preinstallato JIRA Service Desk, ma per tutti coloro che vogliono, possono anche installarlo in un secondo momento.

Analogo discorso per le versioni Cloud. Quando si esegue l’acquisto per la prima volta, viene richiesto quale versione di intente usare. Per coloro che già dispongono ed utilizzano JIRA, basta semplicemente andare nella gestione degli Addon, quindi procedere …. all’acquisto dell’addon stesso. :-).

Primo passo – Creazione Service Desk

Una volta installato e pronto all’uso, occorre procedere alla creazione del Service Desk vero e proprio. Questa viene eseguita attraverso il menù Service Desk –> Create a Service Desk, come mostrato in figura

Viene quindi attivata l’autocomposizione, che ci aiuta nella generazione dello stesso.

Possiamo creare il Service Desk Project da zero, oppure agganciarlo ad un progetto JIRA esistente. Infatti, fondamentalmente, il Service Desk utilizza un JIRA Project per eseguire tutte le sue operazioni, estendendone le funzionalità ed aggiungendo delle Dashboard di gestione per gli Agents.

Supponiamo di creare un nuovo progetto. Forniamo seplicemente il nome del progetto e la sua chiave, come avremmo fatto ad un qualsiasi progetto.

Al termine della elaborazione, sarà presentata la dashboard generale:

Già in questa fase, il Service Desk è utilizzabile. La generazione del progetto ha già fornito una prima configurazione che, se non si richiedono ulteriori indicazioni, è già sufficiente per poter lavorare e creare il tutto. Il Customer Portal risulta così configurato:

Permettendo di poter aggiungere le prime richieste. Ovviamente siamo sono all’inizio.

Prossimi passi

Nel prossimo post, andremo ad analizzare come costruire l’interfaccia verso gli utenti finali e vedremo una prima configurazione dello stesso.