Prova addon

In questo post andremlo a visionare la prova dell’addon di importazione/esportazione dei template di Confluence, che abbiamo presentato qualche giorno fa.

Installazione

Partiamo come sempre dalla installazione dell’addon. Andiamo a cercare il nostro addon dalla sezione di amministrazione, come mostrato dalla seguente figura:

La prima cosa che notiamo è che l’addon è gratuito (al momento in cui viene redatto il post). Procediamo quindi con l’installazione, selezionando il tasto Install.

Viene prima eseguito in automatico il download dell’addon, senza che dobbiamo preoccuparci che sia la versione corretta, dato che le procedure stesse si preoccupano di eseguire questo controllo 🙂 ….

… terminato il download, si procede con la installazione vera e propria. ….

… che termina con il messaggio di addon pronto all’uso. Questo addon è gratuito e non abbiamo bisogno di ulteriori fasi. Selezionando Close veniamo rediretti alla pagina seguente:

che ci permette di accedere alla pagina di gestione/configurazione dell’addon

Configurazione

Selezionando manage veniamo reditretti alla seguente pagina:

che ci dice una cosa importante: Non abbiamo una configurazione da gestire 😀

TEST TEST TEST TEST TEST

Senza indugio andiamo a testare questo addon e vediamo che cosa ci consente di fare :-). Come prima cosa ci posizioniamo nella gestione dei temnplate del nostro space di esempio:

Creando dei template id test, con dei nomi di fantasia molto importanti (:-P) vediamo che ci viene proposto un nuovo menù che comprende anche la funzioen export. Se andiamo a vedere la visualizzazione pre-installazione dell’addon:

Se andiamo a testare questa nuova funzionalità, quello che otteniamo è un file XML, che presenta il contenuto del template, come possiamo vedere dalla seguente immagine:

Quello che vien efatto è di estrarre il codice che compone il nostro template e poter così creare la nostra libreria di template 🙂

Conclusioni

Abbiamo un addon che ci semplifica un bel po la vita. Riusciamo ad estrarre il contenuto delle pagine template, senza dover andare a leggere il database e senza dover fare troppi sforzi. In questo modo possiamo eseguire questa operazione senza alcuna fatica.

Reference

Maggiori informazioni sono presenti nella pagina del marketplace della Atlassian.

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.

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 🙂

Mostriamo le potenzialità

In questo post andremo ad introdurre un possibile utilizzo di JIRA CORE. Vediamo come sia possibile arrivare a gestire un sistema di fatturazione, verificando tutte le fasi ed arrivando a documentare il tutto in maniera completa. SI tratta di un possibile scenario di come possiamo sfruttare le potenzialità di questi prodotti e di altri collegabili 🙂

Di cosa abbiamo bisogno?

Per la realizzazione di questa idea abbiamo bisogno di:

• JIRA CORE, dove andremo a sfruttare le potenzialità che esso mette a disposizione per realizzare il nostro workflow e andremo ad implementare la gestione delle fatture.
• Confluence, che sfrutteremo come repository di documenti e che useremo anche per visualizzare le fatture del cliente.

Non abbiamo bisogno di altro, per implementare le funzioni base, salvo poi integrare con vari addon in base ad esigenze particolari.

Come realizziamo il tutto?

Su JIRA CORE (ma possiamo anche sfruttare le altre pacchettizzazioni, se le abbiamo a disposizione) andiamo ad implementare una serie di configurazioni, come mostrato in questo post dove andiamo a spiegare come realizzare un asset management, in cui impostiamo:

• un progetto dedicato alla creazione di issue, in cui ogni issue rappresenterà una fattura e presenterà delle caratteristiche tali da poter identificare in maniera semplice tutte le informazioni della fattura
• Campi custom, che andranno a descrivere tutte le caratteristiche di una fattura, quali importo, IVA, ritenuta, descrizione, allegato (ovvero il PDF della fattura generata), etc.
• Issue Type, che ci permette di identificare meglio le fatture, le note di credito, storni, etc.
• Workflow, ad uso specifico del progetto, che descrive quali stati assume la fattura, quali ad esempio: Creata, approvata, cancellata, emessa, in attesa di pagamento, non pagata, in mora, in recupero credito; etc. (NB: Ho indicato gli stati in italiano, ma è possibile impostare gli stati come ci risulta più comodo)
• Vari Scheme: Notification, permission, etc; per permettere la visualizzazione e la relativa autorizzazione della stessa.

