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.

Automatizziamo le operazioni

In questo post andremo a vedere come possiamo automatizzare alcune operazioni, analizzando il seguente addon per Confluence Cloud.

Bulk Action Tool

Si tratta di un addon molto interessante, in quanto consente di poter automatizzare azioni … ripetitive 🙂

In particolare possiamo automatizzare le operazioni su Watch

sulla gestione delle etichette

e sulla gestione delle pagine, in particolare su Move/Delete page

Alcune considerazioni

Ci terrei a soffermarmi un istante su alcune considerazioni. Questi addon sono importatissimi in quanto consentono, agli utenti, di poter velocizzare la propria operatività. Occorre tenere conto che, come già indicato in questo mio post, non sono presenti molte funzioni su ,Confluence e/o su JIRA, che consentono di centralizzare determinate operazioni. Il più delle volte occorre diventare matti per poter automatizzare il tutto.

Conclusioni

Abbiamo visto un addon interessante. Nei prossimi post, andremo ad eseguire una prova su strada, dove andremo a saggiare le potenzialità :-).

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.

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.

Organizzare un LOG Diary

In questo post, andremo a vedere come organizzare un LOG Diary con Confluence, in maniera molto semplice e pratica.

Procediamo

Per la realizzazione, andiamo a sfruttare il componente BLOG di Confluence. Vediamo come 🙂

Dato che per ogni space è possibile creare un blog, il mio consiglio è il seguente:

• Se si tratta delle proprie attività, consiglio di sfruttare i Personal Space, che Confluence mette a disposizione;
• Se si tratta di attività specifiche, cui più persone possono mettere mano, allora conviene dedicare uno space dedicato, in cui raccogliere tutte le informazioni del progetto/attività.

A questo punto, una volta scelto dove posizionare il BLOG, si procede come segue. Per ogni giornata di lavoro, si genera un BLOG post, in cui andare a segnare tutto ciò che è accaduto, le attività svolte, risultato di riunioni, etc etc etc. In particolare, TUTTO 🙂

Per facilitare il tutto, conviene applicare lo stesso template a tutti i post :-), come il seguente esempio:

dove abbiamo una organizzazione molto più schematica e di semplice lettura. Infatti:

• Riassunto delle attività della giornata, consente di poter avere un quadro completo delle attività svolte, senza grossi problemi e di facile lettura. Riusciamo ad avere il quadro delle ore lavorate, dove abbiamo lavorato, senza entrare nel dettaglio. In questo caso non ci serve il dettaglio.
• Task definiti nella giornata, raccoglie tutti i task che si sono generati, a seguito di altri lavori svolti nella giornata e che devono essere svolti nei prossimi giorni. A tale proposito, ci aiuta la funzione dei task che Confluence ci mette a disposizione. 
• Nella ultima sezione, abbiamo l’esplicitazione del dettaglio delle attività vere e proprie, che sono state svolte. Qui trova posto il dettaglio di tutto, ovvero delle segnalazioni ricevute, dei task eseguiti, delle attività programmate, riunioni, link ad altre pagine, istruzioni, risoluzioni a problemi riscontrati, etc etc.

Che cosa abbiamo quindi?

Quello che otteniamo, una volta compilato, è una situazione in cui abbiamo il riassunto delle operazioni. Sfruttando le potenzialità e le funzionalità stesse di Confluence (in particolare la riocerca), abbiamo la possibilità di rintracciare facilmente i fatti di una specifica giornata, rintracciare un fatto specifico, una soluzione applicata. Il vantaggio non è indifferente.

Riassumendo:

• facilità di compilazione di consuntivi ore
• situazione sotto controllo SEMPRE
• dettaglio di attività
• tracciatura di fatti
• etc etc etc 🙂

Conclusioni

Abbiamo visto un sistema semplice per eseguire una tracciatura delle attività in Confluence, sfruttando delle funzionalità standard (sia su versione server che su versione cloud) e verificando come poter ottenere un grande vantaggio,  anche se per il momento, per la funzionalità BLOG, non esiste la possibilità di poter impostare dei template, come riportato un un mio precedente post, anche se la Atlassian sta lavorando su questa funzionalità, segnalando il crescente interesse da parte degli utilizzatori di Confluence. Attendiamo i prossimi rilasci.

Una piccola novità

Andiamo ad esaminare una piccola novità introdotta sulla sulla Roadmap macro, esaminata in precedenza in questo post e successivamente testato in questo post.

Vediamo la novità

Riprendiamo l’esempio, che avevamo fatto durante il test su … strada 🙂

