Exporter issue per JIRA CLOUD

In questo post andremo ad esaminare un addon molto imortante per JIRA. Si tratta di Exporter issue per JIRA CLOUD.

Di cosa si occupa?

Fondamentalmente si occupa di esportare/importare le Issue dei nostri progetti presenti sulle istanze di JIRA CLOUD. In questo modo abbiamo un ulteriore strumento che aiuta nella nostra gestione es amministrazione dei nostri progetti.

Consente di eseguire delle esportazioni su formato CVS e permette di poter successivamente reimportare il tutto sia sulle nostre istanze Cloud, che nelle nostre istanze Server. Questo diventa quindi un valido strumento per le migrazioni 🙂

Il formato con cui viene eseguita l’esportazione è simile a quello che la stessa Atlassian mette a disposizione di JIRA. Quindi non abbiamo stravolgimenti che ci fanno ammattire, ma uno strumento che ci aiuta e ci mette a disposizione le informazioni esattamente come ci aspettiamo.

Possiamo anche vedere il transaction log, come mostrato in figura. L’esportazione risulta decisamente completa.

Considerazioni

Faccio alcune considerazioni sull’addon. Si tratta di un addon che colpisce nel punto giusto: le migrazioni e le esportazioni dati da e per i prodotti della Atlassian sono sempre stati una croce ed una delizia di ogni amministratore dei prodotti della Atlassian.

Avere a disposizione uno strumento completo che permette di poter, aggiungo io Finalmente, trattare l’argomento in maniera semplice e senza dover ammattire, è un vantaggio enorme.

Conclusioni

Abbiamo visionato un addon che ci aiuta nel nostro lavoro. Nei prossimi post andremo a fare le prove su campo di questo addon. Tenteremo di migrare un JIRA e ne valuteremo le potenzialità, limiti e prestazioni.

Reference

• Video che spiega il funzionamento dell’addon
• Articolo di un blog che presenta e spiega (in inglese) l’addon.

Bitbucket – First Look

In questo post andremo ad analizzare questo nuovo componente della Atlassian: Bitbucket. Diamo una prima occhiata con l’obbiettivo di capire che cosa offre 🙂

Che cosa è?

Bitbucket is the Git solution for professional teams

Questa è la definizione che è presente nel sito ufficiale. Si tratta fondamentalmente della soluzione offerta dalla Atlassian per gestire i progetti attraverso GIT.

Che cosa è GIT?

Come indicato nella pagina di wikipedia che ho linkato prima, è un sistema di controllo versione del codice. Tutte le informazioni sono reperibili qui, nel sito ufficiale.

Ho trovato una guida, molto semplice, che spiega che cosa è GIT e come funziona. Spero che possa aiutare i lettori, che magari si affacciano la prima volta, a capire che cosa è, come funziona e ragiona.

Andiamo al sodo

Adesso andiamo ad esaminare le caratteristiche salienti del sistema 🙂

Come ogni sistema di controllo versione, come CVS, SVN et al., GIT ragiona a riga di comando. Bitbucket consente di poter usare questo fantastico sistema di controllo versione senza la difficoltà della riga di comando :-).

Bitbucket è fondamentalmente l’interfaccia che la Atlassian mette a disposizione per potersi interfacciare con i sistemi GIT.

Che cosa consente di fare?

Consente di eseguire tutte le operazioni che riguardano il sistema di controllo versione, in maniera semplice, guidata e veloce. In aggiunta, e questa non poteva assolutamente mancare, mette a disposizione anche delle caratteristiche social.

In aggiunta, e questo lo diamo abbastanza scontato :-P, questo prodotto si integra molto bene con tutti i prodotti della famiglia Atlassian. JIRA in primis.

Conclusioni

Abbiamo presentato, in questo post, Bitbucket. Nei prossimi post andremo ad esaminare nel dettaglio le funzionalità, quali caratteristiche, limiti e tante altre cose interessanti.

Product Requirements

In questo post andremo ad esaminare come Confluence ci può aiutare nella redazione di product requirements, basandoci sull’articolo del blog ufficiale di Confluence

Andiamo al sodo

Sfruttiamo le funzionalità che Confluence ci mette a disposizione :-). Per realizzare il tutto abbiamo a disposizione opportuni template che ci aiutano nel creare questi contenuti particolari. Semplicemente andiamo a selezionare il template del Product Requirements e andiamo a costruire la nostra pagina.

