Prendiamo una decisione ….

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

Andiamo in dettaglio

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

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

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

Un esempio potrebbe essere questo che segue:

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

In questo caso, abbiamo usato i seguenti componenti:

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

Carino, ma è il solo modo?

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

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

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

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

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

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

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

Un piccolo chiarimento

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

Conclusioni

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

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

Prova su strada

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

Procediamo

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

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

Triggers

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

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

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

Dalla stessa maschera video possiamo costruire anche i seguenti elementi:

• Conditions
• Validations
• Post-Functions

Vediamo come definire queste operazioni.

Conditions

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

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

Selezioniamo il gruppo degli utenti ed il gioco è fatto 🙂

Abbiamo così aggiunto una nuova condizione.

Validations

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

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

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

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

Post-Functions

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

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

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

Properties

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

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

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

Conclusioni

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

Test delle funzionalità descritte.

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

scrivere un articolo di approfondimento su WOrkflow.

Confronto tra addon

In questo post andremo a vedere un confronto tra addons che si occupano di aiutare a tracciare le ore di lavoro. Cercheremo di eseguire un confronto di funzionalità cercando, senza peccare di presunzione, di fornire indicazioni di come sia possibile usare in base alle proprie necessità/possibilità.

Quali addon confrontiamo?

La scelta ricade sui seguenti addon, di cui abbiamo già parlato:

• TimePO
• TEMPO
• Alternative a TEMPO, dove abbiamo censito altri addon che si occupano della gestione del time tracking

Cosa valutiamo? Cosa vogliamo fornire?

Cercheremo di capire come possiamo usare questi strumenti, se per uso di piccoli gruppi o di grandi gruppi di lavoro. Cercheremo anche di dare spazio ai liberi professionisti che, nello svolgere le loro attività, abbiano bisogno di strumenti dedicati o se può farne a meno. L’obbiettivo è di fornire lo strumento giusto al momento giusto 🙂

Cercheremo di fornire, più che un giudizio del tipo:

Questo addon è il migliore e di conseguenza predomina sugli altro ...

cercheremo di aiutare gli utenti nella scelta dell’addon giusto per il proprio lavoro. Molto spesso si parte dal presupposto  che l’addon leader di mercato sia quello più indicato, senza capire che in alcuni casi si va a spendere inutilmente un capitale per avere a disposizione un ….. mastodonte quando ci servono solo 2 funzionalità in croce.

Come procederemo?

In una serie di post andremo a vedere come possiamo eseguire questo confronto e arriveremo a dare le indicazioni per poter decidere cosa utilizzare e come.

Conclusioni

In questo post abbiamo accennato ad un argomento molto interessante. Si tratta di un lavoro che, in determinate circostanze, ci mette davanti ad una scelta molto importante e che, come spesso accade, ci lascia sempre con forti dubbi e paure circa la scelta giusta. Questi post hanno l’obbiettivo di dare delle indicazioni e dei consigli a tutti coloro che ne abbisognano, cercando di arrivare ad una scelta molto oculata.

Completiamo il test

In questo post andiamo a completare il test iniziato nei seguenti post:

• Userprofile – una alternativa
• Prova su strada #1
• Prova su strada #2

andando a collegare il sistema ad un LDAP.

Colleghiamo un LDAP

Completiamo questo tour collegandoci ad un LDAP e testiamo il comportamento. Per far cio, sfruttiamo un server open LDAP presente su internet. Googlando sono riuscito a trovare questo LDAP. Lo usiamo come ambiente di test e cercheremo di sfruttarlo in maniera tale da poter impostare il nostro addon. La seguente immagine mostra gli utenti che sono messi a disposizione.

che, come possiamo vedere meglio,attraverso un visualizzatore free LDAPAdmin, vediamo quali sono gli utenti che sono effettivamente disponibili:

Configuriamo il nostro LDAP su Confluence e poi, successivamente, andiamo a configurare l’addon affinché punti al nuovo LDAP (che chiamiamo con estrema fantasia LDAP server 😛

Il risultato è il seguente:

Conclusioni

Concludiamo questa carellata dell’addon della Appfusions. Si tratta di un addon che consente una buona integrazione con LDAP e che consente di poter sfruttare questa integrazione per il meglio. Nei prossimi post cercheremo di fornire un confronto tra i vari addon, con l’obbiettivo di fornire delle indicazioni per comprendere quale addon usare per l’uso richiesto 🙂

Come usare JIRA e Confluence per ……

Proseguiamo questa serie di articoli che tentano di spiegare come usare Confluence e JIRA per ulteriori scopi. In questo post andremo a vedere come usare Confluence e JIRA per ….. la gestione delle commesse.

Come possiamo organizzare il tutto

Possiamo pensare di impostare questa organizzazione. Come per la gestione degli Asset, vista nei precedenti post, possiamo sfruttare questo concetto e definire un Issue Type Commessa. In questo modo abbiamo la seguente situazione:

• Una identificazione univoca delle Commesse. Possiamo in questo modo facilmente ricercarle sfruttando la ricerca che JIRA le mette a disposizione 
• Possiamo gestirle con un opportuno Workflow, consentendo una gestione mirata 
• Possiamo anche sfruttare i subtask per gestire tutte le attività che ricadono sotto la commessa. Il vantaggio è di dettagliare in maniera quasi completa tutti i lavori svolti e di avere il totale delle ore dedicate. Con delle semplici interrogazioni possiamo tenere sotto controllo la spesa della commessa 
• Sfruttiamo Confluence per inserire la documentazione della commessa, specificando tutte le informazioni, cliente di riferimento, persona responsabile, lavori che devono ricadere su tale commessa 

Conclusioni

Abbiamo visto un semplice esempio di come possiamo sfruttare le funzionalità di JIRA e Confluence per gestire una situazione di tutti i giorni. Nei prossimi post andremo a vedere come realizzare una possibile implementazione.

Un nuovo addon per JIRA

In questo post andremo ad esaminare questo addon per JIRA. Links Hierarchy for JIRA & Agile

Di cosa si tratta?

Andando al sodo, questo addon consente di poter determinare e visualizzare la gerarchia delle varie Issue presenti su JIRA. Attraverso opportuni sistemi, consente di poter visualizzare la gerarchia delle linked issue

Consente di poter visualizzare in un attimo, direttamente dalla schermata di dettaglio della Issue, la situazione completa della stessa

sia attraverso le Agile Boards, come mostrato dalla precedente immagine.

Attraverso una opportuna Matrice di Tracciabilità, consente di poter visualizzare in maniera semplice il quadro della situazione.

senza dimenticare la possibilità di poter esportare su Excel

e senza dimenticare di segnalare una forte integrazione con JIRA, sopratutto nella parte di JQL, indispensabile per poter eseguire le interrogazioni:

Conclusioni

Abbiamo visto un addon molto importante. Quando si lavora con progetti complessi, le linked issue consentono di poter eseguire delle operazioni molto importanti ma, se non le andiamo a considerare in maniera opportuna, possiamo arrivare a delle complessità non indifferenti ed il disporre di tali strumenti, ci semplifica la vita 🙂

Come usare Confluence e JIRA per …..

Proseguiamo con lo scrivere questi post in cui cerchiamo di descrivere come poter usare Confluence e JIRA per poter realizzare un piccolo sistema di gestione degli ordini di acquisto/vendita.

Come possiamo realizzare il tutto?

Allo stesso modo con cui abbiamo realizzato il precedente esempio, possiamo utilizzare JIRA e JIRA Agile per gestire gli ordini di acquisto, vendita.

Ogni ISSUE JIRA rappresenta il nostro ordine di acquisto/vendita. Opportuni campi custom possono aiutare nella tracciatura dell’ordine vero e proprio.

Progetti separati, per tracciare gli ordini di acquisto e gli ordini di vendita può aiutare nello svolgere meglio questa attività.

Un opportuno Workflow, studiato per coprire tutte le casistiche possibili o necessarie per lo svolgimento della attività, può essere implementato ed associato ai progetti. In questo caso potrebbe essere necessario implementarne 2: uno per progetto

Successivamente, utilizzando la BOARD della JIRA Agile, possiamo consentire all’utente di poter meglio gestire i vari passaggi di stato, semplicemente spostando la ISSUE da una colonna all’altra.

In aggiunta, possiamo collegare anche delle informazioni relative alla società o alla natura dell’ordine. A tale scopo, Confluence ci viene in soccorso. In questo modo, possiamo sfruttare la potenza e la versatilità di Confluence per poter realizzare tutta la parte di documentazione necessaria. Queste informazioni possono essere poi collegate tramite campi custom

Risultato

Possiamo disporre di un sistema semplice per arrivare a gestire delle situazioni molto complesse, sfruttando la semplicità di questi strumenti. Nei prossimi post proveremo a sviluppare questa idea e cercheremo di realizzare un prototipo.

Prova su strada

In questo post andiamo ad eseguire la prova su strada dell’addon della Communardo. Cerchiamo di capire vantaggi, limiti e possibilità di utilizzo.

Installiamo

Procediamo sempre con ordine. Come prima cosa installiamo l’addon. Una volta trovato, selezioniamo free trial per poter procedere alla prima installazione sul nostro sistema. Una volta selezionato, si procede con la fase di installazione.

Attendiamo che siano eseguiti tutti i passi necessari…

Al termine della installazione, qualora non siamo loggati, viene richiesto di accedere al proprio account Atlassian, per poter generare la licenza TRIAL

L’addon stesso si occupa di connettersi per poter ottenere la licenza

Terminata questa fase l’addon è disponibile

Possiamo quindi procedere con la configurazione. Nella scheda dell’addon, troviamo tutte le indicazioni che ci aiutano ad iniziare a lavorare, come mostrato nella figura seguente:

Prova

Iniziamo a testare il nostro nuovo addon. Seguiamo le indicazioni, presenti nella precedente immagine, che ci forniscono un primo aiuto. Partiamo dalla configurazione generale, presente nella sezione di amministrazione, dove l’addon mette a disposizione due link, sulla barra sinistra dei menù

Partiamo con il definire i primi metadati attraverso la funzionalità Metadata fields. Una volta selezionato, ci accorgiamo che, come default, l’addon mette a disposizione dei metadati, come mostrato in figura.

Possiamo aggiungere i nostri metadati personalizzati come vogliamo :-). Selezionamo il tasto Add metadata field, per procedere. L’addon propone la seguente schermata:

Proviamo, in questa fase di test, ad aggiungere alcune informazioni di prova, quali:

• Progetto
• Ambito di lavoro

Definiamo quindi il Metadata set di appartenenza.

Dopo di che, lavoriamo su di uno space di test, che con grande fantasia è chiamato Communardo-test, e verifichiamo come possiamo accedere a tali informazioni e come ci possono essere utili.

La prima cosa che notiamo è la presenza di una icona, in alto a destra sulla pagina:

Se lo selezioniamo, accediamo alla gestione dei metadati, come mostrato nella figura successiva. Con nostra sorpresa, non riusciamo ad accedere subito a tali informazioni.

Dobbiamo prima procedere con la configurazione sulle opzioni dello space, prima di poter procedere. Andiamo nella sezione dei Medatada set e selezioniamo l’ultimo inserito:

Salviamo ed il gioco è fatto. Adesso i metadati sono pronti ad essere usati. Se aggiungiamo l’apposita macro nella pagina di prova e andiamo a visualizzarla, questo è il risultato che otteniamo.

Per inserire i valori semplicemente andiamo a selezionare il tasto in alto a destra, già evidenziato nelle immagini precedenti e vediamo quanto segue:

Inseriamo i dati e selezioniamo il tasto Salva. L’immagine che segue mostra il risultato.

Si segnala inoltre che l’addon consente di definire, oltre che metadati globali, anche metadati ristretti solo a determinati Space. In questo modo si ha la possibilità di poter definire situazioni ad hoc per determinate situazioni.

Conclusioni

L’addon è molto interessante: L’idea di disporre di informazioni di tale genere, aiuta enormemente l’utilizzatore ad una classificazione della pagina ed estende, secondo il mio personale giudizio, la funzionalità delle Page properties.

Devo segnalare ancora qualche piccola anomalia/suggerimento, che dettaglio di seguito.

• Se dalle opzioni dello Space andiamo a modificare un metadato globale, si viene poi rediretti nella sezione dei metadati globali. Se accedo dalle opzioni dello space, sarebbe il caso di ritornare su tale sezione.
• Potrebbe essere utile semplificare la procedura per definire i metadati. L’utente generico potrebbe avere dei problemi nel gestire questa procedura.

Si tratta di piccole cose, ma sono sicuro che la Communardo, con la sua esperienza e con le sue capacità, ci sorprenderà di sicuro.

Reference

Maggiori informazioni sono reperibili alla pagina del marketplace.

Userprofile – Alternative #2

Proseguiamo quanto riportato sul post precedentemente pubblicato, andando a saggiare questo addon 🙂

Dove eravamo rimasti?

Eravamo arrivati al punto in cui si doveva inserire la licenza

Una volta inserita (nel mio caso ho richiesto una licenza di valutazione di 30 giorni), questo è il risultato:

Possiamo iniziare ad usare l’addon 🙂

Azione

Passiamo alla azione. Come prima azione, creiamo una pagina di prova su di un apposito spazio. Quindi passiamo alla azione utilizzando la prima macro: Lookup User. 

