Risorse per JIRA Service Desk

In questo post andremo ad integrare quanto già esposto in questo post, dove abbiamo introdotto alcune risorse per il mondo Atlassian.

eBook per JIRA Service Desk

Segnaliamo un nuovo libro dedicato interamente a JIRA Service Desk. In un momento in cui JIRA Service Desk si conferma come un o dei prodotti più interessanti nell’ambiente, arrivando ad ottenere la certificazione ITIL, come già descritto qui, questi libri sono un utile spunto per partire con questi prodotti.

Maggiori informazioni sono reperibili qui.

Una breve divagazione

In questo post facciamo una breve divagazione sulle Agile Board. Cerchiamo di capire come possiamo sfruttare questo strumento  in vari ambiti e, sopratutto, vediamo come possiamo adattare alle nostre esigenze lo strumento.

Ringraziamenti

Un ringraziamento a Maria Luisa, per il lavoro che sta svolgendo con i prodotti Atlassian e che ha causato questa divagazione. 🙂

Vediamo come possiamo ….

… sfruttare la Agile Board a nostro uso e consumo. Infatti, si presta bene a diversi utilizzi, come ho già avuto modo di mostrare nel Workflow che ho già pubblicato qui nel marketplace della Atlassian, dove ho mostrato come poter utilizzare la Agile Board per tracciare il flusso delle fatture.

Un altro esempio lo trovate anche in questo post, che ho dedicato ad una ipotesi di realizzazione di Asset Management, dove anche li ho mostrato come la Agile Board trova un suo utilizzo molto naturale nel tracciare lo stato di ogni singolo asset.

Di conseguenza ….

… forti di queste esperienze, possiamo anche ipotizzare che ci siano anche altri possibili utilizzi delle board, anche non proprio relative alla metodologia Agile.

Stato di fatto – Fotografia – Snapshot

Un utilizzo che possiamo avere della Agile Board è quello di tracciare in generale lo stato di fatto. Allo stesso modo usato negli altri esempi. Un altro esempio riguarda il post che ho dedicato alla recensione dell’addon del Kanoah CRM, dove gli autori dell’addon hanno praticamente utilizzato una board per tracciare l’andamento degli affari.

Altri utilizzi?

Lasciamo che sia la nostra fantasia a trovare altri usi :-). Possiamo anche ipotizzare che sia gestita anche per gestire i percorsi di carriera del personale di una azienda. In questo caso, le issue sono utilzzate per rappresentare il dipendente, con tutte le sue informazioni, mentre gli stati del workflow sono i gradi di avanzamento di carriera/assegnazione incarichi e chi più ne ha ne metta, sfruttando anche la potenzialità di Confluence 🙂

Un altro esempio potrebbe essere la gestione di un parco macchine di una azienda. Le issue possono essere utilizzate per rappresentare le automobili, mentre gli utenti di JIRA sono il personale che ottiene in gestione l’auto…. ma questo è solo un possibile applicazione di un utilizzo un pò più generico: ovvero gestire la assegnazione di risorse e, utilizzando anche un altro addon che abbiamo censito, per rintracciarlo a livello geografico.

Ma la board è legata ad un solo progetto?

Fondamentalmente le Board sono legate ad un progetto, anche se possiamo sfruttarle per andare a leggere le informazioni anche da issue appartenenti a diversi progetti. Occorre però tenere presente alcune piccole accortezze per arrivare a gestirle al meglio.

1. Possiamo selezionare le issues che vogliamo, basta semplicemente impostare la JQL di cui si vuole
2. Occorre prestare attenzione: se il filtro JQL non presenta il campo project , allora la Board potrebbe non risultare associata al progetto o fruibile dalla Dashboard del progetto, come mostrato nella immagine successiva
3. Se vogliamo sfruttare le potenzialità della board di modificare lo stato delle issue, accertiamoci che le issue dei progetti selezionati presentino lo stesso workflow, che presentino gli stessi stati e che la Board sia configurata in maniera tale da telere conto degli stessi stati, ovvero quali stati e quale colonna etc. Se presentano WF differenti, potremmo non avere il comportamento che ci aspettiamo 🙂

Conclusioni

Abbiamo fatto una semplice digressione sull’argomento. Questo è sicuramente uno punto di partenza per altri ragionamenti che porterà sicuramente a conclusioni interessanti.

