Esempio di utilizzo

In questo post vedremo un esempio di come poter gestire un lavoro basato su un monte ore. Questo è un esempio di come realizzare il tutto sfruttando i prodotti della Atlassian.

Di cosa abbiamo bisogno?

• JIRA, per tracciare le attività e i tempi di esecuzione;
• CONFLUENCE, per dettagliare le attività svolte, documentare il tutto e e fornire dei dettagli operativi

Vediamo nel dettaglio le due parti da configurare.

 JIRA

Cominciamo da JIRA. Sfruttando il concetto di TASK e SUBTASK , procediamo come segue:

• Creiamo un progetto ad hoc, per tracciare le attività del nostro cliente;
• Creiamo un TASK. Ci servirà come contenitore generale per tutte le attività che andremo a svolgere nel nostro Monte Ore;
• Creeremo una serie di SUBTASK , uno per ogni attività che andiamo ad eseguire, in cui dettaglieremo ogni singola attività svolta nell’ambito del monte ore.

Sul TASK andremo ad inserire il totale del monte ore acquistato dal cliente (Dettaglio: Sezione Time Tracking). 

Sui SUBTASK , inseriremo, sia come ore stimate (Original Estimate) che come ore effettive (Work LOG), il totale delle ore che sono state dedicate alla attività. Come sempre, inseriamo sui commenti, tutte le annotazioni che riteniamo necessarie, quali le operazioni che sono state svolte, i risultati delle analisi, etc. Nella description, inseriremo la richiesta che è stata operata da Cliente.

Risultato

Con questa configurazione, controlliamo sempre il monte ore residuo in maniera semplice. Basta semplicemente che teniamo sott’occhio il Time Tracking, del TASK  generale. Nei vari SUBTASK  abbiamo il dettaglio di ogni operazione di supporto richiesta dal cliente, con tutto ciò che ne riguarda. Con questo modo di procedere, abbiamo la possibilità di gestire il monte ore, tenere sotto controllo e documentare le attività svolte, e monitorare i tempi di reazione. In questo modo possiamo anche consigliare il cliente su come scegliere il monte ore adeguato per le sue esigenze.

Confluence

Passiamo adesso a configurare Confluence. Come prima cosa, seguendo i consigli del post (come creare una scheda del cliente in Confluence), possiamo creare una sottopagina, con le indicazioni del progetto (seguendo la stessa logica) e successivamente, nella pagina del progetto Monte Ore, indicare la cronologia delle attività dettagliate. In questo caso abbiamo diverse possibilità:

• Space, in cui inseririamo le informazioni del cliente. Qui andremo ad inserire tutte le altre informazioni;
• Blog dello space. Qui andiamo ad indichicare le attività svolte di una o più giornate. Consiglio il blog in quanto più comodo per redigere il dettaglio delle attività. Ci sono poi delle macro che consentono di poter visualizzare gli ultimi post e danno evidenza delle ultime attività.
• Dedichiamo una pagina riassuntiva per tutti i monte ore acquistati e tante sottopagine per ogni singolo monte ore acquistato. Sulla pagina principale abbiamo i riassunto di tutti i monte ore. Sulla sottopagina abbiamo il dettaglio dello specifico monteore. In questa pagina andremo ad inserire l’elenco dei SUBTASK del TASK principale, di modo da avere la situazione documentata.

Una variante potrebbe essere quella di avere delle singole pagine per intervento. Questo potrebbe risultare più comodo del BLOG. Teniamo conto che, come indicato in questo post, non esiste ancora la possibilità di poter associare un TEMPLATE ad un post blog

Questo è il risultato che si può arrivare ad ottenere

 Suggerimento

Una ulteriore operazione che si può fare, è quella di mettere a disposizione degli utenti un ulteriore strumento, ovvero un Knowledge Base, ovvero uno space dove sono raccolte una sequenza di informazioni, secondo un determinato stile, che consentono di poter mettere a disposizione conoscenza

Conclusioni

