Addons per JIRA

In questo post andremo ad esaminare due addon per JIRA, uno che consente di poter impostare delle Checklist nelle issue, ed uno che consente di poter impostare dei test case, sfruttando le potenzialità di JIRA.

Checklist

Uno degli addon prodotti, consente di poter impostare delle checklist all’interno delle ISSUE di JIRA.

Inserire delle checklist in una issue permette di poter inserire nell’issue stessa a modalità per poter verificare la effettiva risoluzione delle anomalie.

Con questo sistema è possibile inserire un sistema di verifica della anomalia, a prova di tutto. In questo modo, chiunque si occupi del system test è in grado di eseguire le verifiche del caso per poter verificare se il problema è stato effettivamente risolto.

Test Case

Un altro addon che la Kanoah mette a disposizione, consente di poter creare dei test case e associarli alla issue JIRA.

Questo addon si integra perfettamente con JIRA, estendendone le funzionalità consentendo di  per poter aggiungere i test case necessari per verificare lo sviluppo. Questo addon è stato studiato in modo da poter fornire una integrazione importante tra chi si occupa del system test e lo sviluppo.

Conclusioni

SI tratta di due addon, per il  momento solo per installazioni server, che consentono di poter migliorare il system test ed il lavoro del personale addetto ai test. Nei prossimi post, andremo a fare la …. prova su strada, ma sono sicuro che non deluderanno le aspettative 🙂

Riferimenti

Riferimenti agli addon:

• checklist
• test

Usiamo Confluence

In questo post andremo ad esaminare come possiamo utilizzare Confluence nell’ambito di un progetto, chiudendo quanto iniziato in questo post e continuato in questo post.

Come possiamo usarlo?

Possiamo usare Confluence per classificare i vari asset in uso, documentare in maniera completa tutti gli interventi e/o indicare pregi/difetti degli stessi. Quello che è possibile fare è creare uno space dedicato, in cui andremo a creare le varie pagine di dettaglio.

Lo Space presenterà una pagina Home, in cui sarà riportato un quadro riassuntivo dei vari asset. Sfruttando le Page Properties riusciamo a creare delle pagine di dettaglio, che possiamo raggruppare come già visto nelle schede clienti.

In questo modo possiamo avere delle schede tecniche, utili per il supporto, che consentono di poter migliorare il lavoro. Si può, in questo modo, arrivare a gestire meglio l’assegnazione delle risorse. Ad esempio, se un capo cantiere ha la necessità di un portatile, quando è in cantiere, non ha senso assegnargli un notebook normale, ma conviene assegnargli un notebook che possa reggere gli urti, che possa sopportare le sollecitazioni, etc.

Se il responsabile degli asset dispone di tutte queste informazioni, riesce a fare meglio il proprio lavoro. 🙂

Andiamo in dettaglio e verifichiamo come possiamo realizzare queste schede.

Scheda Asset

Una scheda asset, sicuramente, dovrà contenere le informazioni del dispositivo, con tutte le caratteristiche del prodotto, quante riparazioni/interventi ha subito, a quante persone è stato assegnato, etc.

Sfruttiamo le Page Properties per avere tutte queste informazioni, come mostrato nella figura sottostante

Allo stesso modo, possiamo collegare anche le ISSUE create dal Service Desk, per creare una cronostoria delle segnalazioni aperte (vedi figura precedente). Successivamente, possiamo anche visualizzare la ISSUE dell’Asset, usando le apposite Macro. Sulla pagina principale, possiamo invece avere un quadro situazione. Abbiamo un unico punto in cui contenere tutte le informazioni, tutti i drivers del pc o notebook, informazioni sul server, etc etc.

In questo modo si ha la possibilità di avere una scheda del server, notebook, computer, etc.; in cui l’amministratore deve gestire, arrivando ad avere il controllo completo dell’Asset dell’azienda.

Grafici