Creiamo una Knowledge Base con JIRA Service Desk

In questo post andremo ad esaminare un sistema per poter gestire la Knowledge base su JIRA Service Desk, ovvero mettere a disposizione dei nostri clienti una libreria in cui sono specificate tutte le risoluzione alle varie problematiche, permettendo di poter risolverle in autonomia.

Di cosa abbiamo bisogno?

Come prima cosa dobbiamo disporre di Confluence nella nostra installazione, come mostrato anche dalla seguente figura:

Per realizzare questa funzionalità, JIRA Service Desk si appoggia ad uno Space di Confluence, dove si costruiscono, attraverso opportune procedure, le pagine della KB. Se Confluence non è disponibile o non è stato opportunamente collegato con il sistema, questa è la schermata che JIRA Service Desk visualizza per avvisare della situazione:

Impostando l’opzione Link to a Confluence space, la prima cosa che si nota è la presenta su portal della barra di ricerca, come mostrato in figura.

Questa è la barra di ricerca che l’utente utilizza per procurarsi la eventuale risoluzione del problema che ha riscontrato.

Come avviene la generazione?

Per generare le varie KB, ABbiamo a disposizione una apposita funzionalità, presente nella default view della issue, come mostrato in figura:

Gli agenti possono quindi, se non ci sono articoli già presenti e se si tratta di problematiche che si possono ripresentare, creare i KB per consentire agli utenti di cercarsi le soluzioni. Abbiamo solo da scegliere il template da usare per creare l’articolo su Confluence 🙂

Conclusioni

Abbiamo visto un semplice tutorial che ci mette a disposizione una buona funzionalità per JIRA Service Desk.

Reference

Suggerisco anche il seguente articolo del blog ufficiale Atlassian, dove sono fornite ulteriori informazioni.

Anno nuovo, novità sempre in pista

In questo post andremo ad esaminare le ultime novità si JIRA Portfolio.

Compare target and actual delivery dates

Viene data la possibilità di fissare delle Target Start Date e Target End Date, rappresentate come delle barre azzurre, come si può vedere nella figura sottostante,

Questa caratteristica può essere di aiuto:

• quando hai delle pianificazioni da fare ma non si dispone di tutti i dettagli e si vuole avere almeno una idea di come impatta+
• per dare un punto di riferimento e capire dove e quando allocare delle risorse per un determinato progetto.

Compare multiple scenarios

Con questa nuova funzionalità viene data la possibilità di poter generare degli scenari possibili e di poterli confrontare, oltre che marcare con opportune etichette e avere così diversi quadroi della situazione, com emostrato dalla seguyente immagine.

Compare story point estimates

Con Portfolio è possibile realizzare una stima a lungo termine della Velocity del gruppo di lavoro. E’ possibile dare una prima stima iniziale e poi eseguire tutti gli aggiustamenti del caso avendo sempre sotto controllo la stima iniziale. Questo aiuta sicuramente nella messa in opera di un gruppo di lavoro.

Conclusioni

JIRA Portfolio si conferma sempre una fonte di soprese e di innovazioni. Rimaniamo in attesa delle prossime novità

Reference

Maggiori informaizoni sono presenti nel post del blog Atlassian.

Risorse per i prodotti Atlassian

In questo post andremo ad elencare alcune risorse disponibili per il mondo Atlassian, siano essi applicativi, documentazione, libri, ebook, etc.

Libro su Amministrazione di JIRA

Segnaliamo questo libro (in inglese) su JIRA. Si tratta di : JIRA Strategy Admin Workbook, di Rachel Wright.

Il libro contiene :

• 152 raccomandazioni per aiutare i JIRA Administrator a settare, mantenere pulito ed efficiente JIRA;
• 33 esempi reali di problemi da evitare,
• Best Practices, cose da fare e da non fare per ogni area di amministrazione
• Tanti e tanti altri esempi e consigli sulla amministrazione di JIRA.

Più che di documentazione, l’obbiettivo del libro è quello di essere un compendio di suggerimenti e consigli pratici che permettono ad ogni amministratore di arrivare a gestire al meglio JIRA :-), come indicato dalla stessa autrice :

The JIRA Strategy Admin Workbook will save you time, money and frustration.

This book is different – it’s not documentation.  It’s recommendations from years of cleaning up horrible JIRA configurations!  It’s about what you should do, what you shouldn’t do, and why.