Seguiamo l’autocomposizioni, cui la Atlassian ci ha abituati in tutti questi anni.

Come possiamo vedere, ci vengono fornite tutte le indicazioni del caso. Non possiamo sbagliare 🙂

Quindi selezioniamo Create. Il risultato è il seguente

A questo punto compiliamo i vari campi e lasciamo libera la nostra fantasia, andando a scrivere tutte le informazioni che servono  :-).

Che altro possiamo fare?

Ovviamente questo è il solo punto di partenza. Confluence ci mette a disposizione tutta una serie di strumenti che permettono di poter personalizzare in base a tutte le esigenze. Possiamo infatti costruire dei template ad hoc, espressamente dedicati per determinati Product Requirements, oppure avere delle diversificazioni in base ai progetti o alle tipologie di progetti. Oppure possiamo sfruttare altre caratteristiche, di cui abbiamo più che ampiamente parlato, quale il Yoikee Creator, Mind Mapping 🙂

In questo Confluence ci aiuta in questa operazione. Possiamo aggiungere altri addon, come descritto in altri post, per poter estendere le funzionalità e aiutarci nel nostro lavoro.

Ripeto il consiglio: Lasciate che il vostro unico limite sia la fantasia :-D.

Conclusioni

Abbiamo visto un ulteriore esempio di come Confluence si dimostra uno strumento eccezionale, sempre rispondente alle nostre esigenze e con caratteristiche superiori.

Reference

• Articolo del blog

Annuntio Vobis Gaudium Magnum

E’ con grande gioia che annuncio che il buon artigiano è adesso Atlassian Partner.

Voglia di fare e perseveranza sono stati premiati con questo grande risultato :-), ma si tratta solo del punto di partenza per nuove imprese e nuovi risultati.

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

Altro esempio di uso

In questo post andremo ad esaminare quanto descritto nel post del blog ufficiale della Atlassian, cercando di spiegarlo meglio e di fornire quanti più dettagli possibili.

Procediamo….

Andiamo ad esaminare una funzionalità di Confluence, che ci consente di interfacciarci a JIRA, in modo da poter andare a leggere le informazioni delle issue, relative ad un rilascio, e pubblicare il risultato su di una pagina , che raccoglierà tutte queste informazioni.

Andiamo a selezionare dal tasto:

e selezioniamo il template JIRA report.

quindi selezioniamo Change log:

A questo punto, attendiamo che l’autocomposizione di Confluence vada a leggere le informazioni dei progetti JIRA e ci chieda quali parametri passare:

Possiamo andare a imputare i parametri sfruttando la modalità semplice della autocomposizione, oppure, come mostrato nella seguente figura:

possiamo impostare una opportuna query JQL, che ci consente di poter andare a selezionare le issue che ci servono :-). Il risultato è la seguente pagina:

Possiamo identificare le seguenti sezioni:

• Page properties, dove andiamo ad inserire dei metadati che possono risultare utili nel caso di report o recupero delle informazioni;
• Riassunto, dove riportiamo un riassunto delle informazioni;
• Punti chiave del rilascio, dove riportiamo che cosa si è voluto rilasciare
• JIRA Issue, dove è riportato l’elenco delle JIRA ISSUE coinvolte.

Come si vede, abbiamo a disposizione un semplice template che ci consente, attraverso l’uso di pochi passi e delle macro di connessione ai dati JIRA, di poter reperire le varie informazioni, in modo semplice e veloce.

Conclusioni

Abbiamo visto fino a qui delle indicazioni su come realizzare una Release Notes. Una cosa vorrei far notare: Questo funziona anche se non si tratta di un software, ma del rilascio di una nuova macchina, che presenta dei miglioramenti rispetto alla precedente edizione. Analogo discorso per un manuale. Ricordate quindi che quanto dico si può tranquillamente applicare anche ai progetti ed alle realtà NON IT, non di informatica :-).

Reference

• Articolo del Blog della Atlassian.

Prendiamo una decisione ….

Sulla falsariga di una pubblicità, usiamo Confluence per aiutare gli utenti di un determinato gruppo di lavoro, nell’ambito di un loro processo decisionale, a prendere una decisione. Ci rifacciamo all’articolo del blog ufficiale della Atlassian, ma cercherò di metterci del mio :-P. L’obbiettivo è quello di stimolare la fantasia degli utenti in modo che siano loro a costruirsi la propria soluzione 🙂

