Cloud o Server?

In questo primo post, di una serie dedicati all’argomento, andremo ad esaminare quali sono le differenze principali tra le due release dei prodotti. Obbiettivo è quello di fornire tutte le informazioni necessarie per operare la scelta migliore, in base alle esigenze.

Andiamo nel dettaglio

Credo che il primo punto da chiarire sia dare una prima spiegazione del perché di queste differenze. Innanzitutto, si tratta di situazioni differenti. Le versioni cloud (ex onDemand) sono gestite centralmente dal personale Atlassian e, di conseguenza, alcune funzionalità sono controllate direttamente da loro. Fornirle in mano ai clienti potrebbe essere controproducente in quanto potrebbe arrivare ad impattare altre installazioni.

Quali prodotti sono disponibili in cloud?

Prima di vedere le differenze, vediamo quali prodotti Atlassian sono disponibili.

• Confluence
• JIRA
• JIRA Service Desk
• JIRA Agile
• JIRA Portfolio
• Hipchat
• Bamboo

Adesso vediamo il dettaglio delle varie caratteristiche.

Il ruolo di System Administrator  viene ricoperto dal personale Atlassian. Di conseguenza, tutte le funzionalità che ruotano a tale ruolo, non sono disponibili.

I Backup schedulati non sono possibili, ma è comunque possibile eseguire una esportazione dati, al fine di riportarla su installazioni Server. I backup giornalieri NON sono consentiti in quanto il personale Atlassian li gestisce a livello centrale.

User Macro, HTML Macro e tutto ciò che impatta HTML (come macro standard) è disabilitato. Non esiste altra possibilità di poter abilitare tali addon su Cloud. Tuttavia, sono disponibili degli addon di terze parti che consentono di includere pagine web di siti terzi.

Mail Account e Mail server sono configurati e gestiti a livello centralizzato. Questo per gestire il tutto a livello centrale. Di conseguenza non è possibile customizzare questa parte.

Le versioni cloud utilizzano dei propri layout, ma non risulta possibile inserire delle variazioni ai CSS per la versione Cloud nè personalizzare il layout della versione cloud.

Non tutti gli addon sono disponibili per la versione Cloud. Il motivo è da ricercarsi nel fatto che, essendo la versione cloud centalizzata, la Atlassian ha modificato il come impostare gli addon per la soluzione cloud. Di conseguenza, anche lo sviluppo deve avvenire in maniera differente. Il seguente link aiuta a capire quali addon sono, al momento, disponibili. Come ho già avuto modo di evidenziare in post pubblicati, il numero di addon per la versione cloud è notevolmente aumentato nell’ultimo anno. Per la tecnologia da usare, fare riferimento ad Atlassian Connect. dedicheremo post a questo argomento.

Conclusioni

In questo post abbiamo dato una prima scorsa alle differenze tra le due installazioni, dove abbiamo visto quali operazioni sono possibili per una o per l’altra installazione. Questo aiuta sicuramente nella scelta del prodotto che si vuole e nel bugdet a disposizione. Nei prossimi post andremo a dettagliare le differenze, evidenziandole e commentandole.

Riferimenti

Pagina della documentazione Confluence disponibile qui.

Introduciamo Confluence

In questo post andremo ad introdurre Confluence nella gestione dei progetti, come elemento di supporto per la gestione dei progetti.

Partiamo subito

Il primo punto da chiarire è quello di definire quale è l’obbiettivo di Confluence, nella gestione di un progetto.

Confluence deve essere il contenitore dove posizionare TUTTE le informazioni del progetto. Ovvero:

• Analisi funzionali e tecniche
• Documentazioni tecniche di riferimento
• Verbali di riunioni, sia con il cliente che interne
• Piani di Battaglia, ovvero il dettaglio di come sviluppare
• Piani di rilascio delle varie versioni, spiegati in dettaglio.
• Documentazione
• CV del personale
• Template di documenti
• tutto ciò che si ritiene utile per lo svolgimento del progetto 🙂