Maggiori informazioni sono reperibili consultando il seguente link. Attendo commenti 🙂

eBook gratuito su XRay – Test su JIRA

Segnalo anche questo ebook sui test in JIRA, della Xpand IT, dedicato al mondo dei Test con JIRA. Abbiamo già ampiamente dedicato molti articoli del blog a tale argomento, presentando diversi  addon, quali Kanoah Tests e XRay, della stessa Xpand IT.

Adesso la XPand IT propone un ebook dedicato, riportando la loro esperienza in materia e cercando di metterla a disposizione degli utenti JIRA. Maggiori informazioni sono presenti in questo link.

Ultimo ma non ultimo

Segnaliamo anche una risorsa su di un argomento molto importante: DevOps. Si tratta di un libro sull’argomento, presente nel blog della Atlassian, in cui si evidenzia un caso di uso di DevOps e di come costruire un team di DevOps 🙂 e dove si viene anche rimandato ad un altro blog post, sempre della Atlassian, dove si spiega il perchè viene utilizzato DevOps.

L’ebook, in inglese, può essere scaricato al seguente indirizzo del blog della Atlassian.

Conclusioni

In questo post abbiamo fornito un ulteriore elenco di risorse a disposizione dei prodotti Atlassian e delle moetodologie che mette a disposizione. Seguiranno ulteriori post. 🙂

Kanban, Scrum, Scrumban, …

In questo post andremo a proseguire l’esplorazione sulla metodologia AGILE, concludendo l’introduzione di questo argomento.

Definizioni preliminari

Per alcune definizioni preliminari, vi rimando al seguente link del sito Agileway.it, dove ho trovato delle indicazioni molto ben fatte.

Kanban

Per spiegare in cosa consiste Kanban, sfruttiuamo A brief introduction to kanban, di Dan Radigan, dove il lettore viene indirizzato in un percorso abbastanza chiaro e semplice (Si tratta di un articolo in inglese, ma stiamo lavorando per rendere disponibile queste documentazioni in italiano). Cercheremo di dare una spiegazione il più semplice, ma anche il più chiaro possibile.

L’approccio Kanban bene si adatta a quelle situazioni in cui si hanno sempre delle attività continue da svolgere.

Il Product Owner scompone il lavoro in tanti piccoli task, più o meno complessi, modificando l’ordine degli stessi e inserendo in cima quelli con maggiore priorità. In questo modo è sempre possibile rischedulare il lavoro del team senza dover bloccare il lavoro del team.

Il Team di sviluppo verifica i task da eseguire, seleziona quello in cima al backlog e lo porta a compimento. Quando lo seleziona, lo sposta dalla colonna To Do alla colonna Doing. Quando lo completa, lo sposta nella colonna Done.

Quando si ha a disposizione un insieme di task completati, si procede con un rilascio del nuovo software.

Questo approccio è molto più indicato nella manutenzione che nello sviluppo di nuove applicazioni.

Scrum

A differenza della precedente, la Scrum ben si adatta allo sviluppo di un nuovo progetto. Andiamo a capire meglio:

Scrum struttura il proprio sviluppo in cicli chiamati Sprint che durano da una a quattro settimane, al termine dei quali il team di sviluppo rilascia funzionalità immediatamente testabili.

In Scrum non abbiamo una figura di Project manager che coordina il team, ma possiamo dire che il team stesso è in qualche modo auto-organizzato. Tutte le competenze per la realizzazione del progetto sono presenti in tutti i membri del team stesso. Con questo non voglio dire che il project manager non esiste in tali organizzazioni, fa solo qualcosa di differente.

Prima di iniziare i lavori, il team si riunisce e definisce i task che saranno sviluppati definendo una Sprint. Nel definirli si impegna a completarli entro la fine della stessa. Una volta definiti, questi task sono inseriti nel backlog e si iniziano i lavori.

Ogni giorno il team si confronta nello Stand-up Meeting, che deve durare non più di 15 minuti, dove deve emergere lo stato di avanzamento, problemi e criticità. Obbiettivo è di identificare subito ciò che può bloccare il lavoro del team e rimuoverlo in modo da consentire il normale svolgimento delle attività.

Al termine della sprint si rilascia ciò che è stato completato, mettendo a disposizione una funzionalità completa e testata, testabile a sua volta dal cliente.

Scrumban