Abbiamo visto, in questo post, come possiamo realizzare un sistema di gestione monte ore, sfruttando le funzionalità che Confluence e JIRA mettono a disposizione. Questo è solo uno dei tantissimi esempi di come possiamo sfruttare le potenzialità di questi prodotti e di come possiamo combinarli per ….. soddisfare le nostre necessità. Ma come sempre, questo non è altro che un punto di partenza per altre idee. La fantasia è il nostro solo limite 🙂

Atlassian Cloud

La Atlassian, nel sul blog, ha informato che sarà reso operativo il servizio di Atlassian Cloud. Con questo servizio metteranno a disposizione tutti i prodotti della Atlassian nel cloud.

Ma il servizio onDemand?

Non sparisce. Semplicemente cambia nome da onDemand a Cloud. Rendono i servizi migliori e più performanti.

Tutti coloro che dispongono del servizio onDemand vedranno semplicemente sparire l’etichetta onDemand a favore dell’etichetta Cloud, ma continueranno ad avere gli stessi servizi, con una maggiore reattività.

Maggiori raggiagli sui servizi offerti (che sono praticamente gli stessi di onDemand) alla seguente pagina di documentazione.

Conclusioni

Prepariamoci a delle belle sorprese. 🙂

JIRA e le sue tabelle

In questo post, proseguiamo quanto iniziato su questo post, dove abbiamo fatto una breve panoramica delle tabelle di Confluence.

In questo caso, proviamo ad eseguire la stessa operazione presentata nel post precedente, ma facendo riferimento alle tabelle di JIRA. La seguente immagine riassume alcune delle tabelle di JIRA. Si rimanda alla sezione Reference per tutte le indicazioni sul caso.

Precauzioni

Si ribadiscono le stesse identiche precauzioni che sono state indicate nel precedente post. Fate sempre un backup dei dati, prima di procedere con qualsiasi operazione. In questo modo potete essere sicuri di poter operare in tutta sicurezza.

Iniziamo 🙂

Cerchiamo di impostare un avatar di default differente da quello preimpostato. Partiamo da questa situazione:

Le tabelle che andiamo a referenziate sono le seguenti:

• cwd_user – Tabella contenente le informazioni degli utenti
• avatar – contenente gli avatar standard
• propertyentry – contenente le associazioni da utente ed avatar utilizzato
• propertynumber – contenente l’associazione con l’avatar collegato all’utente

Procediamo con la modifica

Aggiungiamo il nuovo avatar. Il file va caricato nella directory:

<Install-Dir>Atlassian-JiraWEBINFClassesAvatar

Supponiamo di utilizzare sempre l’icona del pinguino 🙂

Punto di attenzione. A differenza di Confluence, JIRA ha la necessità di avere anche una seconda icona, dimensione 24×24, la metà rispetto alla dimensione dell’avatar che si inserisce, ovvero 48×48, che viene referenziato e mostrato in alto a destra. Predisporre quindi un secondo avatar, nome pari a small_<nome_del_file_nuovo_avatar>.png e memorizzarlo nella stessa directory.

Quindi aggiungiamo un nuovo record, alla tabella avatar, con le indicazioni dell’icona nuova

Dalla tabella cwd_user, identifichiamo l’utente in questione:

Dalla propertyentry ci ricaviamo l’ID per determinare la proprietà da andare a modificare, cercando per ENTITY_ID = ID USER e PROPERTY_KEY = ‘user.avatar.id’:

Quindi dalla propertynumber, ci ricaviamo l’ID dell’avatar utilizzato.

Inseriamo, nel campo propertyvalue, l’ID del nuovo avatar di default, e questo è il risultato:

Conclusioni

Con questo sistema riusciamo ad impostare il nuovo avatar di default in maniera semplice. Questo ci consente di poter eseguire una semplice modifica alla installazione, sostituendo gli avatar in modo semplice.

Se si vuole aggiungere un avatar non di default?

Fattibile, ma occorre agire da tutt’altra parte. In questo caso si dovrebbe memorizzare il file del nuovo avatar in altra directory, ovvero:

<JIRA-Home-dir>dataavatars

e si memorizzano in vari formati, principalmente il formato 48×48 ed il formato 24×24, che servono principalmente per tutte le funzionalità. La configurazione delle tabelle è la medesima. Il nome del file, come per il precedente esempio, deve essere preceduto dal nuovo ID assegnato alla tabella Avatar. Nei prossimi post vedremo altre informazioni sulle tabelle di JIRA.

Scaviamo in profondità

In questo post andremo a vedere, con alcuni esempi, come possiamo accedere ai dati di Confluence e JIRA, lavorando direttamente su DB. In particolare vedremo alcuni esempi di come sono memorizzate le informazioni. In figura vediamo lo schema delle tabelle di Confluence.

Perché accedere ai dati?

Prima di iniziare ad esplorare le tabelle dei due sistemi, conviene porsi una domanda fondamentale: Perché dobbiamo accedere direttamente ai dati del DB? Quale è la necessità?

Uno dei motivi più importanti è sicuramente quello di dover accedere ad informazioni a cui non si avrebbe altrimenti accesso, oppure il dover eseguire una operazione massiva. Questo perché non sempre è possibile eseguire una operazione su di una grossa mole di dati, in quanto Confluence/JIRA non la consentono, come ribadito in altri post di questo blog. Fino a quando non saranno disponibili delle funzionalità di un certo tipo, occorre dover agire direttamente da DB. In aggiunta, queste informazioni sono sicuramente utili a coloro che vogliono sviluppare addon per i prodotti Atlassian 🙂

Precauzioni

Prima di agire, occorre sempre che siano prese delle semplici precauzioni. Il motivo mi sembra abbastanza semplice: Quando si lavora direttamente su DB, è abbastanza facile arrecare danni. Di conseguenza, sempre meglio avere un backup dei dati/tabelle/DB intero prima di procedere con le modifiche.

Il mio consiglio è sempre quello di avere a disposizione un backup del DB completo + una copia delle tabelle su cui si agisce, prima di procedere con qualsiasi operazione.

Un primo esempio

Supponiamo che si voglia modificare gli avatar standard, con un avatar differente (i motivi possono essere qualsiasi: Marketing aziendale,  impostare un avatar di default più carino, etc).

Al momento, solo gli utenti possono modificare il proprio avatar. A livello di amministrazione, non è possibile eseguire tale operazione. La precedente immagine mostra dove è possibile eseguire tale operazione. Adesso vediamo come è possibile aggirare tale limitazione, semplicemente andando a lavorare su DB.

In prima battuta esaminiamo le tabelle dove sono contenute le informazioni delle utenze. In particolare faremo riferimento a:

• cwd_user – Tabella contenente le informazioni degli utenti che sono stati configurati in Confluence.
• cwd_group – Tabella contenente le informazioni dei gruppi definiti su Confluence.
• os_propertyentry – Tabella contenente anche le informazioni degli avatar.
• user_mapping – Tabella contenente la corrispondenza uid – nome utente.

La tabella che ci interessa in particolare è l’ultima. Dobbiamo andare a cercare le informazioni degli avatar, utilizzando questa query:

Come si vede dalla precedente immagine, quello che dobbiamo andare a cercare è il campo String_val. In questo campo è presente la localizzazione dell’avatar. In questo caso ho assegnato un avatar di default. 🙂 Nel campo Entity_name abbiamo la userid. Come possiamo vedere è abbastanza ….. criptata. Come facciamo a decodificarla? Il giro è il seguente:

• Dalla tabella os_propertyentry abbiamo le indicazioni del path della immagine
• Dalla tabella user_mapping abbiamo le indicazioni dell’uid dell’utente
• Dalla tabella cwd_user abbiamo il nome dell’utente.

Le seguenti immagini chiariscono il tutto: Dall’ID identifichiamo l’utente

Di conseguenza, per modificare l’avatar dell’utente admin (in questo caso), possiamo semplicemente modificare il path e andare ad assegnarne uno nuovo. Supponiamo di creare una sottodirectory nel path utilizzato da Confluence per gestire gli avatar di default, ovvero:

<Install_dir_Confluence>confluenceimagesiconsprofilepic

supponiamo di chiamarla Demoprofile e di memorizzare il seguente avatar:

Eseguire il restart del servizio Confluence e, come per magia, il risultato sarà il seguente:

Conclusioni

Abbiamo visto un esempio di come si può modificare il database per modificare gli avatar degli utenti di Confluence. Questo esempio può essere utilizzato anche per le installazioni per cui gli utenti sono presi da LDAP e non sono solo utenti locali di Confluence.  Nei prossimi post vedremo altri esempi di come si può accedere ai dati e …. vedere altre informazioni.

Proseguiamo il nostro piccolo tour nei vari plugin di Confluence e Jira onDemand, iniziato in questo post.

Confluence

Viene data la possibilità di poter visualizzare delle formule matematiche attraverso Beautiful Math for Confluence.

Addon utile per coloro che fanno parecchio uso di formule matematiche o che devono usare LaTeX, ma non è il solo. Segnalo anche il plugin Bulk Action Tools, che rappresenta una vera sopresa :-). SI tratta di un addon che consente di centralizzare delle azioni altrimenti brigose (tipico termine bolognese che sta ad indicare azioni che richiedono molto tempo e sono noiose)

A volte non se ne intravede l’importanza, ma queste operazioni sono abbastanza noiose se si utilizzano le funzionalità standard. Questo perché tali funzionalità sono letteralmente sparse tra le varie componenti. Come già ribadito in questo post, la centralizzazione di certe operazioni è importante, sopratutto quando si riesce a semplificare la vita degli utenti rendendo le funzioni molto più agevoli :-D.

Non meno importante è la funzionalità di Copy Space. Funzione utilizzatissima nella versione server (ve lo posso assicurare).

Anche se non è meno importante del Copy Page Tree, il quale consente di poter copiare solo porzioni di space, in particolare una pagina e la sue sottopagine.

Chiudiamo questa carrellata di Addons con il Balsamiq Mockups for Confluence. Già disponibile nella versione Server, consente di poter realizzare dei mockups per qualsiasi ambito (ad es. mockups di applicazioni, schemi, semplici workflow, etc.)

JIRA

Iniziamo citando JQL Pro, un addon che consente estende, con ulteriori funzionalità, il JQL di JIRA

Proseguiamo il nostro tour citando l’addon Plain Tasks – Simple Todo Lists, un semplice addon che consente di poter semplificare la complessità di JIRA e trasformarla in un a più semplice ToDo List. Questo potrebbe essere utile per poter mettere a disposizione di utenti non avanzati, le funzionalità avanzate di JIRA.

Chiudiamo la carrellata degli addon di JIRA con Automated Log Work for JIRA. Si tratta di un addon che consente di poter automatizzare la fase di worklog. Al momento JIRA consente un inserimento manuale, mentre attraverso questo addon, è possibile automatizzare tale fase e delegare a JIRA la fase di conteggio del tempo dedicato ad ogni task.

Conclusioni

Come possiamo osservare, anche gli addon della versione Confluence/JIRA onDemand iniziano a prendere piede e comunciano a fornire funzionalità molto avanzate. Le sorprese non sono finite qui. Nei prossimi post andremo ad esaminare nel dettaglio questi addon.

Nuove Features 2.0

Prosegue, in questo post, la panoramica sulle funzionalità di JIRA Service Desk, già descritte nel primo post e proseguite nel successivo, dove è stata descritta la possibilità di poter utilizzare il JIRA Service Desk per gestire delle risorse riusabili.

Un passo indietro

Tramite questo Addon, si estende JIRA affinché possa divenire un sistema di Trouble Ticketing ma non solo. Attraverso l’uso di Confluence e dei suoi Addon, è possibile sfruttare JIRA per tracciare anche altri eventi e poter essere di supporto per i team di sviluppo.

Novità – Pagamento in base agli agenti

