Conclusioni finali e considerazioni

In questo post completiamo quanto abbiamo iniziato nel nostro giro di esplorazione delle nuove versioni di JIRA. dove forniremo alcune considerazioni finali sull’argomento.

Considerazioni Finali

Nei vari post abbiamo visto i diversi aspetti dei tre prodotti. Siamo partiti dalla installazione e abbiamo eseguito dei confronti, cercando di capire diverse sfumature.

Su JIRA CORE abbiamo visto come possiamo sfruttare tutta la potenza dei Workflow anche  in situazioni che non riguardano necessariamente lo sviluppo software, ma anche in situazioni in cui si ha la necessità di dover monitorare un determinato percorso decisionale.

JIRA CORE raccoglie tutte le funzioni base di JIRA, su cui si basano le altre due pacchettizzazioni: SOFTWARE e SERVICE DESK.

Su JIRA SOFTWARE abbiamo visto come, sfruttando la BOARD AGILE, possiamo monitorare l’andamento del progetto e riusciamo facilmente a fare programmazione Agile.

Agevole reportistica ci fornisce un ulteriore aiuto.

JIRA SERVICE DESK diventa la soluzione per gestire un Service Desk in una azienda. Con questa pacchettizzazione abbiamo visto che possiamo sfruttare in pieno tutte le funzionalità di JIRA, ed abbiamo a disposizione anche un sito PORTAL per consentire ai nostri clienti di monitorare lo stato della situazione.

Conclusione

Concludiamo questo viaggio nelle nuove pacchettizzazioni di JIRA. Da quando sono usciti, lo scorso ottobre, si sono dimostrate sempre all’altezza della situazione. Restiamo in attesa delle ultime novità.

Analizziamo altri Addon per JIRA

In questo post andremo ad esaminare alcuni addon per JIRA. Continuiamo la nostra esplorazione in questa galassia alla esplorazione di nuove …. soprese.

Iniziamo l’esplorazione

Iniziamo la nostra esplorazione esaminando Create on Transition for JIRA, un addon che consente di creare delle Issue sfruttando delle post function del Workflow.

L’addon mette a disposizione una serie di post-functions che permettono di poter generare task e subtask in maniera molto semplice. Supponiamo ad esempio di trovarci in una situazione in cui, in un nostro progetto, se abbiamo una anomalia su di una componente del progetto, questa va ad impattare su di un’altra componente dello stesso. Questo ci consente di poter aprire direttamente questi task senza dover impazzire

Abbiamo una configurazione molto agevole che ci consente di poter gestire la creazione di subtask in maniera molto agevole.

Sicuramente un ottimo addon che ci permette di semplificarci la vita.

Proseguiamo il nostro viaggio esplorativo andando ad analizzare Jira Scripting Suite, ovvero un addon che permette di aggiungere script Python in JIRA per realizzare ulteriori estensioni di condizioni, post-funzioni e validatori di Workflow JIRA.

Attraverso un semplice editor, consente di poter eseguire l’editing degli script

Conclusioni

Ci fermiamo qui, ma nei prossimi post andremo ad eseguire ulteriori test su strada ed esplorazioni di nuovi componenti.

Novità di JIRA Service Desk

In questo post proseguiamo il giro di prova delle nuove versioni, dato dal rilascio di JIRA 7. Come per i precedenti post pubblicati, ovvero:

• JIRA CORE e seguenti
• JIRA Software e seguenti

e proseguiamo quanto iniziato nel post dedicato a JIRA Service Desk.

cercando di segnalare differenze, punti di attenzione e novità della nuova versione.

Test test test test test test

Partiamo dalla nostra versione installata di JIRA Service desk e cerchiamo di capire le differenze con le precedenti versioni installate 😀

La prima cosa che vedremo, alla installazione, è la seguente:

In questa schermata ci viene chiesto cosa vogliamo scegliere come sistema di Service Desk. In particolare ci viene chiesto quale possibile opzione di Service Desk si vuole impostare, per eseguire il proprio lavoro. Le possibilità sono:

• IT Service Desk
• Basic Service Desk

Queste due opzioni sono fondamentalmente delle autocomposizioni, che consentono di poter generare in auto-magico 😛 un progetto di Service desk. In questa guida cercheremo anche di capire come poter configurare da zero il tutto.

Se selezioniamo la prima opzione, il risultato che otteniamo è il seguente:

Vediamo quindi che abbiamo sempre e comunque JIRA Service Desk ci aiuta. Possiamo anche dire che non la vogliamo. In alto a destra della precedente immagine, vediamo un bellissimo Dismiss this guide. Il risultato che otteniamo è indicato nella seguente immagine:

ovvero della schermata della gestione del progetto. Come si può notare, abbiamo sempre un aiuto (come mostra la popup in alto a destra della immagine).

Una piccola precisazione

E’ bene fare questa precisazione. Per il Service Desk  abbiamo due tipologie di utenti:

• Agenti
• Utenti

Gli Utenti…. producono le segnalazioni. E’ il loro mestiere. :-D. Gli Agenti sono gli utenti JIRA che si occupano di gestire le segnalazioni e rendono la vita degli utenti… migliore :-D.

Ma esiste una buona notizia, che è sempre bene specificare. La LICENZA si paga solo per numero di AGENTI. Gli utenti possono essere INFINITI. 

Confrontiamo i prodotti

Le tipologie di progetti … aumentano, come possiamo vedere nella seguente immagine:

Abbiamo l’introduzione della tipologia Service Desk. Nella immagine precedente abbiamo a disposizione il progetto generato dalla autocomposizione, di tipo Service Desk. Questo conferma, quanto riportato nel precedente post (TO DO: INSERIRE LINK). Possiamo creare le seguenti tipologie di progetto.

Da quanto vediamo, possiamo creare gli stessi progetti di JIRA CORE e di JIRA SERVICE DESK, come mostrato nella figura seguente:

Infatti, se andiamo ad esaminare le applicazioni presenti, possiamo vedere che:

ovvero che è presente sia JIRA Service Desk che JIRA CORE. Abbiamo la conferma che JIRA CORE è la base su cui si appoggia il JIRA Service desk.

Utenti ed Agenti

Come possiamo vedere quanti Agenti e quanti Utenti abbiamo a disposizione? lo possiamo vedere anche sezione User Management. 

dove possiamo vedere due agenti e un utente JIRA, un utente di portale. Infatti, questo utente DEMO riesce solo ad accedere al portal, ma non ad altro. Anche se gli passiamo direttamente la URL per accedere ad una ISSUE, questa viene  subito reindirizzata alla URL del portal, come mostrato dalla seguente immagine.

e può vedere solo la form della issue per gli utenti:

mentre un agente riesce ad accedere alla issue nel dettaglio

Conclusioni

Concludiamo questa seconda parte. Nei prossimi post completeremo l’analisi di JIRA Service Desk.

Prova su strada #2

Proseguiamo la prova su strada. Nella prima parte abbiamo visto installazione e configurazione dell’addon. Passiamo adesso all’utilizzo.

Utilizzo addon

Vediamo come utilizzare questo addon. Nel post precedente abbiamo visto come installarlo e che cosa offre come configurazione. Passiamo all’utilizzo vero e proprio :-).

Come prima cosa, generiamo un progetto ad hoc, da usare come banco di prova e capire come su utilizza questo addon. Con molta fantasia, andiamo a chiamare il progetto Script Runner Demo 😛

Questo progetto presenta un Workflow molto semplice. A tale scopo, prima di proseguire, consigliamo la lettura del miei post, dedicati al Workflow ed alla loro spiegazione. Il nostro progetto di test presenta un workflow molto semplice, come mostrato in figura:

A questo punto, introduciamo lo scriptrunner. Supponiamo di voler eseguire una riassegnazione automatica della Issue, quando si apre nuovamente la stessa. Vediamo come configurarla. Selezioniamo la transazione che ci interessa:

Aggiungiamo una Post Functions. Selezioniamo Script Post-Function, come tipo di funzione, come mostrato in figura:

Confermiamo ed andiamo a selezionare il tipo di script che vogliamo attivare:

selezioniamo Assign to first member of role, andando avanti nel wizard ….

… selezionaimo il ruolo che ci interessa (nel nostro caso va benissimo anche Administrator). Selezioniamo Add, confermando a questo punto anche la nostra Post Function 🙂

Come mostrato dalla precedente immagine, abbiamo il tutto. Procediamo con una semplice demo. A tale scopo mi servirò di un semplice applicativo che registra delle GIF animate e che mostra il risultato 🙂

Come possiamo osservare, abbiamo che la Issue, in fase di riapertura, viene riassegnata nuovamente ad Administrator.

Conclusioni