Si tratta di una composizione delle due tecniche, un cui abbiamo l’unione di quanto di meglio abbiamo dai due approcci precedentemente indicati. Ho trovato, facendo delle ricerche, il seguente link per una bella immagine che descrive abbastanza bene visivamente che cosa è Scrumban, che mi sembra molto chiara e precisa. Maggiori dettagli li ho identificati qui (in inglese).

Scrumban mette insieme l’interazione continua di Kanban, aggiungendo una limitazione agli slot di task che devono essere eseguiti contemporaneamente.  In Scrumban, il gruppo di lavoro è organizzato in piccole interazioni e monitorato attraverso una board similare a Scrum e Kanban.

Si lavora solo su di un sottoinsieme di user story, che vengono scelte attraverso dei planning meeting, che hanno l’obbiettivo di predisporre delle vere e proprie Sprint. Per tenere le interazioni molto basse, Il WIP (Work in Progress) di ogni stato.

Kanban Vs Scrumban

La seguente immagine riassume le differenze tra Kanban e Scrumban.

Scrum Vs Scrumban

La seguente immagine riassume le differenze tra Scrum a Scrumban:

Conclusioni

In questo post abbiamo concluso l’introduzione alla programmazione Agile. Spero di aver fornito le basi per poter iniziare ad approfondire questi nuovi argomenti o quanto meno di aver introdotto degli argomenti interessanti.

Nei prossimi post iniziamo a calare questi concetti su JIRA SOFTWARE, verificando che cosa sia possibile realizzare e come.

Ringraziamenti

Ringraziamenti per l’aiuto a Michael Forni, che è stato un valido supporto ed aiuto nella redazione di questi articoli. Di seguito i suoi contatti:

• Twitter: @MichaelForni
• Linkedin: www.linkedin.com/in/michaelforni
• Email: michaelforni@gmail.com

Citazione

Alcune immagini ed indicazioni sono prese dal sito AgileWay.it e da altre fonti (che cito di seguito), dove ho trovato indicazioni molto utili. Lo cito con piacere e ne suggerisco la lettura dei vari articoli: ritengo siano una fonte molto importante di informazioni in italiano. Altre immagini e riferimenti sono stati presi dai seguenti siti, quali:

• kanbantool.com – per l’immagine che mette a disposizione per descrivere Scrumban e per le immagini
• www.solutionsiq.com – per le immagini di confronto tra Kanban e Scrumban e tra Scrum a Scrumban.

Ultime novità

In questo post andiamo ad esaminare e dettagliare le ultime novità sulla versione 7.3 di JIRA, verificando quali sono le novità sia per la versione CORE che per la versione Server.

Uno alla volta …

Molte sono le novità. Cerchiamo quindi di andare con ordine 🙂

Rich text editing

Novità introdotta in versione LAB che consentiva di poter ovviare alla editazione vera e propria via wiki markup. Adesso è possibile, installando la versione 7.3, poter eseguire l’editazione direttamente attraverso il Rich Text editing.

Privilegi di modifica di un Workflow

Viene concessa, agli amministratori di progetto, la possibilità di poter eseguire la modifica del workflow, a condizione che siano rispettate le seguenti condizioni:

• Il workflow non deve essere condiviso tra più progetti
• Il workflow in questione non deve essere quello di default di JIRA

Occorre tenere presente che nell’istante in cui viene eseguito l’aggiornamento alla versione 7.3, tutti gli amministratori di progetto saranno in grado di eseguire l’aggiornamento del workflow, come mostrato nella figura precedente.

Starting a JIRA instance

Abbiamo anche delle novità per la parte sistemistica di JIRA. Sono state aggiunte due nuove caratteristiche inerenti  starting JIRA:

1. E’ stato aggiunto un passo extra nella fase di installazione/upgrade di versione di JIRA, nel quale viene richiesto di far ripartire JIRA esplicitamente.
2. Viene offerta la possibilità di far partire JIRA manualmente con tutti gli addon di sistema disabilitati

1. Installing and upgrading start up

Questa operazione è stata implementata in quanrto necessaria nel caso di installazione sotto Amazon Web Services (AWS) . Di seguito una  Quick Start guide che utilizza CloudFormation templates  per permetterti di eseguire il deploy delle versioni Data Center  in ambiente AWS.

2. Disable non-system add-ons