Possiamo poi utilizzare Gliffy per arrivare ad avere dei grafici, come già visto, da utilizzare per capire come potersi muovere per eseguire operazioni, manutenzioni, azioni, etc.

La  seguente immagine può aiutare a comprenderne le potenzialità 🙂

Allo stesso modo, come già mostrato nel post precedentemente pubblicato, possiamo sfruttarlo per creare grafici di flussi di lavoro e tutto ciò che può tornare utile per poter gestire il nostro ASSET, comprensivo della localizzazione dell’asset. A tale scopo, potrebbe tornare utile anche il seguente addon.

Conclusioni

Abbiamo concluso, con questo post, l’argomento ASSET. Questo ovviamente  non esaurisce l’argomento e sicuramente, con le nuove funzionalità che la Atlassian metterà in campo, riusciremo ad estendere il tutto.

Ultime novità

In questo post andremo ad esaminare le ultime novità, introdotte dalla Atlassian, su Confluence, Jira etc.

Confluence

Con i rilasci eseguiti tra il 24 maggio ed il 30 maggio, è stata rilasciata la versione 5.9.0-OD-52 che presetava le seguenti nuove funzioni:

Modificata la macro Content by label, che viene estesa in modo da poter eseguire interrogazioni molto più mirate. Impariamo a conoscere il  CQL – Confluence Query Language, attraerso il quale è possibile eseguire opportune query nelle pagine, come mostrato nella figura precedente. Lo stesso è stato realizzato per le Page Properties: Le macro di riferimento sono state estese. Nei prossimi post andremo a visionare nel dettaglio queste nuove caratteristiche, con la solita prova su strada 🙂

I metadati della pagina (label, restrizioni, posizione) sono stati spostati in cima alla pagina. Questo facilita la gestione di queste informazioni.

Con i rilasci dal 31 maggio a 6 giugno, è stata rilasciata la versione 5.9.0-OD-56 che ha introdotto le seguenti novità:

Sono state introdotte le Table Settings, attraverso le quali è possibile inserire in automatico la numerazione in prima colonna. Un automatismo non indifferente :-). Altra novità introdotta è la possibilità di poter copiare le colonne di una tabella molto semplice. Nella bottoniera, in alto, oltre alle funzionalità già presenti e cui siamo abituati, possiamo vedere i nuovi comandi.

JIRA

Passiamo adesso ad esaminare le novità per JIRA. Andiamo con ordine.

Con il rilascio eseguito dal 24 maggio al 30 maggio, con il rilascio della versione JIRA 6.5-OD-04, sono state rilasciate una serie di bugfix minori. Il seguente link li riassume tutti.

Con il rilascio eseguito dal 31 maggio al 6 giugno, con il rilascio della versione JIRA 6.5-OD-05, si è completato il rilascio con una ulteriore serie di bugfix minori. Il seguente link li riassume tutti.

JIRA Service Desk

Rispetto a JIRA, qui abbiamo delle belle novità :-). Andiamo con ordine.

Con il rilascio eseguito dal 24  al 30 maggio, con il rilascio della versione JIRA Service Desk 2.5.1-OD-02, si è completato il rilascio di diversi bugfix.

Con il rilascio eseguito dal 31 maggio al 6 giugno, con il rilascio della versione JIRA Service Desk 2.5.1-OD-03, viene rilasciato il nuovo service desk project navigation, come mostrato in figura.

Viene notevolmente migliorata l’interfaccia per creare dei portali custom per l’accesso al Service Desk.

Come si può vedere dalla figura, adesso abbiamo a disposizione un sistema molto più semplice ed intuitivo per poter creare il portale di accesso 🙂

Altri bugfix sono stati rilasciati con questa versione.

 Conclusioni

Abbiamo a disposizione delle belle novità. Come sempre la Atlassian ci continua a sorprendere con nuove belle funzionalità. Restiamo in attesa dei prossimi rilasci. 🙂

Reference

• Rilascio dal 24 al 30 maggio.
• Rilascio dal 31 maggio al 6 giugno.

