JIRA 7 a Bologna

Il 27 Ottobre si è svolto a Bologna un evento dedicato a JIRA 7. Ho avuto la fortuna di poter partecipare all’evento e di poter vedere le ultime novità di JIRA 7. In questo post, e nei seguenti, cercherò di riassumere quanto è stato presentato in questo evento 🙂

Team più performanti con JIRA

Il core della presentazione verteva sulla presentazione delle novità di JIRA 7, presentate da un ospite di eccezione: Vladimir Cavalcanti; EMEA Experts Manager Atlassian.

Dopo una breve introduzione, da parte di Alessandro Rizzoli di GetConnected, Vlad Cavalcanti ha iniziato una presentazione, tutta dedicata alla Atlassian, fornendo una panoramica sui vari prodotti e sui clienti (ben 50.000), tra cui anche la NASA, dove la Atlassian ha fornito il suo contributo per la missione Rover Mars.

Vlad ha poi subito introdotto le ultime novità su JIRA 7, descrivendo le nuove pacchettizzazioni:

• JIRA CORE
• JIRA SOFTWARE
• JIRA Service Desk

Durante la presentazione ha subito evidenziato una delle domande più comuni, tra quelle che solitamente vengono poste durante le presentazioni: Gli Addons rimangono compatibili? La risposta: Rimangono compatibili con la nuova versione.

Ha quindi evidenziato le indicazioni per le licenze: Nel caso dei vari prodotti, vince la licenza con il taglio più alto.

Vlad Cavalcanti ha quindi concluso il suo intervento mostrando un semplice caso d’uso di tutti i giorni, un esempio di situazione che si è presentata nel suo lavoeo e di come, i prodotti della Atlassian, lo hanno aiutato , soffermandosi come questi strumenti aiutano i team non IT

Si è quindi soffermato anche sulle ultime novità di Hipchat, segnalando che sarà presto rilasciata la versione Server per questo prodotto.

Ha concluso il suo intervento parlando degli Ship-It Days in Atlassian, dove tutti aiutano con nuove idee. Ripeto: TUTTI. Una piccola curiosità: JIRA Service desk è nato a seguito di uno Ship-It :-).

Segue una presentazione, a cura di Cecilia Berbardi, sulla Continuos integration e sulla esperienza in azienda GetConnected.

Cecilia ha fornito una ottima spiegazione dei processi aziedali, sulla realtà e su come i prodotti della Atlassian, attraverso la loro integrazione, sono un valido supporto.  :-). Passare da un sistema di scambio di file ad un sistema di integrazione, condivisione, scambio, ma sopratutto UNICO :-). Questo è il valore aggiunto dei prodotti Atlassian.

Seguita una ottima presentazione di Luca, su come JIRA Service Desk aiuta i gruppi di lavoro nello svolgere il proprio lavoro, mettendo a disposizione sistemi semplici e veloci per la gestione delle anomalie e delle informazioni.

L’evento è stato chiuso da un intervento su JIRA Portfolio:  Il prodotto più giovane della famiglia Atlassian. Federico Sita ha mostrato, con una demo molto completa e chiara, come questo prodotto può essere di aiuto nelle simulazioni e delle pianificazioni trasversali i vari gruppi di sviluppo.

Conclusioni

Un grande evento per Bologna, una occasione di potersi confrontare con esperti del settore e con varie esperienze sull’argomento. Sicuramente da ripetere

Alcune ….. anticipazioni

In questo post raccogliamo alcuni rumors ed anticipazioni sui vari prodotti della Atlassian.

JIRA si fa in tre …

La prima novità che salta all’occhio è che JIRA viene ristrutturato. Per gli utenti si fa in tre :-). Abbiamo una riorganizzazione non indifferente che si attuerà nei prossimi giorni e che la Atlassian stessa spiega attraverso il suo portale Migration Hub.

Presentata ufficialmente il 6 ottobre, sono già presenti delle indicazioni sui blog esteri, dove i vari partner iniziano a presentare i nuovi prodotti in orbita JIRA. Qualche indicazione la trovate qui, in lingua inglese e qui in lingua spagnola. Aggiungo anche una piccola curiosità, che ho trovato in rete: Anche Jessica Alba usa JIRA 🙂

Abbiamo una nuova pacchettizzazione dei vari prodotti, il cui risultato è la seguente ristrutturazione:

JIRA Software

Si tratta della fusione del vecchio JIRA con JIRA Agile, con l’obbiettivo di mettere a disposizione uno strumento dedicato agli sviluppatori. In questo modo si dispone di uno strumento pronto all’uso e prettamente dedicato allo scopo.

JIRA Service Desk

JIRA Service Desk raggiunge la versione 3 e cresce a sua volta.

L’obbiettivo di JIRA Service Desk è quella di implementare una versione di Service Desk . Di primo acchitto, mi viene da dire che si vuole creare una versione Isolata di JIRA Service Desk. Attendo di assistere alle presentazioni per meglio capire che cosa si vuole fare.

JIRA Core

Fa la sua comparsa JIRA CORE. Si tratta di una pacchettizzazione dedicata ai NON Sviluppatori. Con questa operazione, la Atlassian intende creare una pacchettizzazione dedicata a tutti coloro, che non si occupano prettamente di sviluppo software, che necessitano di un sistema di tracciatura delle segnalazioni/anomalie/implementazioni.

Conclusioni

Grandi novità all’orizzonte. Attendo di partecipare ad un evento, in quel di Bologna, in cui sarà presentato JIRA 7. Seguiranno degli ulteriori post, appositamente dedicati all’evento, in cui descriverò meglio le caratteristiche.

JIRA Service Desk – Ultime News

In questo post andremo ad esaminare le ultime novità relative a JIRA Service Desk.

In dettaglio

Dal mese di settembre, la versione cloud è arrivata alla 3.0.0 :-). In aggiunta, ogni settimana viene eseguito un aggiornamento di versione. Partiamo dal primo aggiornamento e proseguiamo di conseguenza 🙂

E’ stata aggiornata la pagina di presentazione, il wizard che guida nelle prime fasi di configurazioni del JIRA Service Desk, come mostrato nella figura

E’ stata resa più agevole la possibilità, da parte degli agenti, di condividere gli attachments con gli utenti.

In aggiunta sono stati rilasciati diversi bug fix.

Conclusioni

Continua la fase di miglioramento continuo del JIRA Service Desk. Rimaniamo in attesa di ulteriori sorprese 😀

Reference

Maggiori informazioni sono reperibili qui.

Proseguiamo il nostro confronto

In questo post, proseguiremo il nostro viaggio, verificando come possiamo gestire un progetto utilizzando altri prodotti Atlassian.

JIRA Service Desk

Ad un certo punto, il progetto sarà eseguito il deploy del progetto e sarà reso fruibile agli utenti. Da quest momento in avanti, quello che si andrà a dover gestire è la manutenzione dello stesso.

A tale proposito JIRA Service Desk è la soluzione migliore per poter gestire il Service Desk del progetto. Facilmente integrato con tutti i prodotti della Atlassian, consente di poter implementare un sistema di gestione delle anomalie/richieste/nuove evolutive, in maniera molto semplice.

In maniera molto semplice, e con pochi click, come già spiegato in questi posts, possiamo implementare un sistema molto semplice, con una interfaccia chiara e diretta. Pochi passi e anche chi si occupa di gestire queste situazioni, dispone di un quadro completo.

Pochi click e già si dispone di un sistema comprensivo di reportistica e di strumenti in grado di monitorare la produttività.

L’integrazione con JIRA, consente agli agenti di potersi interfacciare direttamente con il gruppo di sviluppo / manutenzione senza grandi difficoltà e, una issue generata con JIRA Service Desk viene subito reindirizzata alla persona giusta affinché la gestisca nel minor tempo possibile.

La possibilità di poter modificare il workflow, in modo da gestire tutte le situazioni di cui si ha la necessità, ci consente di poter coprire le nostre esigenze al meglio.

Conclusioni

Abbiamo uno strumento valido per gestire il servizio di trouble ticketing, che abbiamo già esaminato in dettaglio in altri posts, che nella gestione di un progetto non deve assolutamente mancare. Nei prossimi post, andremo ad inserire FISHEYE e JIRA Capture per andare a gestire meglio determinate situazioni.

Nuove migliorie

In questo post andremo a visionare le ultime novità introdotte dalla Atlassian, su JIRA Service Desk per la versione 2.5. Continuiamo quanto riportato nei post:

• JIRA Service Desk 2.0
• JIRA Service Desk 2.2
• JIRA Service Desk 2.3
• JIRA Service Desk 2.4

Ultime novità

Le ultime novità riguardano i seguenti aspetti:

• Reporting: Migliorato ed aggiunte nuovi reports, per meglio monitorare le attività degli agenti.

• Portal: Migliorata ulteriormente la possibilità di personalizzare il Portal

• Queue Update: Migliorato il comportamento delle code e migliorato l’update

Conclusioni

Si tratta mi piccole migliorie, ma sono sicuro che introducono un grande miglioramento. Nei prossimi post andremo ad esaminarle nel dettaglio, continuando il percorso iniziato con i seguenti post:

• Esempio di uso – Parte 1
• Esempio di uso – Parte 2
• Esempio di uso – Parte 3

Cloud o Server?

In questo primo post, di una serie dedicati all’argomento, andremo ad esaminare quali sono le differenze principali tra le due release dei prodotti. Obbiettivo è quello di fornire tutte le informazioni necessarie per operare la scelta migliore, in base alle esigenze.

Andiamo nel dettaglio

Credo che il primo punto da chiarire sia dare una prima spiegazione del perché di queste differenze. Innanzitutto, si tratta di situazioni differenti. Le versioni cloud (ex onDemand) sono gestite centralmente dal personale Atlassian e, di conseguenza, alcune funzionalità sono controllate direttamente da loro. Fornirle in mano ai clienti potrebbe essere controproducente in quanto potrebbe arrivare ad impattare altre installazioni.

Quali prodotti sono disponibili in cloud?

Prima di vedere le differenze, vediamo quali prodotti Atlassian sono disponibili.

• Confluence
• JIRA
• JIRA Service Desk
• JIRA Agile
• JIRA Portfolio
• Hipchat
• Bamboo

Adesso vediamo il dettaglio delle varie caratteristiche.

Il ruolo di System Administrator  viene ricoperto dal personale Atlassian. Di conseguenza, tutte le funzionalità che ruotano a tale ruolo, non sono disponibili.

I Backup schedulati non sono possibili, ma è comunque possibile eseguire una esportazione dati, al fine di riportarla su installazioni Server. I backup giornalieri NON sono consentiti in quanto il personale Atlassian li gestisce a livello centrale.

User Macro, HTML Macro e tutto ciò che impatta HTML (come macro standard) è disabilitato. Non esiste altra possibilità di poter abilitare tali addon su Cloud. Tuttavia, sono disponibili degli addon di terze parti che consentono di includere pagine web di siti terzi.

Mail Account e Mail server sono configurati e gestiti a livello centralizzato. Questo per gestire il tutto a livello centrale. Di conseguenza non è possibile customizzare questa parte.

Le versioni cloud utilizzano dei propri layout, ma non risulta possibile inserire delle variazioni ai CSS per la versione Cloud nè personalizzare il layout della versione cloud.

Non tutti gli addon sono disponibili per la versione Cloud. Il motivo è da ricercarsi nel fatto che, essendo la versione cloud centalizzata, la Atlassian ha modificato il come impostare gli addon per la soluzione cloud. Di conseguenza, anche lo sviluppo deve avvenire in maniera differente. Il seguente link aiuta a capire quali addon sono, al momento, disponibili. Come ho già avuto modo di evidenziare in post pubblicati, il numero di addon per la versione cloud è notevolmente aumentato nell’ultimo anno. Per la tecnologia da usare, fare riferimento ad Atlassian Connect. dedicheremo post a questo argomento.

Conclusioni

In questo post abbiamo dato una prima scorsa alle differenze tra le due installazioni, dove abbiamo visto quali operazioni sono possibili per una o per l’altra installazione. Questo aiuta sicuramente nella scelta del prodotto che si vuole e nel bugdet a disposizione. Nei prossimi post andremo a dettagliare le differenze, evidenziandole e commentandole.

Riferimenti

Pagina della documentazione Confluence disponibile qui.

Introduciamo Confluence

In questo post andremo ad introdurre Confluence nella gestione dei progetti, come elemento di supporto per la gestione dei progetti.

Partiamo subito

Il primo punto da chiarire è quello di definire quale è l’obbiettivo di Confluence, nella gestione di un progetto.