Attraverso nuove opzioni, possiamo eseguire lo start del nostro server JIRA in cui tutti gli addon installati (non quelli di sistema) sono disabilitati. In particolare:

1. --disable-all-addons (or /disablealladdons for Windows users)

2. --disable-addons=<addon keys> or (/disableaddons=<addon keys> for Windows users)

Questa caratteristica è molto utile, sopratutto quando dobbiamo eseguire degli upgrade e non vogliamo che le versioni installate degli addon faccianmo fallire lo start del servizio. In questo caso, riusciamo a far partire l’istanza e, successivamente, riusciamo ad eseguire la rimozione dell’addon incriminato in maniera semplice e veloce.

Conclusione

Abbiamo un pò di novità con questo rilascio. Continueremo a seguire tutte le variazioni e cercheremo di pubblicare costantemente tutte le ultime news.

Reference

Maggiori dettagli sono presenti sulla pagina di release notes di JIRA CORE e sul seguente articolo del blog Atlassian.

Una nuova esplorazione

Con questo post iniziamo una nuova esplorazione nel mondo dei Wiki. Affrontiamo uno dei problemi maggiori nel campo: Come andiamo a redigere una documentazione che abbia un senso e che permetta, un domani, di essere  condivisibile e permetta agli utenti di avere a disposizione un percorso di lettura valido, sensato e coerente.

Da cosa partire

Avere le idee chiare

La prima cosa che occorre fare è sicuramente cercare di classificare tutte le informazioni e gli utenti che andranno a referenziarle. In questo modo abbiamo riusciamo ad avere una prima indicazione di come classificare le informazioni, in quali SPACE andare a inserirle, se abbiamo bisogno di collegare delle informazioni, etc etc etc

Questo ovviamente è solo l’inizio. Occorre studiare bene questa prima parte, per un motivo molto semplice: Inserire delle informazioni a caso su di un Wiki non ha praticamente senso. Faccio un esempio molto semplice: Se si inseriscono delle pagine a caso e queste non sono collegate tra di loro (aggiungo anche: collegate in maniera opportuna, ma nella maniera più improbabile), questo significa che abbiamo solo un caos semi-disorganizzato, che non ci aiuta minimamente nel reperire le info. Passeremo le nostre giornate a ricercare le informazioni. Lo strumento non ci aiuterà in nessun modo 🙁 e la prima reazione sarà quella di copiare le informazioni in locale sul nostro PC/tablet.

Fate sempre ordine

Occorre studiare come inserire le informazioni e come organizzarle, classificarle, collegarle. Questo ultimo punto è sicuramente il più importante in quanto anche delle belle pagine chiare e illuminanti non hanno alcun senso se non sono collegate tra di loro. Occorre mettersi in testa che l’utente non deve fare la caccia al tesoro per reperire le informazioni.

Non seguire le mode…

Molto spesso si commette l’errore che basti introdurre lo strumento in azienda o semplicemente adottarlo per risolvere tutti i problemi di documentazione, come avevo già indicato in questo post, in cui ho riportato una prima serie di considerazioni sulla documentazione su Wiki.

Se le informazioni sono collegate in maniera tale da creare dei percorsi di lettura, quello che si ottiene è una documentazione valida.

Obbiettivo di questi post

Con questa nuova serie di post, ci prefiggiamo l’obbiettivo di fornire una serie di consigli per gli utenti, inteso più come un nuovo modo di ragionare e di organizzare le informazioni che porti gli utenti ad avere a disposizione una documentazione il più possibile fruibile ed utile.

Non intendo fornire tanto delle norme rigide ed immodificabili, ma quanto una serie di consigli e di punti di attenzione che possono aiutare nella redazione della documentazione e nell’organizzazione della stessa. La vera potenzialità dei prodotti Atlassian risiede proprio nel grado di libertà che si ha a disposizione 🙂

In conclusione

Chiudiamo qui questo post introduttivo. Abbiamo ripreso quanto avevo già indicato in altri post e cerchiamo di esploderlo nei prossimi post con esempi pratici, modalità di ragionamento e, importantissimo, uso corretto della testa 🙂

Atlassian on Mobile

In questo post andremo ad esaminare in che modo, i servizi e le funzionalità dei prodotti Atlassian , sono messi a disposizione attraverso applicativi Mobile o attraverso addon che permettono un moglioramento del layout mobile. Continueremo ad approfondire il discorso con degli ulteriori articoli.