Come usiamo Confluence?

In questo caso, possiamo sfruttare Confluence per documentare le fatture come in questa ipotesi 🙂

• Possiamo creare la documentazione dei vari clienti/fornitori sfruttando l’organizzazione degli space. Ad esempio possiamo pensare di creare uno space per i clienti ed uno space per i fornitori. Oppure possiamo creare uno space unico dove memorizziamo tutto. Abbiamo la libertà totale.
• Come sottopagine, possiamo generare delle pagine di anagrafica del cliente/fornitore. In questo modo sfruttiamo la libertà che Confluence ci mette a disposizione nell’impostare le informazioni come risulta più comodo
• Attraverso l’uso di page properties, possiamo sfruttare opportune macro per rissumere i dati sulle Home page degli space e da li andarle poi a referenziare 🙂
• Colleghiamo le issue alle pagine attraverso la JIRA Issue macro o macro simili, ovvero eseguendo delle interrogazioni su JIRA direttamente da Confluence. In questo modo colleghiamo le issue-fatture alle pagine Confluence e possiamo seguire l’andamento in tempo reale.

In questo modo riusciamo a sfruttare le potenzialità di Confluence, di essere punto centrale ed unico delle informazioni, con la potenza di JIRA e dei suoi Workflow di controllo.  Tutto va al suo posto 🙂

In aggiunta, sfruttando queste potenzialità e il legame esistente tra Confluence e JIRA, possiamo anche realizzare delle Dashboard su Confluence, ad uso dei vari team di lavoro, che riassumono lo stato di fatto. Ad esempio, si può realizzare uno space che mostra agli addetti dell’ufficio legate quali sono le fatture che sono scadute e non sono pagate, in modo da consentire loro di poter interventire e capire che cosa è successo.

Il marketing può intervenire in modo da fornire uno sconto per incentivare i clienti che comprano troppo poco o i migliori clienti. In questo caso, sempre sfruttando Confluence e le sue capacità, si può costruire una Dashboard che mostra chi solo i clienti che spendono sotto una certa soglia o sopra una determinata soglia e, in base ai risultati, agire di conseguenza contattando direttamente il cliente e proponendo promozioni.

Conclusioni

In questo post abbiamo esaminato una possibile ipotesi di come possiamo sfruttare i prodotti della Atlassian per realizzare una determinata funzione aziendale, facendo notare quale che sia il grado di libertà che mettono a disposizione, sia come questi strumenti consentono di poter realizzare il tutto: La fantasia è il solo unico limite.

News interessanti

In questo post andiamo a vedere una news riguardante un addon molto interessante, che abbiamo avuto il piacere di esaminare di recente. Vediamo quali nocità in merito

Andiamo al dunque

Andando ad esaminare il codice sorgente di una pagina, relativa alla mia installazione cloud di lavoro, mi sono accorto di una piccola novità molto interessante:

Come si può notare dalla figura, rispetto al precedente articolo, sono state aggiunte alcune funzionalità:

• Find/Replace, importantissima. In questo modo possiamo ricercare dei TAG e dei pattern di stringhe in maniera molto semplice.
• Beautify, che consente di poter dare una …. forma al codice che, come si vede nella precedente immagine è molto piatta, mentre nella seguente immagine risulta meglio leggibile ed interpretabile: 
• Preview, ovvero verificare il risultato della modifica prima di salvare, operazione prima non prevista ed altrettanto importante ed interessante.

Conclusioni

Abbiamo delle piccole modifiche che rendono questo addon unico, indispensabile per la vita di tutti i giorni. Rimaniamo in attesa delle prossime novità.

Task ricorrenti su JIRA Cloud

In questo post andiamo a provare questo prodotto, cercando di capire limiti, vantaggi e svantaggi che sono messi a disposizione.

Installazione

Partiamo come sempre dalle procedure di installazione. Dato che si tratta di una procedura su Cloud, abbiamo delle piccole differenze rispetto ad una installazione server, ma la procedura generale è la medesima.

La prima cosa è ricercare l’addon nella lista dei possibili addon e successivamente selezioniamo Trial, per iniziare la procedura di installazione…

… accettiamo i termini di licenza e procediamo con l’installazione ….

… attendiamo che l’addon sia scaricato ed installato nella nostra istanza ….

… operazione tutta automatizzata …

… fase successiva, diversa dalla procedura di installazione lato server, di sottoscrizione dell’addon ….