Andiamo in dettaglio

Confluence ci mette a disposizione tutta una serie di strumenti che possono essere usati per definire un processo decisionale. Possiamo utilizzare sia i template che Confluence stesso mette a disposizione. Si tratta del template Decision, che come vediamo possiamo così usare:

Come possiamo vedere, inseriamo pochi semplici parametri, e arriviamo a costruire la nostra pagina dedicata alla decisione.

Tuttavia, questo non è una regola invalicabile. Possiamo usare anche altri template, come mostrato in precedenza; possiamo anche costruirci il nostro template ad hoc.

Un esempio potrebbe essere questo che segue:

Possiamo usare il template che Confluence mette a disposizione, per poi ….. estenderlo a nostro piacere e necessità, aggiungendo ulteriori componenti o togliendone di non necessarie. :-). Questo è il bello di Confluence: Libertà massima.

In questo caso, abbiamo usato i seguenti componenti:

• Metions, per coinvolgere gli utenti di confluence responsabili della … decisione. Nel caso di altri utenti, non presenti in Confluence, possiamo solo indicare il nome. Questa soluzione è usabile anche nel caso di pagina che consente un accesso anonimo;
• Page Properties, che andiamo ad usare per inserire una serie di informazioni o metadati alla pagina. Questo risulta assai utile quando vogliamo creare delle pagine riassuntive 
• Tabelle, che usiamo per definire step, informazioni in maniera strutturata, etc. 
• Messaggistica, che andiamo ad usare per comunicare informazioni/messaggi/task.

Carino, ma è il solo modo?

La domanda sorge spontanea. Possiamo solo usare Confluence? Azzardiamo una soluzione alternativa. Possiamo anche fare uso di JIRA, sfruttando le sue potenzialità. L’uso di JIRA può fornire quella marcia in più per poter aiutare le persone nel percorso decisionale.

Infatti, possiamo sfruttare i workflow in modo da impostare un percorso decisionale, definendo tutti i passi da seguire per arrivare alla decisione.

Questo ci può aiutare anche nel definire dei processi approvativi, come mostrato nell’esempio dell’Asset management  e l’uso delle board Agile, ci può aiutare nella fase di cambio stato o nel mostrare lo stato di avanzamento (ovviamente in situazioni limitate o con opportiuni filtri – filtri da verificare).

Usando JIRA, invece di creare delel pagine, andiamo a creare un progetto o più progetti,m dedicati ai processi decisionali. Le relative Issue saranno poi le singole decisioni da prendere.

Possiamo sfruttare le potenzialità delle linked issue per legare eventuali decisioni ad altre, qualora ci siano delle dipendenza. Non male 🙂

Possiamo anche aggiungere una serie di campi custom, dedicati alla fase decisionale, che sicuramente ci aiutano. Ovviamente, in questa soluzione, Confluence può essere o meno usato come supporto. Mi spiego meglio: possiamo usare sempre confluence per documentare /  creare le pagine di documentazione che saranno di di supporto. Ovviamente queste pagine possono anche essere i contenitori di allegati di vario genere e natura.

L’obbiettivo è di sfruttare il più possibile le funzionalità che abbiamo a disposizione. 🙂

Un piccolo chiarimento

Anche se i prodotti sono dedicati prevalentemente allo sviluppo software, possiamo usarli anche per soluzioni che definisco ….. alternative. Quello che voglio esprimere in questi post, è che risulta possibile utilizzare questi strumenti anche per altri scopi,che nulla hanno a che fare con la IT.

Conclusioni

Abbiamo visto due possibili utilizzi delle funzionalità di Confluence e JIRA. Possiamo usare Confluence per aiutarci nel nostro processo decisionale, oppure usarli entrambi in modo da sfruttare meglio le funzionalità di entrambi. Ricordate sempre: La fantasia deve essere il nostro unico limite  🙂

http://blogs.atlassian.com/2015/09/make-better-decisions-software-team/

Prova su strada

In questo post andremo a vedere nel dettaglio quanto descritto nel precedente post, mostrando come farne uso.

Procediamo

Per accedere alle funzionalità descritte, occorre andare in editazione del workflow, come mostrato nella figura:

Quando andiamo a selezionare le transazioni di stato, come mostrato, abilitiamo il menù che ci interessa, che viene mostrato sulla destra.

Triggers

Selezionando tale opzione, andiamo a configurare quali operazioni devono essere eseguite in fase di cambio di stato.

Viene proposta una apposita maschera video (probabile che venga aperta una nuova finestra del browser), dove possiamo andare a configurare le nostre operazioni.

Come possiamo vedere, occorre connettere ai sistemi di controllo versioni, quali FishEye, Stash, Bitbucket, etc.

Dalla stessa maschera video possiamo costruire anche i seguenti elementi:

• Conditions
• Validations
• Post-Functions

Vediamo come definire queste operazioni.

Conditions

Selezioniamo il tab relativo, mostrando le funzionalità della precedente figura. Per creare una nuova condizione, selezioniamo Add condition.

Come possiamo vedere, una agevole autocomposizione guida l’utente nella scelta e definizione della condizione. Supponiamo di voler far si che la transazione di stato scelta, possa essere eseguita solo da  alcuni utenti, o dagli utenti di un particolare gruppo. Vediamo la sequenza di operazioni. Facendo riferimento alla immagine precedente. selezionamo User is in Group, quindi selezioniamo  Add.

Selezioniamo il gruppo degli utenti ed il gioco è fatto 🙂

Abbiamo così aggiunto una nuova condizione.

Validations

Selezioniamo il tab Validations ed iniziamo a lavorarci, come mostrato in figura:

Selezioniamo Add Validator e procediamo con l’aggiunta della validazione.

Possiamo aggiungere un Permission Validator oppure uno User Permission Validator. Questo ultimo è obsoleto, in quanto presente nelle prime versioni di JIRA. Andiamo a configurare un Permission Validator.

Selezioniamo le Permission che vogliamo andare a controllare. La seguente immagine visualizza i risultati 🙂

Post-Functions

Si tratta delle operazioni che possiamo far eseguire a JIRA, quando la transazione di stato è stata eseguita. Questo per completare le operazioni. Andiamo in dettaglio.

Selezionando Add Post Function , viene visualizzata la selezione mostrata nella precedente immagine. Possiamo impostare l’azione aggiuntiva da eseguire. Supponiamo di voler eseguire l’aggiornamento di un campo. Selezioniamo Update Issue Field quindi selezioniamo Add.

Supponiamo di impostare un valore Esempio al campo Environment. Selezioniamo Add ed il gioco è concluso.

Properties

Si tratta di una coppia di valori che possiamo associare agli stati di un workflow. vediamo come associare queste informazioni. Semplicemente selezionare uno stato:

quindi andiamo a selezionare il link Properties, posto a destra.

A questo punto possiamo inserire le proprietà che vogliamo. Come indicato nella precedente immagine, proprietà possono essere definite per abilitare ulteriori personalizzazioni nei vari passi.

Conclusioni

Abbiamo visto ulteriori funzionalità standard che JIRA mette a disposizione.  A questo punto abbiamo solo la nosra fantasia per poterle usare al meglio, per facilitarci la vita. 🙂

Test delle funzionalità descritte.

https://confluence.atlassian.com/jira/advanced-workflow-configuration-317196666.html

scrivere un articolo di approfondimento su WOrkflow.

… Censire e gestire le offerte di lavoro

In questo post andremo a capire come gestire Confluence e JIRA per gestire delle ….. offerte di lavoro.

Vediamo come

Come in altre situazioni descritte, possiamo utilizzare le Issue Type di JIRA per definire delle … offerte di lavoro. Quindi, basandoci anche su quanto indicato nel post precedente, possiamo arrivare a gestire le offerte di lavoro di una azienda medio piccola.

Possiamo creare tante Issue quante sono le offerte di lavoro. Quindi, sfruttando un opportuno Workflow, andiamo a gestire le varie fasi della selezione, passando dalla fase di pubblicazione, alla fase di ricezione CV, selezione personale, etc.

In aggiunta, possiamo allegare i CV che ci interessano alla Issue (o in alternativa tutti i CV che sono pervenuti), in modo da poterli avere sempre sotto controllo.

Per documentare e avere indicazioni dei vari CV, Confluence ci viene incontro. Possiamo definire uno space dove andremo a scrivere delle pagine dedicate alle singole operazioni. Potremmo avere delle pagine dedicate alla descrizione dell’offerta, alle richieste operate dal cliente, informazioni accessorie. Poi possiamo anche aggiungere le pagine con i risultati dei colloqui.