Andiamo in dettaglio

In questo post, andremo ad esaminare nel dettaglio la parte di JIRA, in cui inizieremo a vedere come configurare la gestione di un progetto, continuando quanto già pubblicato in questo post.

JIRA – configuriamolo

La prima cosa da fare, una volta installato il nostro JIRA, è quello di definire un nuovo progetto. A seconda di quanto è grande/vasto il progetto, potrebbe essere necessario fare uso di più progetti oppure ricorrere alle componenti.

Queste ultime consentono di poter definire una sorta di sottoprogetti, mantenendo tutta la storia all’interno di un unico progetto. Andremo ad esaminare in seguito queste componenti.

Viceversa, se il progetto è abbastanza grande, lo si deve spezzettare in più progetti JIRA, ognuno dedicato ad una delle parti interessate. Ad esempio, se il progetto prevede una componente web molto articolata ed una parte database complessa, allora conviene avere due progetti, e sfruttare la possibilità delle linked issue per poter legare delle issue dei due progetti, nel caso di problematiche inerenti le due aree.

Quando andiamo a definire il progetto, occorre anche capire quale tipologia necessita.

JIRA mette a disposizione diverse tipologie di progetto. Andiamo ad analizzarle per capire meglio quale tipologia utilizzare e che accorgimenti usare. Sullo standard, ovvero sulla installazione di JIRA senza addon particolari (quali JIRA AGILE o simili), abbiamo a disposizione:

Simple Issue Tracking è la soluzione più semplice da utilizzare. Consente di poter definire un semplice progetto in JIRA per tracciare le anomalie e segnalazioni. Si utilizzano le funzionalità standard di JIRA, senza utilizzare altri addon o altre funzionalità particolari. Il workflow di gestione delle issue è riassunto dal seguente diagramma.

Project Management è la soluzione per seguire un progetto dall’inizio alla fine. Questa tipologia di progetto è stata studiata per la gestione di un progetto. Rispetto alla tipologia precedente, cambia il workflow, come mostrato nella figura seguente:

Possiamo anche creare un nostro workflow, come mostrato in questo post, dove possiamo inserire gli stati di cui abbiamo necessità.

Il secondo passo, una volta definito la tipologia di progetto, è quello di definire la tipologia delle ISSUE, in modo da inserire anche tipologie che, nello standard, non sono presenti. Faccio un esempio. Se dobbiamo gestire un semplice Help Desk, senza far uso di JIRA Service Desk, potrebbe essere utile inserire l’Issue Type Segnalazione o con una descrizione simile che aiuti ad identificare le segnalazioni ricevute dall’Help Desk. Per fare ciò, selezionare da COG menù (vedi figura successiva) :

la sezione ISSUE,  per poter accedere alla relativa sezione di amministrazione delle stesse:

Quindi procediamo con l’aggiunta delle ISSUE necessarie.

Definite le Issue ed il relativo Issue type scheme, ed assegnate al progetto, passiamo alla configurazione di gruppi e ruoli. Questa è la parte più delicata e viene eseguita nella sezione di amministrazione di un progetto:

Facendo riferimento alla figura, abbiamo la sezione dei Roles, dove andiamo a definire i ruoli degli utenti oltre che inserire le permission degli stessi.

Possiamo inserire le permission sia attraverso i gruppi che inserendo direttamente gli utenti. Quindi possiamo definire il Default Assignee, ovvero l’utente a cui viene assegnata di default la issue creata. A seconda delle necessità potrebbe essere utile o mantenerlo non assegnato o assegnarlo ad uno dei componenti del gruppo di lavoro.

Successivamente occorre definire le permission, andando a configurare lo scheme permission che si intende utilizzare. Normalmente, quello standard consente di poter coprire tutte le necessità di cui si abbisogna.

Le altre sezioni da impostare sarebbero:

Componenti, importanti per definire le parti principali del progetto, e che consentono di poter disporre di una classificazione più mirata delle ISSUE. Ad esempio, possiamo classificare le ISSUE dedicate al database, dalle ISSUE dedicate alla Web Server, dalle ISSUE del programma, etc etc etc.

Versioni. Chi sviluppa software sa quanto è importante classificare i rilasci in base alla versione, in modo da identificare in maniera semplice quali bug-fix sono presenti sulla versione, quali nuove funzionalità sono state inserite e quali sono state estese,

Per i progetti che non trattano sviluppo software, non è necessario settare le versioni e le componenti possono essere configurate sempre come le aree coperte dal progetto.

Altre configurazioni accessorie, non obbligatorie ma sempre comodo da sapere,  sono le seguenti:

• La scelta di una icona del progetto. Non necessaria, ma quando si devono gestire più progetti, suggerisco di impostarla. Consente di poter riconoscere meglio il progetto rispetto agli altri.
• Possibilità di generare ISSUE via email, qualora si voglia sfruttare una email preesistente, per sfruttare una delle capacità di JIRA di poter generare ISSUE attraverso email.
• Nuovi campi custom. Sempre utili, qualora si voglia tracciare informazioni che non sono coperte dai campi preesistenti di JIRA.

Conclusioni

In questo post abbiamo visto come configurare JIRA per gestire un progetto. Nel prossimo post andremo ad estendere e completare la configurazione.

Proseguiamo la configurazione

Proseguiamo quanto iniziato in questo POST e proseguiamo andando a configurare il progetto TAG e iniziando a configurare JIRA Service Desk.

Creiamo i nostri asset

Una volta configurato il nostro progetto TAG, iniziamo a creare le issue degli asset. Utilizzando la Agile Board Kanban, possiamo eseguire questa operazione molto semplicemente.

In questo esempio ho inserito alcuni asset, tra i quali una mia desiderata: Quello di comprare un server virtuale linux :-P. Questo è il risultato. Per piccole e medie imprese, professionisti o ditte individuali, questo sistema è sicuramente il migliore.

Già così, questa configurazione risulta sufficiente per poter gestire un Asset. La Board ci consente di poter lavorare senza doverci complicare la vita. Su piccole realtà, ci potremmo fermare a questo.

Un qualsiasi generatore di QR Code, la stampa di alcune etichette, ed il gioco è fatto.

L’immagine sopra riportata, corrisponde al QR Code del codice TAG-1.  Possiamo, come hanno realizzato in Atlassian, impostare un QR-Code in modo che riporti l’indirizzo esatto per accedere alla ISSUE TAG; possiamo inserire una URL che vogliamo. Lasciate che la Vostra fantasia faccia il suo corso 🙂

Su realtà già un pò più grandi, l’uso di JIRA Service Desk ci può aiutare nella gestione delle richieste e della gestione. Infatti, sfrutteremo le funzionalità di gestione delle richieste per poter aiutare, chi gestisce gli Asset. Vediamo come

JIRA Service Desk

Andiamo subito al dunque. Configuriamo subito un Service Desk. Come già indicato nei seguenti posts, procediamo di conseguenza. Creiamo il nuovo progetto di gestione.

Una volta creato il nuovo progetto, procediamo con la configurazione.

Iniziamo con il creare un ISSUE TYPE che comprenda quelli utilizzati dal progetto TAG. Quindi, configurare le richieste.

A questo punto, possiamo creare la richiesta, associando anche il TAG-XXX presente nel nostro device.Vediamo i vari passi.

Selezioniamo SUPPORT-2, per il passo successivo:

Selezioniamo la funzione LINK, per associare il nostro TAG-XXX

In fase di LINK, selezioniamo che il nostro SUPPORT-2 è bloccato dalle operazioni che si eseguono su tale link. La prima cosa che esegue chi si occupa del supporto, è di modificare lo stato del nostro TAG-5.

Quando le operazioni sono terminate, il TAG-5 sarà opportunamente dismesso, rimesso in magazzino, riassegnato, etc etc.