Chiudiamo, con questo post, abbiamo visto qui come è possibile utilizzare lo Script Runner per poter gestire delle nuove situazioni e poter inserire delle funzioni aggiuntive, non presenti nello standard. Questo è, al momento, disponibile solo per le versioni SERVER di JIRA, ma non mettiamo mai limiti. Sono sicuro che la Adaptavist ci stupirà nel prossimo futuro 🙂

Ovviamente questo post non esaurisce l’argomento: Ci saranno ulteriori post con aggiornamenti.

Reference

• Marketplace ScriptRunner
• Manualistica Addon

Prova su strada

In questo post andremo a testare lo Script Runner. Sarà anche una piccola sorpresa: Andremo a provarlo su di una versione antecedente a JIRA 7 e, in una seconda fase andremo ad eseguire il collaudo anche su JIRA 7, per testare le potenzialità si entrambe le versioni e capire, laddove presenti, le differenze 🙂

Installiamo il prodotto

Come sempre, iniziamo dalla installazione dell’addon, sfruttando quanto la Atlassian ci mette a disposizione. Dalla sezione di amministrazione, andiamo a cercare l’addon, come mostrato un figura:

Quindi selezioniamo Free trial, per scaricare la versione trial dell’addon e …. testarla. Quindi, andiamo ad accettare i termini e la licenza utente, come richiesto dalla seguente immagine:

Una volta accettata la licenza, si procede con il download ….

… e con la fase di installazione dell’addon.

Una volta installato, viene richiesta la login per accedere al portale Atlassian, al fine di generare la licenza trial.

Una volta fornite tali credenziali, viene generata la licenza in automatico e…..

… come mostrato nella immagine successiva, abbiamo a disposizione il nostro addon per i nostri test 🙂

Configurazione

Il passo successivo consiste nell’esaminare le opzioni della configurazione:

che sono accessibili dalla opzione Addons , relativamente alla sezione di Amministrazione di JIRA.  Da qieste opzioni possiamo:

• accedere alla console di scrittura degli script, che possiamo scrivere direttamente  
  o come indicato nella figura successiva, possiamo anche caricate gli script da una apposita directory della JIRA_HOME directory
  
• Abbiamo a disposizione una libreria di script già pronti, che ci aiutano nel nostro primo impatto 🙂 dove possiamo anche andare ad eseguirli per renderci conto di come funzionano.
• Abbiamo a disposizione la possibilità di poter definire dei nuovi campi, utilizzabili negli script 
• Possiamo definire dei listener, al fine di eseguire delle operazioni particolari 
• Abbiamo a disposizione delle nuove funzioni da usare nel JQL 
• Possiamo definire dei nuovi REST-Endpoint 

Conclusioni

Ci fermiamo qui ma proseguiamo l’analisi nel prossimo post.

Esaminiamo JIRA Software

In questo post andiamo a completare il giro di prova su strada. Abbiamo già eseguito una installazione su di una nostra macchina virtuale. Andiamo quindi a completare l’opera.

Test test test test test test

Iniziamo, come prima cosa a collegarci sul nostro JIRA SOFTWARE e vedere che cosa ci offre subito :-). Eseguiamo la Login nella nostra installazione di prova:

Osserviamo subito che la dashboard è la medesima di JIRA CORE: non notiamo alcuna differenza.

Notiamo invece che possiamo selezionare due tipologie di progetti:

• Software, ovvero i progetti dedicati allo sviluppo di software;
• Business, ovvero i progetti non di sviluppo software (i medesimi di JIRA CORE).

Fondamentalmente, quello che possiamo fare è generare e gestire progetti come siamo abituati, avendo a disposizione, in questa installazione di JIRA, la Board Agile. Infatti, se creiamo un progetto ex-novo, quello che andiamo a vedere è:

a differenza di JIRA CORE, che prevede quanto segue:

Andiamo a gestire, oltre alle stesse tipologie di JIRA CORE , anche le tipologie di progetti dedicate allo sviluppo Software. Se andiamo a selezionare il progetto di tipo KANBAN, come mostrato dalla figura siccessiva, viene indicato il workflow necessario.

Procedendo con la normale procedura, assegniamo il nome al progetto e…..

…. questo viene creato. In questo caso, la board agile kanban viene subito proposta all’utente, in modo da metterlo in condizione di poter svolgere la propria attività.

A questo punto, si può procedere con lo sviluppo del software, second la metodologia kanban 🙂

Funzionalità disponibili?

Sono presenti le funzionalità che lo stesso JIRA CORE presenta, con l’aggiunta della Board AGILE. Sono presenti altre tipologie di Issue, come mostrato in figura:

Ricordiamoci che è sempre possibile creare delle nuove issue type, in base alle nostre esigenze, come per il JIRA CORE.

Faccio notare una cosa. Diamo una occhiata alla seguente immagine:

Possiamo osservare che su JIRA SOFTWARE è presente anche JIRA CORE. Questo vuol dire che JIRA SOFTWARE estende JIRA CORE. In aggiunta abbiamo che JIRA Service Desk,  che estende a sua volta JIRA SOFTWARE. Queste informazioni sono presenti nella sezione SYSTEM (COG menù) -> Application.

La configurazione di un progetto è identica sia per JIRA CORE che per JIRA SOFTWARE.

Conclusioni

Abbiamo visto JIRA SOFTWARE in azione. Abbiamo visionato alcune differenze con JIRA CORE, cercando di aiutare gli utenti ad usare entrambe le versioni, cercando anche di identificare le differenze tra le due installazioni, cosa che sicuramente aiuta gli utenti e gli amministratori nell’uso di tutti i giorni.

JIRA Software

In questo post, come per i casi prececenti, andremo ad esaminare come eseguire l’installazione di JIRA Software, esaminandone tutti gli aspetti.

Premessa

Come per quanto riportato in questo post, e successivi, le indicazioni da seguire sono le medesime. Occorre sempre tenere d’acconto le stesse considerazioni. Unica variante, rispetto a quanto indicato nel post, consiste nel fatto che installiamo questa versione solo se abbiamo la necessità di un JIRA che ci supporti nello sviluppo di software. Infatti, questa installazione ci mette a disposizione una serie di strumenti dedicati allo sviluppo software.

A differenza della installazione JIRA CORE, abbiamo a disposizione fin da subito le BOARD AGILE, per agevolare lo sviluppo software, tutto già incluso nella installazione, oltre che tutta una serie di strumentazioni che ci agevolano in questo obbiettivo.

Installazione & Configurazione

Che cosa cambia rispetto a quanto descritto per JIRA CORE? Assolutamente nulla :-). L’installazione viene eseguita seguendo gli stessi passi e avendo a disposizione le stesse accortezze già descritte nel post. Di conseguenza, vi rimando al post di installazione su JIRA CORE per qualsiasi dettaglio, ovvero ai seguenti post:

• Parte 1
• Parte 2

Conclusioni

Concludiamo questo post, dove abbiamo specificato una prima parte. Suggerisco ai lettori di ripassare quanto riportato nei post citati, dedicati a JIRA CORE, prima di passare alle fasi successive.

eLearning con i prodotti Atlassian #2

In questo post, proseguiamo quanto iniziato nel seguente post, dove abbiamo iniziato a discutere ed analizzare come i prodotti della Atlassian possono essere usati per poter realizzare sistemi di eLearning.

Proseguiamo con JIRA

Andiamo avanti e cerchiamo di capire che cosa si può realizzare con JIRA. Per le sue peculiarità, e come indicato nel mio precedente post, JIRA può essere utilizzato per creare dei compiti da assegnare alla persona. Vediamo come.

Possibilità uno

UN primo esempio può essere quello di creare dei task con dei passi ben stabiliti, che servono alla persona per intraprendere (scusate se lo ripeto) il percorso di apprendimento. Questo è un concetto fondamentale, in quanto forniamo allo studente i passi da eseguire. Se li forniamo in un modo particolare, allora riusciamo ad assicurarci che lo studente abbia appreso un determinato argomento studiato.

Questo diventa un esame a tutti gli effetti.

Possibilità due

Se eseguiamo una combinazione nella gestione dello starter kit, possiamo anche pensare di realizzare l’inserimento in azienda come un insieme di passi ben definiti, quali ad esempio:

• richiesta e rilascio del badge aziendale
• richiesta della login per accesso alla rete aziendale
• richiesta, qualora necessario, del notebook o del materiale aziendale necessario per il ruolo da ricoprire
• Compilazione della documentazione aziendale
• Compilazione della documentazione contabile (INPS, enti previdenziali, assicurazioni, etc.)
• …..(altri passi sulla falsariga dei precedenti)…..

Una piccola annotazione. Questo è solo un esempio, che esprime il concetto. Provate ad immaginare questa soluzione intercalata nella Vostra realtà aziendale.