Viene rivisto il modello di pagamento in base agli utenti. Si inizia a distinguere tra tre ruoli ben distinti:

• Agenti, ovvero gli utenti che accedono al sistema e che si occupano di gestire le segnalazioni ricevute
• Clienti, ovvero coloro che inviano le segnaklazioni
• Admin, ovvero gli amministratori del sito

Il pagamento viene calcolato in base al numero di agenti (minimo 3) di cui si intende disporre. Ogni agente può gestire un numero di clienti illimitato.

Migliorato il Portale di accesso al JIRA Service Desk

Risulta migliorato il portale di accesso alle richieste. Questo non deve essere visto come un qualcosa di dedicato solo alle richieste IT (nuovo software da installare, problemi con le stampanti, etc), ma viene esteso anche ad altre problematiche/tipologie di richieste. In precedenza avevo già citato un esempio di come è possibile utilizzare questo addon per tracciare le risorse riusabili :-).

 Richieste via email

Viene migliorata e resa più semplice la funzionalità di generazione delle richieste via email. In questo modo, si facilita l’uso dello strumento anche per le persone che sono più abituate ad usare l’email. Pochi semplici passi e l’email viene configurata. JIRA dispone nativamente di questa funzionalità e l’addon consente di poterla configurare senza tanti problemi 🙂

 Migliorate le pagine di gestione

Sono state migliorate, e rese molto più semplici, le pagine di gestione e le pagine utilizzate dagli agenti per poter svolgere la propria mansione. In questo modo si aumenta e facilita la produttività degli Agenti.

Conclusioni

Un addon fenomenale. Non posso che consigliarlo per le piccole o grandi imprese che intendono crearsi un proprio sistema di Service Desk interno che, in maniera agevole e semplice, possa aiutare le persone a risolvere i piccoli e grandi problemi quotidiani.

JIRA Capture

In questo post andremo ad esaminare un addon di JIRA, molto utile per le sessioni di testing. JIRA CAPTURE. Nato come addon delle prime versioni di JIRA, fu succesivamente acquisito dalla Atlassian (insieme ad altri addon) e gli fu cambiato nome in JIRA Capture.

Nel dettaglio ….

