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 🙂

Permission

In questo post andremo ad esaminare come gestire le permission. Vedremo che cosa sono, come si gestiscono e a che livello.

Diamo una definizione

Sotto questo termine, si intende fondamentalmente la visibilità che andiamo a forniamo ai contenuti di Confluence. Per Contenuti si intende:

• Sito (ovvero l’intero Confluence)
• Space
• Pagine

Confluence consente di poter assegnare delle Permission ai seguenti livelli:

Global

Si tratta delle permission che si possono fornire a livello di intero Confluence. SI tratta di permission GENERALI. Facciamo notare che viene sempre fornita una distinzione nelle seguenti classi di utenti:

• Gruppi;
• Utente singolo;
• accesso anonimo (inteso come accesso a Confluence senza loggarsi);

per tutte le permission.

 

Dalla figura precedente, possiamo vedere quali Permission possiamo assegnare. La prima, e più importante in quanto stabilisce anche il numero di utenti utilizzati e quindi la licenza (ed i soldi da pagare), è la can use. Tenetela sempre presente e controllatela 🙂

Seguono le permission che consentono di poter:

• Attach file to user profile, che consente di poter allegare file al profilo utente. AL momento soppiantata dalla possibilità di poter creare dei Personal Space.
• Personal Space, che consente di poter creare degli Space personali, dove ogni utente può inserire le proprie informazioni e che può gestire a suo uso e consumo. Dedicheremo un post a questo argomento molto importante 😀
• Create Space(s), che consente di poter creare degli space
• Confluence Administrator, che consente l’accesso alla console di amministrazione
• System Administrator,  che consente l’abilitazione, nella console di amministrazione, di poter accedere a particolari funzionalità che sono normalmente precluse agli utenti amministratori. Fare riferimento alla sezione reference, dove ho riportato la manualistica con le indicazioni delle differenze di quali operazioni sono consentite nei due ruoli.

Nella versione server, il ruolo System Administrator è assegnato al gruppo Administrator. Nella versione onDemand, non abbiamo questo, ma solitamente viene impostata questa distinzione.

La seguente figura riporta le stesse indicazioni ma per gli utenti e per l’accesso anonimo.

Space

In questo caso, viene data la possibilità di poter gestire le permission relative al singolo Space. Qui troveremo le azioni che è possibile eseguire SOLO A LIVELLO DI INTERO SPACE. Solo gli utenti/gruppi che sono stati precedentemente indicati come Space Administrator, possono manipolare tali permission. Anche in questo caso abbiamo la distinzione nelle tre tipologie di utenze, come indicato in precedenza.

Vediamo nel dettaglio che cosa possiamo fare:

• View, possibilità di poter consentire l’accesso;
• Pages, possibilità di creare/modificare/cancellare pagine nello space. Abbiamo la distinzione in due possibilità: Add, per aggiunta/modifica; Delete, per cancellazione;
• Blog, possibilità di poter creare/modificare/cancellare blog post (fondamentalmente pagine di Confluence, ma visibili solo attraverso la sezione Blog Post dello Space).  Abbiamo la distinzione in due possibilità: Add, per aggiunta/modifica; Delete, per cancellazione;
• Comments, possibilità di poter aggiungere/modificare/cancellare commenti alla pagina.  Abbiamo la distinzione in due possibilità: Add, per aggiunta/modifica; Delete, per cancellazione;
• Attachments, possibilità di poter aggiungere (tenendo conto della versione) e rimuovere gli space.  Abbiamo la distinzione in due possibilità: Add, per aggiunta/modifica; Delete, per cancellazione;
• Restrictions, possibilità di poter impostare/rimuovere le restrizioni alla pagina (che vedremo nel dettaglio di seguito). In questo caso abbiamo una unica opzione;
• Mail, possibilità di poter cancellare le email che sono state riportate nello space (Vedi sezione riferimenti)
• Space, possibilità di esportare lo space (Export) o di amministrarlo (Admin).

Da notare che, dalla console di amministrazione di Confluence è possibile definire quali permission di default deve possedere uno Space appena creato. Questo è possi- bile attraverso la sezione Space Permission, presente nella console di amministra- zione. Da qui possiamo impostare quali configurazioni di Default possiede uno Space appena creato. Sta poi all’amministratore impostare le configurazioni particolari da assegnare allo Space appena generato.

Page

In questo caso andiamo ad impostare quali operazioni possono essere eseguite sulla singola pagina dello space. Si tratta dell’entità minima che possiamo andare a trattare. Richiamiamo la funzione attraverso il menù Tools (Rif. al seguente post se utilizzate una delle ultime versioni di Confluence)

 

Quindi si accede alla funzionalità

Le uniche operazioni che possiamo eseguire sono le seguenti:

• Viewing restricted to, ovvero consentire la sola visualizzazione a utenti/gruppi specificati.
• Editing restricted to, ovvero consentire la modifica a utenti/gruppi specificati

 Conclusioni

In questo post abbiamo esaminato una funzione molto importante di Confluence, che ci consente di poter amministrare il sistema e di poterlo gestire al meglio per i nostri utenti. Anche se al momento la funzionalità è alquanto distribuita nelle varie sezioni di confluence, iniziano ad essere distribuiti degli addons che centralizzano queste funzioni, come il seguente addon, che rappresenta un primo passo. Attendiamo i prossimi sviluppi. .

Reference

Consiglio di leggere la manualistica della Atlassian, completa e molto chiara ma, ahimè, in inglese, sulle permission. Per la parte delle email associate ad uno space, consiglio la seguente pagina della manualista Atlassian.

 

 

 

Sarà comunicato a molti che, lanciando dei Jobs, questi non venissero eseguiti. Nessuna indicazione, nessun failure, niente di niente. Quindi? che cosa causa il problema?

Semplice. Oracle imposta un numero massimo di JOB che possono essere eseguiti. Se si vuole eseguire un numero maggiore, occorre controllare un parametro:

JOB_QUEUE_PROCESSES

Eseguendo la query:

Select * from v$parameter
where name like ‘%job%’

è possibile visionare il valore impostato.

La modifica del valore viene eseguita attraverso una ALTER SYSTEM, come mostrato di seguito.

alter system set job_queue_processes=10

Potete trovare un pò di informazioni aggiuntive nel seguente link.

Una piccola annotazione. Per poter eseguire l’istruzione di Alter System, occorre che l’utenza disponga delle corrispondenti grant. Fare riferimento al seguente link per ulteriori delucidazioni