In aggiunta, possiamo avere a disposizione anche la Agile Board, per meglio gestire i cambi di stato.

Conclusioni

Abbiamo visto un ulteriore utilizzo di questi strumenti per scopi NON IT. Vediamo che questi strumenti sono abbastanza versatili per poter realizzare funzionalità che, normalmente, richiederemmo altri software, senza avere la stessa versatilità di Confluence e JIRA 🙂

Confrontiamo gli strumenti

In questo post andremo in dettaglio, rispetto a quanto accennato in questo post. L’obbiettivo è sempre quello di dare indicazioni per fornire l’addon giusto al momento giusto.

Iniziamo il confronto

Disponibilità

La prima cosa che andiamo ad indicare è che gli addon specificati sono tutti disponibili per le installazioni Server. Unica differenza è che solo Zephyr risulta disponibile solo per il Cloud.

Questo significa che se disponiamo di una installazione cloud, e non possiamo farne a meno, la scelta è pressoché obbligata.

Se invece disponiamo di solo installazione server, allora non abbiamo questo problema e possiamo scegliere, sempre in base alle nostre esigenze, l’addon che più ci piace.

Prezzo

Escludendo il taglio dei 10 utenti, dove tutti gli addon presentano lo stesso costo ($10), vediamo che l’addon XRay risulta il più economico. Segue l’addon Kanoah Tests e l’addon Zephyr. Quest’ultimo è il più costoso.

Il costo della versione cloud di Zephyr è abbastanza contenuto. Se disponiamo di un taglio abbastanza piccolo di utenti, possiamo anche arrivare a non spendere molto.

Funzionalità

Esaminando i vari post di presentazione e prova su strada, Zephyr potrebbe risultare più complicato da usare, mentre l’XRay risulta quello più semplice. Infatti, con XRay basta semplicemente creare un progetto e poi da li creare le Issue, definendo tutto all’interno della generazione delle issue.

Kanoah, in questo caso, presenta una complessità media, ma nelle ultime versioni, ho avuto modo di verificare che il gruppo di lavoro sta cercando di semplificare al minimo la complessità. In aggiunta, Kanoah è al momento l’unico che dispone di un timer che aiuta nel comprendere anche quanto tempo si è dedicato alla esecuzione di un test.

Integrazione con JIRA

Per quanto riguarda l’integrazione con JIRA, l’addon che meglio si integra sono XRay e Zephyr, in quanto generano i test come se fossero Issue a tutti gli effetti. In questo modo si arriva a fornire una nuova funzionalità senza un addestramento particolare del personale.  😉

Infatti, se il personale è abituato a lavorare con JIRA, non avrà alcuna difficoltà a lavorare con i casi di TEST.

D’altra parte, Kanoah introduce delle sezioni dedicate ai test, che si appoggiano alle Issue JIRA. In questo caso, creiamo dei Test Case separati che si collegano facilmente alle Issue JIRA. In questo modo possiamo definire dei cicli di test unici per differenti issue, che possono anche essere relative a diversi progetti (che magari presentano la stessa funzionalità). Abbiamo quindi una buona riusabilità. 🙂

Conclusioni

Per le versioni cloud, la scelta risulta al momento forzata, in quanto l’unico addon (al momento in cui l’articolo viene scritto, la situazione  quella descritta).

Per le versioni server abbiamo molta più scelta. Se il nostro obbiettivo è quello di usare il prima possibile queste funzionalità, allora la nostra scelta ricade su XRay e su Zephyr, in quanto diventano una sorta di estensione delle Issue JIRA (con delle funzionalità non indifferenti) 🙂

Se invece, ahime, è il nostro portafoglio a dettare legge, la scelta ricade sicuramente su XRay, in quanto offre un ottimo insieme di funzionalità ad un costo relativamente contenuto.

Se invece vogliamo puntare sulla riusabilità, integrata con altri progetti, allora abbiamo a disposizione il Kanoah Tests, che ci consente di poterci agganciarci a più progetti.

Ovviamente si tratta di un confronto che mira a non dichiarare un vincitore tra le parti, ma semplicemente cerca di aiutare gli utenti nella scelta dell’addon, seguendo le proprie necessità.