Se andiamo a consultare le proprietà, abbiamo una prima sorpresa: Non abbiamo proprietà della macro. Queste sono disponibili solo nella sezione di amministrazione degli addon, nella sezione dedicata, come mostrato in figura:

La prima cosa che notiamo, guardando le configurazioni, è il dover subito capire quale gruppo di utenti può visualizzare le informazioni. Nel nostro caso, dato che l’ambiente di test non dispone di un numero molto alto di utenti, ho autorizzato il gruppo dei confluence-administrator. In questo modo posso subito visualizzare il risultato.

Altra piacevole soluzione, è quella di poter visualizzare i dati servendomi di un LDAP di test che l’addon mette a disposizione. In alternativa, occorre installarlo e poi configurarlo nella sezione delle User-Directory.

Il risultato della macro presente nella pagina è il seguente:

dove possiamo eseguire la ricerca. Il risultato viene così visualizzato (ho inserito una GIF per meglio rendere l’idea):

Il risultato è sicuramente notevole 🙂

Passiamo ad esaminare la seconda macro. Questa necessita di un LDAP . Per ovviare a questa mancanza, ho installato OpenLdap, sullo stesso server di prova. In questo modo dispongo di un sistema di test per poter eseguire un test effettivo.

Conclusioni

Terminiamo qui questa seconda parte del post. Nel prossimo post andremo a testare la seconda macro e quindi daremo il risultato finale.

Prova su strada

Proseguiamo l’analisi di questo addon, verificando su …. strada come si comporta 🙂

Installiamo l’addon…

Questo addon è rilasciato da un vendor esterno all’Atlassian marketplace. Anche andando a selezionarlo dalla sezione degli Addon di JIRA, come mostrato nella figura successiva, si viene reindirizzati al sito del produttore.

Selezionando il link presente nella immagine precedente, siamo subito reindirizzati nel sito da cui scaricare il prodotto.

Selezioniamo il nostro addon, in base alla versione del nostro JIRA. Quindi procediamo con il download.

Avendo a disposizione la versione 6.3.11, che uso per i miei test, procedo con il download del relativo JAR. Quindi, selezionando la sezione Manage add-ons, passiamo al caricamento:

Come per Confluence, selezioniamo Upload add-on per attivare la relativa funzione:

Possiamo selezionare il file JAR sia dal nostro hard disk, che da internet, direttamente dalla URL da cui scaricare il file.

Attendiamo il download

Terminata l’installazione, l’addon sarà disponibile:

Possiamo quindi procedere con il test vero e proprio.

Licenza dell’addon

Come prima cosa, dobbiamo procedere con la configurazione. L’addon mette a disposizione una sezione vera e propria sulla pagina di amministrazione di JIRA:

Da qui, possiamo referenziare tutte le configurazioni disponibili. Andiamo a …. giocarci un attimo e vediamo che cosa abbiamo a disposizione.

Prima operazione: Gestiamo la licenza. Una volta installato, il componente non è disponibile in quanto …. manca a licenza. Occorre quindi seguire le istruzuoni presenti sulla sezione JFS Licensing.

Dalla immagine, vediamo che si attiva una sezione dove possiamo caricare la licenza. Facciamo una precisazione. Le licenze sono fornite dal produttore, che dispone di un suo pannello di controllo, attraverso il quale è possibile richiedere le licenze come il pannello di controllo che la Atlassian mette a disposizione.

Letta la licenza e riportata sulla pagina relativa, abbiamo che l’addon si attiva ed è pronto per gestire le nuove situazioni.

La prima operazione da eseguire è quella di definire un nuovo Field Security Scheme, dove andremo ad impostare le varie proprietà. In maniera molto semplice e diretta, selezioniamo l’opzione presente sulla pagina di amministrazione degli addon ed andiamo a creare il nostro scheme.

In questo caso, abbiamo creato una situazione in cui il camoi Assignee può essere modificato solo dall’utente Administrator. Andiamo quindi a settare tale configurazione nel nostro progetto:

dopo di che tentiamo di lavorare con un altro utente non autorizzato e verifichiamo il comportamento:

Se si osserva la GIF che ho inserito, l’utente NON Administrator può modificare vari campi, ma non il campo Assignee, che abbiamo escluso dalla modifica.

Conclusioni

Abbiamo visto come è possibile, attraverso delle semplici interfacce, impostare delle restrizioni/abilitazioni relativamente ai vari campi, in maniera semplice e senza che sia richiesta chissà quale competenza.