In entrambe le possibilità, occorre tenere presente che una squadra di persone dedicate, deve, in ogni caso, arrivare a controllare e validare tutto il percorso seguito dal neoassunto, esaminare i risultati ottenuti, al fine di valutare se la persona ha effettivamente studiato ed appreso le informazioni che sono alla base degli argomenti trattati. Usando questo sistema, una volta superato lo stadio iniziale, si eviteranno tutta una serie di contrattempi e di problematiche che normalmente agitano la vita del neoassunto.

Il come realizzare il tutto, si può ottenere sfruttando sia le potenzialità base di JIRA, che attraverso vari Addons, che aiutano in questa fase.

Conclusioni

Concludiamo questo argomento con questo post, dove abbiamo esaminato alcuni possibili utilizzi degli strumenti della Atlassian. Questo è ovviamente uno dei possibili. La fantasia è il solo unico limite 🙂

Altro lavoro dell’Artigiano

Annuntio vobis gaudium magnum, habemus supporto alla lingua italiana del Kanoah Test 🙂

Migrazione

In questo post iniziamo ad affrontare un argomento molto tosto: La MIGRAZIONE :-P. Croce e delizia di ogni sistemista, per quanto difficile, una volta tenuto d’acconto di alcuni punti cardine, possiamo affrontarla senza alcun problema. Iniziamo questo piccolo viaggio 🙂

Una piccola premessa

Prima di entrare nel dettaglio, andiamo a fare alcune elucubrazioni preliminari.

La prima cosa da tenere sempre a mente è da dove partiamo e dove arriviamo. Cercate sempre di avere sempre la situazione sotto controllo.

Come parti fondamentali, consiglio di tenere sotto controllo:

• Database utilizzato. Questo ci aiuta a capire se è compatibile con il nuovo sistema oppure no o se ci sono delle limitazioni di cui tenere conto.
  
• Sistema installato sulla nostra rete o in hosting su di un sistema cloud. Questo ci dice come possiamo reperire le informazioni. Se stiamo utilizzano un sistema server nella nostra rete, siamo molto avvantaggiati. Se ci dobbiamo interfacciare su di un sistema cloud, possiamo avere delle limitazioni.
• Usiamo un LDAP oppure no. Qui dobbiamo prestare attenzione: Se lo utilizziamo ci possono essere dei problemi a livello di licenza.
• SSO (Single Sign-On) presente?
• Mole di utenti, per capire se le nuove versioni hanno un aggravio di costo oppure no ed anche …. se abbiamo bisogno di fare pulizia. Per i prodotti Atlassian (e qui lo scrivo in maniera molto semplice) DOVETE FARE ATTENZIONE. Lo spiegherò meglio dopo, ma non possiamo cancellare a cuor leggero.

Per i prodotti Atlassian

I casi di migrazione che possiamo affrontare sono i seguenti:

• Migrazione di versione  (Ad esempio: da JIRA 6 a JIRA 7)
• Migrazione di versione e di installazione (Ad esempio: da JIRA 6 Server a JIRA 7 cloud)
• Migrazione di installazione (Ad esempio: da JIRA Cloud a JIRA Server).

Per tutte le situazioni tenere sempre a mente i seguenti punti:

• Utenti: Prestare attenzione massima. Non possiamo rimuovere un utente a cuor leggero, in quanto ogni singola operazione viene tracciata ed assegnata ad ogni utente, anche quelli non pi attivi. Quindi, quando viene fatta la migrazione, ce li ritroveremo nuovamente.
• Addons: Ci possono essere problemi di compatibilità. Per le versioni successive potremmo non avere a disposizione alcuni addon, semplicemente perché il produttore …. non ha avuto il tempo di crearlo :-). Aggiungiamo che, un piccolo dettaglio che nella mia esperienza ho riscontrato, si presenta un problema contabile: Da una certa versione gli addon possono diventare a pagamento. Questo non ci aiuta di certo. :-O.
• Cloud Vs Server: Se si passa da Server a Cloud, abbiamo un altro piccolo problema: Non tutti gli addon sono disponibili per cloud. Anche qui occorre prestare molta attenzione. Se si passa alla versione cloud, occorre essere ben coscienti che non si possono trovare tutto ciò che ci serve, ma non disperate: Il numero di addon per la versione Cloud è in aumento :-).
• JIRA 7: Dato che nella ultima pacchettizzazione abbiamo delle piccole differenze, occorre tenere presente questo fatto e capire quale è la nuova versione da installare.

Conclusioni

Concludiamo questo post con le considerazioni fornite. Nei prossimi post andremo ad esaminare un semplice esempio di migrazione.