Conclusioni

Abbiamo visto, in questo post, come possiamo gestire il nostro Asset e come possiamo, attraverso JIRA Service Desk, gestire le richieste per supporto/manutenzione dei vari ASSET.

Gestiamo un progetto

Vedremo in questo post, come possiamo utilizzare gli strumenti Atlassian per gestire un progetto, non necessariamente IT, e come impostare le varie informazioni di corredo.

Di cosa abbiamo bisogno

Le componenti principali sono:

• Confluence
• JIRA

Ulteriori addon potranno essere utilizzati per raffinare il risultato e migliorare la produttività.

Confluence sarà utilizzato prevalentemente per creare la documentazione del progetto, dove andremo ad indicare tutti i requisiti, documenti del progetto, annotazioni, verbali di riunioni, grafici. In una sola parola TUTTO  :-D. L’uso della macro Roadmap è sicuramente utile per aiutare lo sviluppo e pianificarlo al meglio.

Altre caratteristiche, quali i Template per generare le pagine per i verbali delle riunioni, requisiti, informazioni etc, sono altrettanto utili e valide per impostare tutte le informazioni di corredo al progetto.

Confluence ci mette a disposizione una serie di template pronti all’uso. Quelli relativi alla registrazione dei verbali di riunione sono uno di questi.

JIRA sarà invece utilizzato per la gestione vera e propria dello stesso. In particolare, possiamo andare a gestire il progetto oppure, nella eventualità che il progetto sia abbastanza vasto, abbiamo la possibilità di poter gestire più progetti o di scomporre un progetto in componenti, di più facile gestione.

Qui possiamo scegliere la tipologia di progetto di cui abbiamo bisogno, quali caratteristiche deve possedere, come deve essere organizzato.

Abbiamo la massima libertà di scelta ed organizzazione. Qualora disponiamo anche degli addon AGILE, possiamo anche creare le varianti AGILE SCRUM e KANBAN.

Possiamo creare i vari task, che compongono il progetto, ed assegnarli alle persone dedicate alla realizzazione

definendo anche la tipologia delle issue in base a quanto serve ai nostri obbiettivi.

 Conclusioni

Concludiamo questa prima parte qui. Nei prossimi post andremo più nel dettaglio e vedremo come configurare il tutto.

Prova su strada 🙂

In questo post andremo a fare la prova su strada dell’addon MapIt, descritto in questo post.

Installiamo e proviamo

Procediamo con l’installazione, che come sempre è semplice e veloce, senza particolari interventi

Basta solo attendere qualche secondo:

Qualora si voglia richiedere la licenza di valutazione, basta fornire le proprie credenziali per accedere al sto myatlassian.com, ed il gioco è fatto.

Al termine di tutte le operazioni, l’installazione è completata

Selezionando il tasto Get started, si passa alla prima configurazione del progetto. Il tutto viene spiegato in maniera semplice dall’addon stesso e senza particolari problemi:

Seguiamo i passi e configuriamo un progetto di prova. Supponiamo di crearne uno nuovo: GEO-TASK.

Andiamo quindi a creare i campi custom su cui saranno poi memorizzati i geodati.

Una volta definiti, andiamo a configurare l’addon, specificando i nuovi campi appena creati:

Quindi andiamo a settare longitudine e latitudine della sede centrale. Serve all’addon per indicare il centro della mappa.

In questo esempio ho indicato le coordinate di Piazza Maggiore a Bologna 🙂

Suggerimento

Quando si aggiunge un nuovo campo custom, o in presenza di altre operazioni quali la modifica di addon, si consiglia sempre di eseguire l’operazione di  re-index:

Adesso siamo pronti ad usare l’addon. Andiamo sulla dashboard ed aggiungiamo un gadget:

Andiamo a creare una nuova ISSUE e vediamo i risultati. Possiamo posizionarci sulla mappa e successivamente creare direttamente da li la nosytra ISSUE.