… che una volta terminata ci mette a disposizione il nostro addon 🙂

Configurazione

Passiamo alla fase di configurazione dell’addon, sempre molto importante: se non lo configuriamo correttamente, possiamo avere dei comportamenti anomali che ci possono far pensare che l’addon non è all’altezza e così…. sprecare una possibilità, e non vogliamo che ciò accada.

Come mostrato dalla seguente figura:

non abbiamo una pagina di configurazione vera e propria se non quella di gestione e creazione dei template di task. Da questa pagina emerge anche quanto segue:

• Ogni 30 minuti lo schedulatore si attiva per gestire i vari processi;
• Se una schedulazione è prevista per le 5.20 AM, il task sarà creato alle 5.30 AM.

Test addon ed ancora test

Procediamo con il test: creamo il nostro task ricorrente e vediamo come procedere. La creazione è molto semplice. Come mostrato nella figura precedente, selezioniamo Add Recurring Task per attivare il wizard di generazione:

La prima cosa che ci viene chiesta è il progetto dove eseguire la generazione, come mostrato nella precedente figura…

… e successivamente viene chiesto quale issue type associare. Molto importante: In base all’issue type abbiamo poi quale lavorazione sarà eseguita. Fatto ciò, come mostrato dalle seguenti figure, andiamo a configurare i parametri del nuovo task che sarà creato, ovvero:

• Nome del template
• Ogni quanto tenmpo ripetere la schedulazione
• Titolo da assegnare alla Issue, descrizione, etc.

Una precisazione. Avrete notato che sono presenti dei campi che presentano la scrittaUnsupported…. Questi campi non sono al momento utilizzabili. Se qualcuno di questi ci è necessario, occorre capire se e come poter sfruttarne di altri o come poter, attraverso delle operazioni di post function del workflow, andarli a compilare.

Quanto la generazione è terminata, questo è il risultato:

Notiamo che abbiamo a disposizione delle funzionalità aggiuntive sul template e che possiamo:

• modificarlo
• eseguirlo adesso
• disabilitarlo, qualora non sia temporaneamente necessario
• rimuoverlo, qualora non più necessario

Se andiamo ad eseguirlo, per vedere come avviene la cancellazione, come mostrato dalla figura siccessiva:

vediamo che il task viene generato e la seguente figura è il risultato di tale operazione:

Conclusioni

Abbiamo visto come funziona questo addon. Si aprono un ventaglio di possibili utilizzi di questo addon. Lasciatevi guidare dalla vostra fantasia.

Task ricorrenti su JIRA Cloud

In questo post andiamo a dare una prima occhiata a questo prodotto, cercando di capire che cosa è possibile fare e cosa possiamo implementare.

Che funzioni sono messe a disposizione?

Never forget about your recurring tasks. Schedule issue creation and enjoy automatically created items

Questo è quanto riporta la pagina del marketplace dedicata all’addon. In sostanza, questo addon permette di generare dei task ricorrenti nella nostra istanza JIRA, quali la generazione schedulata di issue che devono essere eseguite in maniera sistematica  e ricorrente.

L’interfaccia, come mostrato nella precedente immagine, è molto semplice e intuitiva. Abbiamo subito una lista di template, che possiamo creare per generare le nostre issue ricorrenti.

Abbiamo a disposizione indicazione degli ultimi errori riscontrati, come mostrato dalla precedente figura

La maschera di creazione di un task è molto simile a quella utilizzata per poter generare una issue. Non è quindi necessaria una preparazione di chissa quale genere per poter creare un task ricorrente

Possiamo anche eseguire quando vogliamo il task, sia quando lo collaudiamo sia quando necessitiamo 🙂

Conclusioni

Questo addon mette a disposizione delle nostre istance cloud, la possibilità di poter schedulare delle attivirà ricorrenti in maniera semplice. Questo non fa altro che scatenare la nostra fantasia nell’uso di questo nuovo addon 😀

Reference

Maggiori informazioni sono presenti nella pagina del marketplace.

Versione Cloud

In questo post riprendiamo quanto abbiamo già pubblicato su Draw.io per versione Server, ed andiamo a eseguire un test anche per la versione cloud del prodotto.

Che funzionalità sono garantite?

Da una analisi della pagina del Marketplace, vediamo che sono garantite le medesime funzionalità della versione Server, con le stesse potenzialità e modalità di uso.

