Usiamo Confluence

In questo post andremo ad esaminare come possiamo utilizzare Confluence nell’ambito di un progetto, chiudendo quanto iniziato in questo post e continuato in questo post.

Come possiamo usarlo?

Possiamo usare Confluence per classificare i vari asset in uso, documentare in maniera completa tutti gli interventi e/o indicare pregi/difetti degli stessi. Quello che è possibile fare è creare uno space dedicato, in cui andremo a creare le varie pagine di dettaglio.

Lo Space presenterà una pagina Home, in cui sarà riportato un quadro riassuntivo dei vari asset. Sfruttando le Page Properties riusciamo a creare delle pagine di dettaglio, che possiamo raggruppare come già visto nelle schede clienti.

In questo modo possiamo avere delle schede tecniche, utili per il supporto, che consentono di poter migliorare il lavoro. Si può, in questo modo, arrivare a gestire meglio l’assegnazione delle risorse. Ad esempio, se un capo cantiere ha la necessità di un portatile, quando è in cantiere, non ha senso assegnargli un notebook normale, ma conviene assegnargli un notebook che possa reggere gli urti, che possa sopportare le sollecitazioni, etc.

Se il responsabile degli asset dispone di tutte queste informazioni, riesce a fare meglio il proprio lavoro. 🙂

Andiamo in dettaglio e verifichiamo come possiamo realizzare queste schede.

Scheda Asset

Una scheda asset, sicuramente, dovrà contenere le informazioni del dispositivo, con tutte le caratteristiche del prodotto, quante riparazioni/interventi ha subito, a quante persone è stato assegnato, etc.

Sfruttiamo le Page Properties per avere tutte queste informazioni, come mostrato nella figura sottostante

Allo stesso modo, possiamo collegare anche le ISSUE create dal Service Desk, per creare una cronostoria delle segnalazioni aperte (vedi figura precedente). Successivamente, possiamo anche visualizzare la ISSUE dell’Asset, usando le apposite Macro. Sulla pagina principale, possiamo invece avere un quadro situazione. Abbiamo un unico punto in cui contenere tutte le informazioni, tutti i drivers del pc o notebook, informazioni sul server, etc etc.

In questo modo si ha la possibilità di avere una scheda del server, notebook, computer, etc.; in cui l’amministratore deve gestire, arrivando ad avere il controllo completo dell’Asset dell’azienda.

Grafici

Possiamo poi utilizzare Gliffy per arrivare ad avere dei grafici, come già visto, da utilizzare per capire come potersi muovere per eseguire operazioni, manutenzioni, azioni, etc.

La  seguente immagine può aiutare a comprenderne le potenzialità 🙂

Allo stesso modo, come già mostrato nel post precedentemente pubblicato, possiamo sfruttarlo per creare grafici di flussi di lavoro e tutto ciò che può tornare utile per poter gestire il nostro ASSET, comprensivo della localizzazione dell’asset. A tale scopo, potrebbe tornare utile anche il seguente addon.

Conclusioni

Abbiamo concluso, con questo post, l’argomento ASSET. Questo ovviamente  non esaurisce l’argomento e sicuramente, con le nuove funzionalità che la Atlassian metterà in campo, riusciremo ad estendere il tutto.

Ultime novità

In questo post andremo ad esaminare le ultime novità, introdotte dalla Atlassian, su Confluence, Jira etc.

Confluence

Con i rilasci eseguiti tra il 24 maggio ed il 30 maggio, è stata rilasciata la versione 5.9.0-OD-52 che presetava le seguenti nuove funzioni:

Modificata la macro Content by label, che viene estesa in modo da poter eseguire interrogazioni molto più mirate. Impariamo a conoscere il  CQL – Confluence Query Language, attraerso il quale è possibile eseguire opportune query nelle pagine, come mostrato nella figura precedente. Lo stesso è stato realizzato per le Page Properties: Le macro di riferimento sono state estese. Nei prossimi post andremo a visionare nel dettaglio queste nuove caratteristiche, con la solita prova su strada 🙂

I metadati della pagina (label, restrizioni, posizione) sono stati spostati in cima alla pagina. Questo facilita la gestione di queste informazioni.

Con i rilasci dal 31 maggio a 6 giugno, è stata rilasciata la versione 5.9.0-OD-56 che ha introdotto le seguenti novità:

Sono state introdotte le Table Settings, attraverso le quali è possibile inserire in automatico la numerazione in prima colonna. Un automatismo non indifferente :-). Altra novità introdotta è la possibilità di poter copiare le colonne di una tabella molto semplice. Nella bottoniera, in alto, oltre alle funzionalità già presenti e cui siamo abituati, possiamo vedere i nuovi comandi.

JIRA

Passiamo adesso ad esaminare le novità per JIRA. Andiamo con ordine.

Con il rilascio eseguito dal 24 maggio al 30 maggio, con il rilascio della versione JIRA 6.5-OD-04, sono state rilasciate una serie di bugfix minori. Il seguente link li riassume tutti.

Con il rilascio eseguito dal 31 maggio al 6 giugno, con il rilascio della versione JIRA 6.5-OD-05, si è completato il rilascio con una ulteriore serie di bugfix minori. Il seguente link li riassume tutti.

JIRA Service Desk

Rispetto a JIRA, qui abbiamo delle belle novità :-). Andiamo con ordine.

Con il rilascio eseguito dal 24  al 30 maggio, con il rilascio della versione JIRA Service Desk 2.5.1-OD-02, si è completato il rilascio di diversi bugfix.

Con il rilascio eseguito dal 31 maggio al 6 giugno, con il rilascio della versione JIRA Service Desk 2.5.1-OD-03, viene rilasciato il nuovo service desk project navigation, come mostrato in figura.