Allora era possibile solo poter visualizzare con cadenza mensile. Adesso possiamo modificare la visualizzazione in modo da avere una cadenza settimanale. Questo rende la roadmap molto più dettagliata :-). Andiamo a vedere come partendo dall’esempio:

In alto a destra è presente una combo view by , dove  possibile specificare la cadenza. Passiamo alla visualizzazione settimanale ed otteniamo:

molto più dettagliata. In questo modo possiamo realizzare delle rappresentazioni di Roadmap più dettagliate, più semplici, anche per intervalli più piccoli (se abbiamo delle roadmap di qualche settimana, possiamo rappresentarle senza alcun problema).

Conclusioni

Abbiamo una piccola modifica, che ci aiuta nella rappresentazione delle roadmap. Questo ci consente di poter fare delle roadmap molto più semplici e dettagliate.

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 🙂

Visualizziamo numeri

In questo post sarà mostrato come poter utilizzare Confluence per realizzare delle semplici statistiche. Si tratta di un semplice esempio di uso dedicato alla realizzazione di dashboard, che possono sempre aiutarci nel nostro lavoro.

Di cosa abbiamo bisogno?

Quello di cui abbiamo bisogno è:

• Confluence (versione cloud)
• SQL Play
• Database MySql, per fare tutte le prove di cui abbiamo bisogno. Per tutte le nostre prove, utilizzeremo db4free, un sito che gratuitamente mette a disposizione database mysql di test, attraverso eseguire dei test.

Andiamo in dettaglio

In questo post andremo a vedere un semplice esempio di come visualizzare alcune informazioni. IN questo caso supponiamo di andare a visualizzare delle semplici statistiche sui miei consumi di benzina 🙂

A tale scopo, ho creato un semplice DB su db4free, dove ho riportato alcuni semplici dati.

Sfruttando le potenzialità dell’addon SQL Play, ho creato il contesto verso tale database, quindi ho creato la query per visualizzare i dati.

A questo punto creiamo la pagina di prova 🙂

Ovviamente si tratta di dati di esempio. 🙂

Conclusioni

Abbiamo visto come inserire delle semplici statistiche da un database remoto. Possiamo a questo punto creare delle dashboard che, leggendo le informazioni da un db remoto, visualizzano i risultati direttamente sulle pagine di Confluence.

Inseriamo dei grafici

In questo post andremo a vedere come inserire dei grafici su di una pagina di Confluence Cloud. Non si tratta della macro chart, che Confluence mette a disposizione, ma di grafici creati su dati esterni.

Di cosa abbiamo bisogno

Non sono necessarie molte componenti. Cerchiamo di riassumerle 🙂

• Confluence Cloud
• CYO Create-Your-Own addon per Confluence Cloud
• Google Charts
• Google Spreadsheet

Confluence sarà il nostro contenitore, che fungerà da punto centrale di tutte le informazioni. CYO, addon già esaminato in diverse altre occasioni, dove ne abbiamo saggiato la potenza, ci consente di poter fare da tramite per poter aggiungere i grafici su Confluence.

Google Spreadsheet sarà la nostra sorgente dati, mentre useremo Google Charts per poter creare i grafici :-).

Procediamo

Come prima cosa, impostiamo i dati su di un google spreadsheet. Nel nostro esempio inseriamo i dati dei rifornimento di benzina che ho sostenuto da gennaio 2015 in avanti.

Una volta impostato il google spreadsheet, possiamo inserirlo sulla pagina, come già spiegato su questo post, ma adesso possiamo anche fare in maniera tale di poter generare dei grafici :-P. Andiamo ad esaminare come.

Sempre attraverso lo stesso sistema utilizzato, possiamo aggiungere anche un grafico, sfruttando le potenzialità che Google Charts mette a disposizione.

Semplicemente andiamo ad aggiungere il codice javascript per poter richiamare le API di google, eseguendo una banale query sullo spreadsheet precedentemente impostato.

La query che si imposta si basa sulle colonne del foglio elettronico (colonne che sono nominate da A, B, C, … Z, etc.). Fare riferimento al link per maggiori dettagli.

Basandosi sull’esempio indicato sopra, la query ha la seguente struttura

select B, sum(C) where C>0 group by B

ovvero cerchiamo di identificare i consumi per mese :-P.

Una volta impostata la macro nella pagina confluence, come mostrato in figura

Il risultato che otteniamo è il seguente:

Conclusioni

Abbiamo visto come collegare dei grafici, interfacciando le API che google mette a disposizione degli utenti, e utilizzando gli spreadsheet come fonte dati. Nei prossimi post, cercheremo di approfondire l’argomento, cercando di portare ulteriori novità 🙂