Confluence deve essere il contenitore dove posizionare TUTTE le informazioni del progetto. Ovvero:

• Analisi funzionali e tecniche
• Documentazioni tecniche di riferimento
• Verbali di riunioni, sia con il cliente che interne
• Piani di Battaglia, ovvero il dettaglio di come sviluppare
• Piani di rilascio delle varie versioni, spiegati in dettaglio.
• Documentazione
• CV del personale
• Template di documenti
• tutto ciò che si ritiene utile per lo svolgimento del progetto 🙂

Riassumendo, Confluence deve contenere tutte le informazioni del progetto, ovviamente opportunamente organizzate. 🙂 Se si inserisce alla rinfusa, non serve a nulla. Il tutto deve essere organizzato e fruibile da tutto il team di sviluppo.

Organizzazione

La prima cosa che consiglio è di predisporre uno Space per progetto. In questo modo si hanno due vantaggi subito:

• Tutte le informazioni sono presenti in un unico punto
• La gestione delle permission è molto semplice e veloce

e sono due vantaggi non indifferenti :-D.

Attuando questa organizzazione, si può sfruttare anche un addon molto importante, che consente di poter generare dei template di Space. Ho già descritto le potenzialità di questo addon su altri post. Le potenzialità sono enormi. Abbiamo la possibilità di creare un template di space, organizzarlo in base alle esigenze richieste o avere anche più template in base alla tipologia di progetti

Possiamo anche impostare i template per le varie pagine che comporranno lo Space del progetto. In questo modo, se dobbiamo redarre il verbale della riunione con il cliente, ci semplifichiamo notevolmente il lavoro.

Occorre sempre tenere a mente che Confluence deve essere uno strumento di aiuto nella conduzione del progetto, non un peso aggiuntivo che ci limita i movimenti e che non seguiamo perchè lo riteniamo un ….. problema.

Quindi sfruttiamo tutte le funzionalità per far si che sia un valido supporto. 🙂

Possiamo anche collegarci dei Database, in modo da visualizzare dei risultati di elaborazioni o delle statistiche o, molto più semplicemente, estrarre dei dati dal gestionale per poterli visualizzare e controllare. In questo modo, Confluence diventa il punto unico di gestione del progetto.

Colleghiamo Confluence e JIRA

Confluence e JIRA si collegano e si …. parlano senza alcun problema. Per far ciò occorre procedere con una pocedura particolare, che si chiama Application Link, che mette in comunicazione i due sistemi. In questo modo, possiamo vedere le issue JIRA anche in Confluence :-), come già mostrato nel post precedentemente pubblicato.

Dalla figura sopra riportata, si vede che è possibile collegare i due sistemi. Per maggiori dettagli si rimanda a questa pagina.

In questo modo, possiamo creare delle pagine ad hoc, dedicate alla documentazione di dettaglio di una release di bug fix. Possiamo avere un dettaglio maggiore o di livello funzionale, per i vari bug. In questo modo, su JIRA abbiamo il dettaglio tecnico (campo di database non scritto e corretto), mentre su Confluence possiamo avere il dettaglio funzionale (provincia non riportata nella anagrafica del cliente). Giusto per fare un esempio 🙂

Roadmap aka Piano di battaglia

La macro Roadmap è sicuramente utile per la gestione di un progetto. La macro offre la possibilità di poter rappresentare un vero e proprio piano di battaglia per gestire il progetto:

• rilasci
• avanzamento lavori
• componenti
• variazioni
• etc etc etc 🙂

Come già mostrato nei precedenti post, e dalla immagine sopra riportata, si può vedere che, grazie ad un colpo d’occhio, abbiamo il piano di battaglia, le azioni che saranno intraprese, gli sviluppi predisposti, e tutto ciò che serve.

Questo è di sicuro utile per gestire il tutto ed avere sempre sott’occhio la situazione.

Conclusione

Abbiamo visto in questo post come Confluence diventa, nell’ambito dello sviluppo di progetti, un punto centrale e nevralgico. Abbiamo un unico punto in cui reperire e concentrare le informazioni, senza dover impazzire a cercare il tutto. Verbali, documenti di analisi, documenti del cliente trovano perfettamente posto in Confluence e, grazie alle sue funzionalità, si rivela il più importante dei collaboratori di un progetto.

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.