Viene notevolmente migliorata l’interfaccia per creare dei portali custom per l’accesso al Service Desk.

Come si può vedere dalla figura, adesso abbiamo a disposizione un sistema molto più semplice ed intuitivo per poter creare il portale di accesso 🙂

Altri bugfix sono stati rilasciati con questa versione.

 Conclusioni

Abbiamo a disposizione delle belle novità. Come sempre la Atlassian ci continua a sorprendere con nuove belle funzionalità. Restiamo in attesa dei prossimi rilasci. 🙂

Reference

• Rilascio dal 24 al 30 maggio.
• Rilascio dal 31 maggio al 6 giugno.

Proseguiamo la configurazione

Proseguiamo quanto iniziato in questo POST e proseguiamo andando a configurare il progetto TAG e iniziando a configurare JIRA Service Desk.

Creiamo i nostri asset

Una volta configurato il nostro progetto TAG, iniziamo a creare le issue degli asset. Utilizzando la Agile Board Kanban, possiamo eseguire questa operazione molto semplicemente.

In questo esempio ho inserito alcuni asset, tra i quali una mia desiderata: Quello di comprare un server virtuale linux :-P. Questo è il risultato. Per piccole e medie imprese, professionisti o ditte individuali, questo sistema è sicuramente il migliore.

Già così, questa configurazione risulta sufficiente per poter gestire un Asset. La Board ci consente di poter lavorare senza doverci complicare la vita. Su piccole realtà, ci potremmo fermare a questo.

Un qualsiasi generatore di QR Code, la stampa di alcune etichette, ed il gioco è fatto.

L’immagine sopra riportata, corrisponde al QR Code del codice TAG-1.  Possiamo, come hanno realizzato in Atlassian, impostare un QR-Code in modo che riporti l’indirizzo esatto per accedere alla ISSUE TAG; possiamo inserire una URL che vogliamo. Lasciate che la Vostra fantasia faccia il suo corso 🙂

Su realtà già un pò più grandi, l’uso di JIRA Service Desk ci può aiutare nella gestione delle richieste e della gestione. Infatti, sfrutteremo le funzionalità di gestione delle richieste per poter aiutare, chi gestisce gli Asset. Vediamo come

JIRA Service Desk

Andiamo subito al dunque. Configuriamo subito un Service Desk. Come già indicato nei seguenti posts, procediamo di conseguenza. Creiamo il nuovo progetto di gestione.

Una volta creato il nuovo progetto, procediamo con la configurazione.

Iniziamo con il creare un ISSUE TYPE che comprenda quelli utilizzati dal progetto TAG. Quindi, configurare le richieste.

A questo punto, possiamo creare la richiesta, associando anche il TAG-XXX presente nel nostro device.Vediamo i vari passi.

Selezioniamo SUPPORT-2, per il passo successivo:

Selezioniamo la funzione LINK, per associare il nostro TAG-XXX

In fase di LINK, selezioniamo che il nostro SUPPORT-2 è bloccato dalle operazioni che si eseguono su tale link. La prima cosa che esegue chi si occupa del supporto, è di modificare lo stato del nostro TAG-5.

Quando le operazioni sono terminate, il TAG-5 sarà opportunamente dismesso, rimesso in magazzino, riassegnato, etc etc.

Conclusioni

Abbiamo visto, in questo post, come possiamo gestire il nostro Asset e come possiamo, attraverso JIRA Service Desk, gestire le richieste per supporto/manutenzione dei vari ASSET.

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.

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

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.

JIRA Service Desk 2.2

In questo post andremo a vedere le ultime novità, aggiunte al JIRA Service Desk. Proseguiamo quanto riportato sul post Jira Service Desk 2.0.

Novità

La prima novità consiste nel poter aggiungere ulteriori customer a delle richieste. Spieghiamo meglio. Nelle precedenti versioni non era possibile vedere le richieste degli altri utenti. Con la versione 2.2, è possibile poter aggiungere ulteriori partecipanti alla richiesta.

In questo modo, qualora sopraggiungano più richieste identiche, si può convogliarle in una unica facendo partecipare gli altri utenti ad una unica richiesta. Maggiori dettagli in questa pagina della manualista Atlassian.

Al momento questa funzionalità è utilizzabile dai soli utenti AGENT.

Come conseguenza, viene operato anche il seguente cambiamento a livello dei commenti.

• “Comment: By Reporter” viene rinominata come “Comment: By Customer”
• “Comment: For Reporter” viene rinominato come “Comment: For Customer”

Altra novità, la possibilità di poter personalizzare il Customer Portal, come mostrato in figura:

Abbiamo adesso la possibilità di poter personalizzare:

• Logo, con la possibilità di poter inserire il logo aziendale
• Nome, inserendo un nome più parlante al posto di Help Center
• My Recent Request è stato rinominato in My Request.

Una bella novità è la Search Box, che fornisce un ulteriore aiuto agli utenti, in quanto funge da punto di raccordo tra il servizio di Service Desk ed il knowledge base. Attraverso questa funzione, è possibile ricercare eventuali articoli che trattano di anomalia risolte.

Risultato?? Meno richieste di supporto duplicate, meno lavoro inutile e utenti più contenti 🙂

Da segnalare

JIRA Service Desk 2.2 è compatibile con JIRA versione 6.3.8 o successiva. Di conseguenza, prima di eseguire l’upgrade di JIRA Service Desk, eseguire l’upgrade di JIRA alla versione richiesta 🙂

Conclusioni

JIRA Service Desk mette a disposizione nuove ed interessanti caratteristiche. Ad ogni aggiornamento troveremo sempre delle belle sorprese.

Riferimenti

Release Note di JIRA Service Desk 2.2