L’unica differenza, al momento riscontrata, è che questo addon è gratuito (Al momento in cui viene redatto il post per la prima volta). Direi che questo fa la differenza :-).

Installazione cloud

Per l’installazione dell’addon procediamo come siamo sempre abituati: Utilizziando la procedura guidata andiamo a cercare il nostro addon e selezioniamo Install:

Accettiamo le condizioni di licenza e procediamo con l’installazione vera e propria….

… attendiamo che sia completata la fase di installazione …

Una volta completate le varie fasi, viene visualizzato il seguente messaggio:

… e siamo quindi pronti ad usare il nostro nuovo addon.

Configurazione

Se facciamo riferimento alla precedente immagine, possiamo vedere che è presente il tasto Manage, che ci consente di poter accedere alla sezione di configurazione, mostrata dalla seguente immagine:

e come possiamo vedere, non abbiamo alcuna schermata di configurazione da gestire. Procediamo quindi con il test.

Test test test…. test

Per utilizzare la funzionalità basta semplicemente andare in editazione di una pagina e inserire la nuova macro Draw.io Diagram, come mostrato in figura (l’autocomposizione ci da un aiutino).

Una volta che la macro è aggiunta, procediamo con l’editazione: Selezioniamo l’oggetto e successivamente selezioniamo Edit:

Siamo subito reindirizzati nella form di generazione del grafico. Possiamo a questo punto sbizzarrirci nel generare tutti i grafici che vogliamo :-). Abbiamo solo l’imbarazzo della scelta :-D:

Per il resto non abbiamo cambiamenti sulle varie funzioni inerenti al disegno.

Conclusioni

Abbiamo visto con estremo piacere come la SIBERT/MEDIA ha messo a disposizione delle istance cloud il suo addon anche per Confluence. Restiamo in attesa di nuovi interessanti sviluppi 🙂

Reference

Maggiori dettagli sono reperibili alla pagina del marketplace di Atlassian.

Test su strada

In questo post andremo a testare questo addon.

Installazione

Partiamo sempre dalla installazione dell’addon. Partiamo dalla sezione di gestione degli addon e andiamo ad eseguire la ricerca:

Selezioniamo Free Trial, per eseguire l’installazione nella nostra istanza cloud.

Accettiamo selezionando Accept & Install per proseguire l’installazione. A questo punto parte l’installazione….

… che procede al download ed install del prodotto ….

… al suo completamento ….

… procede con la licenza (Vi ricordate che la installazione per cloud presenta alcune differenze?) …

… esegue l’aggiornamento delle licenze ….

…. rendendo l’addon disponibile …

A Questo punto possiamo usare l’addon 🙂

Configurazione

Non è presente alcuna form di configurazione e possiamo subito utilizzare questo addon direttamente nelle pagine.

Senza indugio… test test test 😀

Procediamo con il test.  Aggiungiamo subito la macro sulle nostre pagine …

… in maniera molto semplice, dove riportiamo un esempio direttamente dalla manualistica dell’addon. Il risultato è il seguente.

Conclusioni

Abbiamo visto un esempio di come possiamo includere del codice HTML sotto la nostra istanza Cloud. Immaginate che cosa possiamo fare :-).

Tip & Tricks

In questo post andremo a vedere un piccolo esempio che ci può risultare molto utile quando dobbiamo provare i nostri sistemi ad inviare mail ma, al momento, non disponiamo di un server SMTP. Vediamo nel dettaglio

Nel dettaglio

Facciamo riferimento al seguente articolo della documentazione di Confluence, che ci aiuta nell’usare Gmail per eseguire l’invio delle mail.

Nel nostro caso occorre impostare, nella sezione di amministrazione di Confluence, ma possiamo anche riusare questi consigli su JIRA, come segue:

Sotto il menù ADMIN –> Mail Servers, impostare come nella figura sottostante:

Chiaramente occorre impostare una GMAIL da usare per l’invio delle email. Questa operazione non costa nulla, in soldini, e possiamo eseguirla senza problemi.

Conclusioni

Abbiamo visto come possiamo sfruttare, a nostro vantaggio GMAIL, per usarlo nell’invio delle mail attraverso Confluence. Ribadiamo che possiamo ottenere lo stesso risultato anche sotto JIRA. Questo tips è sicuramente utile nel caso di ambienti di test, per avere una simulazione il più reale possibile.

Reference

Cito nuovamente la pagina della documentazione, dove sono riportati maggiori dettagli (in inglese).