Riassumendo, Confluence deve contenere tutte le informazioni del progetto, ovviamente opportunamente organizzate. 🙂 Se si inserisce alla rinfusa, non serve a nulla. Il tutto deve essere organizzato e fruibile da tutto il team di sviluppo.

Organizzazione

La prima cosa che consiglio è di predisporre uno Space per progetto. In questo modo si hanno due vantaggi subito:

• Tutte le informazioni sono presenti in un unico punto
• La gestione delle permission è molto semplice e veloce

e sono due vantaggi non indifferenti :-D.

Attuando questa organizzazione, si può sfruttare anche un addon molto importante, che consente di poter generare dei template di Space. Ho già descritto le potenzialità di questo addon su altri post. Le potenzialità sono enormi. Abbiamo la possibilità di creare un template di space, organizzarlo in base alle esigenze richieste o avere anche più template in base alla tipologia di progetti

Possiamo anche impostare i template per le varie pagine che comporranno lo Space del progetto. In questo modo, se dobbiamo redarre il verbale della riunione con il cliente, ci semplifichiamo notevolmente il lavoro.

Occorre sempre tenere a mente che Confluence deve essere uno strumento di aiuto nella conduzione del progetto, non un peso aggiuntivo che ci limita i movimenti e che non seguiamo perchè lo riteniamo un ….. problema.

Quindi sfruttiamo tutte le funzionalità per far si che sia un valido supporto. 🙂

Possiamo anche collegarci dei Database, in modo da visualizzare dei risultati di elaborazioni o delle statistiche o, molto più semplicemente, estrarre dei dati dal gestionale per poterli visualizzare e controllare. In questo modo, Confluence diventa il punto unico di gestione del progetto.

Colleghiamo Confluence e JIRA

Confluence e JIRA si collegano e si …. parlano senza alcun problema. Per far ciò occorre procedere con una pocedura particolare, che si chiama Application Link, che mette in comunicazione i due sistemi. In questo modo, possiamo vedere le issue JIRA anche in Confluence :-), come già mostrato nel post precedentemente pubblicato.

Dalla figura sopra riportata, si vede che è possibile collegare i due sistemi. Per maggiori dettagli si rimanda a questa pagina.

In questo modo, possiamo creare delle pagine ad hoc, dedicate alla documentazione di dettaglio di una release di bug fix. Possiamo avere un dettaglio maggiore o di livello funzionale, per i vari bug. In questo modo, su JIRA abbiamo il dettaglio tecnico (campo di database non scritto e corretto), mentre su Confluence possiamo avere il dettaglio funzionale (provincia non riportata nella anagrafica del cliente). Giusto per fare un esempio 🙂

Roadmap aka Piano di battaglia

La macro Roadmap è sicuramente utile per la gestione di un progetto. La macro offre la possibilità di poter rappresentare un vero e proprio piano di battaglia per gestire il progetto:

• rilasci
• avanzamento lavori
• componenti
• variazioni
• etc etc etc 🙂

Come già mostrato nei precedenti post, e dalla immagine sopra riportata, si può vedere che, grazie ad un colpo d’occhio, abbiamo il piano di battaglia, le azioni che saranno intraprese, gli sviluppi predisposti, e tutto ciò che serve.

Questo è di sicuro utile per gestire il tutto ed avere sempre sott’occhio la situazione.

Conclusione

Abbiamo visto in questo post come Confluence diventa, nell’ambito dello sviluppo di progetti, un punto centrale e nevralgico. Abbiamo un unico punto in cui reperire e concentrare le informazioni, senza dover impazzire a cercare il tutto. Verbali, documenti di analisi, documenti del cliente trovano perfettamente posto in Confluence e, grazie alle sue funzionalità, si rivela il più importante dei collaboratori di un progetto.

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.