Questo Addon consente di poter velocizzare i feedback e renderli molto più agevoli. Proviamo a descrivere uno scenario. Supponiamo di dover eseguire un test di un applicativo WEB. Supponiamo di aver identificato un punto in questo applicativo, in cui sia necessario un intervento (sia esso di manutenzione, correttivo o migliorativo. Come procediamo?

I passi sono semplici ma brigosi:

• Creare uno screenshot della pagina web
• Evidenziare il punto o i punti su cui si vuole eseguire l’intervento
• mail per il servizio di manutenzione o creazione del task su JIRA, se si dispone di quest’ultimo

Immaginate di doverlo ripetere diverse volte al giorno……

In che modo JIRA Capture ci aiuta?

Semplice. Automatizza questa operazione. 🙂 Si tratta di un componente della suite dei prodotti Atlassian, che si interfaccia su tutti i maggiori browser in circolazione e, una volta richiamato, esegue tutte le operazioni che ho descritto in precedenza ed attende solo che l’utente inserisca il testo del feedback che intende fornire.

Come evidenziato dalla precedente immagine, JIRA Capture mette a disposizione tutti gli strumenti per

• evidenziare i punti di intervento sullo screenshot
• inserire le annotazioni del caso
• Creare una issue nuova
• Accodare le informazioni ad una issue preesistente

Conclusioni

Si tratta di un valido strumento che aiuta nello sviluppo e nel fornire un feedback.  Nei prossimi post vedremo nel dettaglio il funzionamento e mostreremo un esempio di come si può utilizzare.

First Look

In questo post iniziamo ad esaminare un componente della Suite di Atlassian. FishEye.

Quale funzione svolge?

Fondamentalmente è il componente della suite che si interfaccia con il sistema di controllo versione del codice.

FishEye provides a read-only window into your Subversion, Perforce, CVS, Git, and Mercurial repositories, all in one place. Keep a pulse on everything about your code: Visualize and report on activity, integrate source with JIRA issues, and search for commits, files, revisions, or people

Si tratta di un applicativo WEB che si interfaccia al sistema di controllo versione del codice e, agganciandosi agli altri componenti della suite, consente di poter arrivare ad un controllo completo dello sviluppo.

Attraverso FiehEye è possibile tracciare, usando una unica interfaccia, tutte le variazioni al codice di un software. Non solo. Integrandosi con JIRA e eseguendo opportune azioni, è possibile agganciare le variazioni che sono state operate al codice alla Issue JIRA di pertinenza, senza fatiche estreme e senza dover eseguire chissà quale numero di azioni.

Come lo realizza?

Semplicemente inserendo il codice della issue JIRA nel testo della commit. Provo a chiarire meglio. FishEye, semplicemente, esegue un polling al database del controllo versione configurato. Quando identifica una azione di commit, verifica che cosa è stato riportato come descrizione. Se riconosce la issue JIRA, verifica se esiste nel JIRA collegato a FishEye ed esegue un aggiornamento affinché il codice modificato sia agganciato alla ISSUE.

Il risultato è la possibilità di poter avere il controllo completo dello sviluppo, semplicemente accedendo alla pagina di dettaglio della Issue di JIRA.

Infatti, l’operazione di aggiornamento che FishEye esegue, è quella di agganciare il codice alla issue e fai si che, accedendo alla pagina della Issue, si possa anche visionare il codice modificato e dove è stata eseguita la modifica.

Conclusioni

Vi lascio immaginare il risultato, ma quello che si ottiene, letteralmente, è il controllo completo dello sviluppo/manutenzione del codice. Gli sviluppatori e i project manager dispongono così di uno strumento avanzato per poter monitorare tutte le azioni che sono eseguite sul codice, consentendo anche di migliorare la produzione ma non solo.

FishEye non è solo questo, ma anche Code Review, attraverso uno strumento che viene fornito: Crucible.

Prossimi passi

Nei prossimi post, andremo a vedere nel dettaglio come realizzare questa integrazione, come poter eseguire una code review e come poter integrare tutti questi strumenti.

Data Center Deployment

The Data Center deployment option is designed for high availability and performance at scale when hosting our applications in your own data center.

In questo modo viene presentata la versione per Datacenter, rilasciata ad inizio settembre 2014, dei seguenti prodotti:

• Confluence
• Jira
• Stash (Beta)

studiata e predisposta per funzionare in ambienti datacenter per alte prestazioni, per alto numero di utenti e mission critical.

Questa versione dei prodotti Atlassian  e stata studiata in modo da poter fornire migliori performance, mettere le aziende in condizione di fornire un servizio sempre disponibile e fornire una buona scalabilita del prodotto.

Maggiori informazioni sono raccolte nel seguente video:

https://www.youtube.com/watch?v=Va9yGtqzb14

Conclusioni

Attendiamoci nuove sorprese dalla Atlassian. Sono sicuro che a breve ci saranno ulteriori novità. 🙂

Una bella novità

In questo post iniziamo a trattare una bella novità, proveniente dalla stessa Atlassian, che non smette mai di riservare delle sorprese. 🙂

Che cosa è?

JIRA Portfolio provides a single, accurate view for planning and managing initiatives across multiple teams and projects with ease.

Con queste parole viene definito l’addon, direttamente nella pagina dell’Atlassian Market. Consente di poter avere un quadro di insieme dei progetti, seguiti dai vari team di sviluppo, e di poter pianificare iniziative comune tra tutti, coordinare la gestione degli stessi.

Come?

Diamo una prima occhiata al video che la stessa Atlassian mette a disposizione sull’onnipresente youtube

dove sono riportate alcune dritte ed alcune indicazioni.

Conclusioni

Una buona presentazione per un bel addon. Nei prossimi post andremo ad esaminarlo nel dettaglio, per cercare di capire come può essere utilizzato.