Inseriamo tutti i parametri

Possiamo poi andare a filtrare andando ad impostare opportuni filtri sulle ISSUE, come mostrato in figura

Conclusioni

Abbiamo visto la prova su strada dell’addon. Il risultato è notevole. Provate ad immaginare una gestione in cui si abbisogna di una georeferenziazione, e che con un semplice click sulla mappa si arrivi a generare la issue. La semplicità di utilizzo è evidente :-).

Asset manager in azienda

In questo post iniziamo a vedere come possiamo utilizzare i prodotti della Atlassian per la gestione di un ASSET Manager. Riprendiamo quanto già esposto in questo post e lo estendiamo alla luce di quanto ha riportato la Atlassian nel proprio blog. Da ciò, mi sono ispirato per cercare di trovare una versione …. lite, in modo da poterlo usare anche in realtà un pò più piccole o non tanto grandi :-). Si tratta del primo di una serie di post dedicati all’argomento.

Di cosa abbiamo bisogno

Riassumiamo brevemente quanto abbiamo bisogno:

• JIRA
• JIRA Service Desk
• Confluence
• Gliffy

JIRA  – Fornisce la struttura base su cui memorizzare le informazioni dei vari strumenti.

JIRA Service Desk – Sarà utilizzato per gestire il supporto per i vari oggetti dell’asset. Sarà prevalentemente utilizzato come supporto.

Confluence – Sarà usato per creare la documentazione di corredo per i vari oggetti dell’asset. In particolare sarà utile per documentare il tutto.

Gliffy – Sarà utilizzato per creare i grafici per descrivere meglio la situazione aziendale.

In questo primo post andremo a vedere come configurare la parte JIRA.

 JIRA – Andiamo in dettaglio

Iniziamo ad implementare l’asset manager. Il primo passo è di creare un progetto su cui andremo a creare gli oggetti. Come?? semplice :-). Le varie Issue saranno gli asset veri e propri. Es. Creeremo una issue per classificare uno specifico notebook, uno specifico server, uno specifico monitor, etc etc etc.

Negli esempi della Atlassian, viene suggerito di chiamare il progetto TAG . Si tratta di un simple tracking project, non ci serve molto di più.

Una volta creato il progetto, occorre definire le ISSUE TYPE  cui il progetto farà riferimento. Che cosa significa questo? semplicemente andiamo a definire le issue come se si trattasse dei vari componenti dell’ASSET: computer, tablet, stampanti, monitor, server, etc etc etc etc. Nel nostro esempio abbiamo definito i seguenti tipi:

Per fare questo, occorre andare nella sezione di amministrazione del progetto TAG, quindi accedere alla sezione che gestisce gli Issue Type e definire i nuovi tipi di issue, associando loro una icona opportuna:

Una volta che gli issue type sono definiti, associarli ad un opportuno insieme (nel nostro caso ASSET Issue Type), che sarà poi associato al progetto TAG (come mostrato in figura).

A questo punto, definiamo quali campi andremo a visualizzare nei vari screen, ovvero nelle varie schermate che sono richiamate dalle procedure di JIRA. Ad Esempio, quando creiamo una nuova issue o quando la andiamo a modificare. Andiamo a settare i campi dello screen, come mostrato in figura:

Selezionando uno qualsiasi degli screen, possiamo selezionare quali campi vogliamo impostare:

Il prossimo passo è quello di definire il Workflow  cui farà riferimento il progetto TAG. Andiamo quindi a creare un nuovo workflow, selezionando un esempio di come potrebbe essere gestito un Asset in maniera molto semplice e rapida. Chiaramente è modificabile per ogni tipo di esigenza, da quella che richiede anche la possibilità di semplificare il workflow, a quella che richiede di complicarlo per gestire delle situazioni particolari.

In questo caso, abbiamo i seguenti stati:

• Richiesta  –  L’utente fa richiesta
• Disponibile  –  L’asset è disponibile
• Assegnato  –  L’asset è stato assegnato all’utente
• Supporto  –  L’asset è sotto supporto per riparazione o manutenzione
• Dismissione  –  L’asset è obsoleto e deve essere dismesso
• Dismesso  –  L’asset è stato dismesso e può essere rimosso dal magazzino.

Una volta creato il Workflow, lo possiamo associare al progetto, attivandolo e rendendolo operativo. Il tutto molto facilmente :-).

Se abbiamo a disposizione l’addon JIRA AGILE, possiamo anche aggiungere la AGILE KanBan Board, per poter gestire, in modo visuale, la gestione degli stati :-). La seguente immagine fornisce un esempio:

Qui ho aggiunto solo alcuni esempi, per fornire una idea. Immaginatevelo con i vari asset. Per aziende molto grandi, non è proponibile utilizzare questa soluzione, ma per piccole e medie realtà, questa soluzione è assolutamente valida. In aggiunta, se si fa uso delle Componenti, possiamo anche ottenere delle visualizzazioni dedicate per tipologia di Asset :-). Basta lasciare correre la fantasia.

Conclusione

In questo primo post abbiamo visto come configurare il progetto JIRA per poter gestire i dati degli asset. Nel prossimo post andremo ad usarlo e successivamente passeremo a configurare la seconda parte: JIRA Service Desk per gestire eventuali segnalazioni a chi gestisce l’asset in azienda.

Mapit for JIRA

Oggi parliamo di un addon … interesante, che introduce una geolocalizzazione su JIRA 🙂

Andiamo in dettaglio

Questo addon consente di poter utilizzare JIRA per la gestione di progetto, o di situazioni particolari, in cui è necessario avere a disposizione una geolocalizzazione

Questo fa si che JIRA può essere utilizzato anche in situazioni NON IT, dove non è coinvolto lo sviluppo software. Possiamo anche gestire situazioni in cui, oltre a segnalare un problema, abbiamo la necessità di indicare … DOVE si trova localizzato il problema. Immaginate una situazione in cui si deve indicare esattamente dove eseguire l’intervento. Magari una situazione in cui si deve indicare che l’intervento deve essere eseguito su di uno degli uffici, negozi 🙂

Conclusioni

L’addon promette bene. Nel prossimo post andremo a fare una prova su strada per saggiarne le performance.

Ultime novità

In questo post andremo a riassumere alcune delle ultime novità per Confluence e JIRA, con qualche piccola puntatina sugli altri prodotti della Atlassian 🙂

Confluence

Su Confluence segnaliamo l’aggiornamento della macro Roadmap, di cui abbiamo già parlato. Adesso viene data la possibilità di poter visualizzare le roadmap in settimane o mesi.

Altro aggiornamento, che riguarda un post su cui abbiamo approfondito un addon molto interessante, riguarda il “ricordare” l’ultima selezione del checkbox notify.

Per chi dispone della versione Cloud, questi aggiornamenti sono disponibili dal 10 di maggio 2015.

Altra segnalazione riguarda la possibilità di poter eseguire delle “query” ad hoc su Confluence, attraverso il CQL, sulle page properties o sulle Label. La macro è stata estesa in modo da poter eseguire delle interrogazioni molto più mirate ed in maniera assai più semplice, come mostrato in figura.

I metadati delle pagine Confluence sono stati …. spostati ed adesso sono visibili in cima alle pagine stesse.

Queste ultime modifiche saranno disponibili dopo gli aggiornamenti del 17 maggio 2015.

JIRA

Su JIRA sono state riportate le seguenti migliorie 🙂

La Basic Search di JIRA è stata estesa in modo da consentire l’interrogazione per lo SPRINT FIELD

Segnaliamo anche il seguente gadget per realizzare il seguente grafico bidimensionale

Conclusioni

Abbiamo visto alcune novità. Nei prossimi post andremo ad approfondirne alcune 🙂