Cosa abbiamo a disposizione oggi?

Iniziamo la nostra esplorazione navigando nel marketplace e cercando di capire cosa oggi è a disposizione degli utenti Atlassian :-), partendo dai nostri precedenti articoli dedicati a JIRA Mobile e Confluence Mobile, che permettono di portare sui nostri dispositivi tutte le funzionalità JIRA e Confluence nei nostri dispositivi, permettendo di avere sempre a disposizione tutte le informazioni che servono (anche se al momento si tratta delle sole istanze cloud).

e ci permette anche di sfruttare al meglio anche gli addon principali di Confluence: Questions e Team Calendar.

Continuiamo la nostra carrellata di applicativi partendo da Pocket Desk Connector for Service Desk, un applicativo mobile (al momento in cui viene redatto il blog post, abbiamo a disposizione la versione iOS), che permette di poter andare a monitorare le nostre issue JIRA Service Desk, slegandoci dal fatto di avere un pc sempre a disposizione 🙂 …..

… e mettendo a disposizione tutte le funzionalità di cui necessitiamo, senza alcuna mancanza della versione web da PC. Possiamo verificare le nostre code e le singole segnalazioni aperte e andare a monitorarne la lavorazione oppure procedere alla lavorazione delle stesse….

…. il tutto senza rinunciare alle innovazioni che i nostri smartphone mettono a disposizione. Abbiamo a disposizione anche le notifiche push, cui siamo abituati, per ricevere le varie segnalazioni.

Passiamo alla prossima applicazione mobile: Tempo Mobile App for JIRA , ovvero la versione mobile di TEMPO per JIRA. Disponibile sia per la versione cloud che per la versione server, questa app mobile mette a disposizione una interfaccia semplice ed intuitiva, permettendo di avere a disposizione TEMPO anche sul nostro cellulare senza togliere alcuna delle funzioni base di cui abbiamo bisogno.

Sono inoltre messe a disposizione una serie di funzionalità non indifferenti, come ad esempio la possibilità di convertire gli eventi del calendario in worklogs, il tutto farcito con una buona integrazione con google calendar e Office 365.

Proseguiamo l’esplorazione con Mobile Themer for Confluence, ovvero un addon per Confluence Server che permette, andando al sodo, di poter personalizzare meglio l’interfaccia Mobile che Confluence Server mette già a disposizione.

Lo stesso logo viene riportato nel layout, cosa che il layout mobile al momento non permette. Questo addon mette a disposizione

Conclusioni

Abbiamo concluso questa prima occhiata su cosa viene messo a disposizione lato mobile su Atlassian. Nei prossimi post andremo ad approfondire l’utilizzo di queste app per capirne vantaggi/svantaggi/limiti/opportunità/etc etc :-). Stay tuned.

Approvazione documenti per Confluence Cloud

In questo post andremo a vedere come possiamo introdurre la funzione di approvazione documenti sulla nostra istanza cloud di Confluence, attraverso un opportuno addon.

Di quale addon abbiamo bisogno?

Si tratta del Comala Approvals for Confluence Cloud, un addon per Cloud che permette di poter inserire tale funzionalità 🙂

Abbiamo la possibilità di aggiungere un workflow di approvazione all’interno dei nostri documenti, prima della visualizzazione effettiva. Come per la versione server, aggiungiamo un workflow al nostro Confluence.

Come mostrato dalla precedente figura, possiamo aggiungere dei reviewer al nostro documento, permettendo così un controllo pre-pubblicazione dello stesso.

Una dashboard evoluta ci condente di avere sempre la situazione sotto controllo e verificare chi deve fare cosa.

Sfruttando le integrazioni con HipChat, abbiamo la possibilità di essere avvisati non solo con il sistema di messaggistica di Confluence, ma anche con lo stesso HipChat. Cosa non da poco 🙂

Conclusioni

Abbiamo dato una prima occhiata a questo addon, che ci mette a disposizione una serie di indicazioni su come possiamo introdurre un workflow di approvazione per le nostre istanze cloud di Confluence. Nei prossimi post andremo a collaudare questo addon per saggiarne le potenzialità.

Reference

Maggiori informazioni sono reperibili dal seguente filmato Youtube:

mentre le informazioni sull’addon sono presenti sulla seguente pagina del Marketplace della Atlassian.