News news news

Questo post è dedicato alle ultime novità dell’Addon ConfiForms per Confluence. Avevamo già parlato di questo addon nel post, dove avevamo descritto come aggiungere delle Form a Confluence.

Andiamo in dettaglio

Vediamo nel dettaglio quali sono le novità che annunciano dalla Vertuna :-).

• Gestione di più di 35 tipi di campi custom. Questo sicuramente aiuta nella gestione di form abbastanza complesse e consente di poter meglio configurare le form 
• Console di amministrazione potenziata 
• Gestione di form Master/Detail e filtri dinamici 
• Gestione di Tabbed form 
• Gestione di Conditional Fields
• CalendarView, che consente di mostrare i dati della form in un Calendario 
• Integrazione con JIRA: Possibilità di poter creare delle JIRA ISSUE 🙂
• Inviare email e notifiche via confiForms ed usare delle form per creare delle pagine
• e tanto altro ancora

Conclusioni

Abbiamo visto solo la punta di un iceberg. Nei prossimi post andremo a testare sul campo le potenzialità di queste nuove features.

Confrontiamo gli strumenti

In questo post andremo in dettaglio, rispetto a quanto accennato in questo post. L’obbiettivo è sempre quello di dare indicazioni per fornire l’addon giusto al momento giusto.

Iniziamo il confronto

Disponibilità

La prima cosa che andiamo ad indicare è che gli addon specificati sono tutti disponibili per le installazioni Server. Unica differenza è che solo Zephyr risulta disponibile solo per il Cloud.

Questo significa che se disponiamo di una installazione cloud, e non possiamo farne a meno, la scelta è pressoché obbligata.

Se invece disponiamo di solo installazione server, allora non abbiamo questo problema e possiamo scegliere, sempre in base alle nostre esigenze, l’addon che più ci piace.

Prezzo

Escludendo il taglio dei 10 utenti, dove tutti gli addon presentano lo stesso costo ($10), vediamo che l’addon XRay risulta il più economico. Segue l’addon Kanoah Tests e l’addon Zephyr. Quest’ultimo è il più costoso.

Il costo della versione cloud di Zephyr è abbastanza contenuto. Se disponiamo di un taglio abbastanza piccolo di utenti, possiamo anche arrivare a non spendere molto.

Funzionalità

Esaminando i vari post di presentazione e prova su strada, Zephyr potrebbe risultare più complicato da usare, mentre l’XRay risulta quello più semplice. Infatti, con XRay basta semplicemente creare un progetto e poi da li creare le Issue, definendo tutto all’interno della generazione delle issue.

Kanoah, in questo caso, presenta una complessità media, ma nelle ultime versioni, ho avuto modo di verificare che il gruppo di lavoro sta cercando di semplificare al minimo la complessità. In aggiunta, Kanoah è al momento l’unico che dispone di un timer che aiuta nel comprendere anche quanto tempo si è dedicato alla esecuzione di un test.

Integrazione con JIRA

Per quanto riguarda l’integrazione con JIRA, l’addon che meglio si integra sono XRay e Zephyr, in quanto generano i test come se fossero Issue a tutti gli effetti. In questo modo si arriva a fornire una nuova funzionalità senza un addestramento particolare del personale.  😉

Infatti, se il personale è abituato a lavorare con JIRA, non avrà alcuna difficoltà a lavorare con i casi di TEST.

D’altra parte, Kanoah introduce delle sezioni dedicate ai test, che si appoggiano alle Issue JIRA. In questo caso, creiamo dei Test Case separati che si collegano facilmente alle Issue JIRA. In questo modo possiamo definire dei cicli di test unici per differenti issue, che possono anche essere relative a diversi progetti (che magari presentano la stessa funzionalità). Abbiamo quindi una buona riusabilità. 🙂

Conclusioni

Per le versioni cloud, la scelta risulta al momento forzata, in quanto l’unico addon (al momento in cui l’articolo viene scritto, la situazione  quella descritta).

Per le versioni server abbiamo molta più scelta. Se il nostro obbiettivo è quello di usare il prima possibile queste funzionalità, allora la nostra scelta ricade su XRay e su Zephyr, in quanto diventano una sorta di estensione delle Issue JIRA (con delle funzionalità non indifferenti) 🙂

Se invece, ahime, è il nostro portafoglio a dettare legge, la scelta ricade sicuramente su XRay, in quanto offre un ottimo insieme di funzionalità ad un costo relativamente contenuto.

Se invece vogliamo puntare sulla riusabilità, integrata con altri progetti, allora abbiamo a disposizione il Kanoah Tests, che ci consente di poterci agganciarci a più progetti.

Ovviamente si tratta di un confronto che mira a non dichiarare un vincitore tra le parti, ma semplicemente cerca di aiutare gli utenti nella scelta dell’addon, seguendo le proprie necessità.

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.

Approfondiamo l’argomento

In questo post andremo ad approfondire l’argomento Workflow, già trattato in:

• First look
• Creiamoci il nostro Workflow

Cercheremo, in questa prima fase, di capire che funzionalità abbiamo a disposizione, cercando in una seconda fase di applicarle a dei casi reali.

Nel dettaglio

Come JIRA Administrator è possibile operare le seguenti azioni su di un Workflow:

• Triggers –  Si tratta di  impostare delle azioni specifiche da eseguire in determinate condizioni / transazioni.
• Conditions – possibilità di poter impostare delle condizioni per poter eseguire determinate transazioni.
• Validators – intesa come validazione dei dati, affinché rispettino determinate condizioni
• Post functions – intesa come l’esecuzione di operazioni dopo che una issue è passata da uno stato all’altro
• Properties – si tratta di coppie di valori che possono essere usate per estendere le proprietà, come informazioni aggiuntive del workflow.

Andiamo ad esaminare nel dettaglio le varie componenti.

Triggers

Questi strumenti sono utilizzati prevalentemente per integrare determinate azioni del workflow con gli strumenti di sviluppo quali Stash o FishEye/Crucible. La seguente tabella riassume quali azioni possono essere eseguite.

Di conseguenza, se non si dispone di un link a tali strumenti, i trigger non risultano usabili. Questo lo andremo a verificare con i nostri test. 🙂

Conditions

Si tratta condizioni che possono essere impostate nelle varie transazioni di stato del Workflow. Possiamo, ade esempio, impostare le seguenti condizioni:

• Consentire al solo reporter di eseguire una transizione di stato. Si tratta di una condizione molto rigida: Si consiglia una attenta valutazione prima di impostare una condizione del genere;
• Consentire ad un insieme di utenti di poter eseguire una transizione di stato. SI tratta di una condizione molto rigida anche questa.
• Poter eseguire una transizione di stato solo dopo aver eseguito la commit.

Validators

Con questa funzionalità, riusciamo ad impostare una validazione dei dati che sono inseriti prima della transazione di stato. Se questa fase non viene passata, la transazione di stato non viene eseguita e le operazioni successive non sono eseguite.

In questo modo possiamo accertarci di aver inserito correttamente tutte le informazioni, nell’ambito di una issue. Possiamo finalmente avere delle issue complete in ogni fase della lavorazione 🙂

Post functions

Si tratta di operazioni, di corollario, che possono essere impostate per essere eseguite dopo che la transazione di stato è stata eseguita. In questo modo possiamo impostare delle funzionalità aggiuntive. SI tratta di una funzionalità non indifferente 🙂

Possiamo settare lo stato di una linked issue, in modo da sbloccarla in … automatico. Questo sicuramente ci può aiutare nella sincronizzazione dei gruppi di lavoro. Supponiamo che una nostra issue blocca il lavoro di un altro gruppo. Con questa semplice azione possiamo segnalare in automatico che possono procedere con la lavorazione di una determinata anomalia. Immaginatevi se i gruppi di lavoro sono a distanza l’uno dall’altro.

Possiamo anche andare a settare un campo in funzione del contenuto di un’altro. Le possibilità sono molteplici. 😀

Properties

Si tratta di coppie di valori (codice/valore) che sono usate per estendere le proprietà di un workflow.

Un possibile uso può essere quello di impostare delle restrizioni in base ai valori delle properties impostate.

Conclusioni

In questo post siamo andati un in profondità sui Workflow. Abbiamo visto come è possibile estendere queste nuove funzionalità, come poter impostare diverse condizioni, validazioni ed estendere il Workflow con nuove proprietà. Nei prossimi post andremo a vedere un esempio di utilizzo di queste, applicandoli a situazioni già descritte.

Ultime news

In questo post andremo a vedere quali sono le ultime novità sull’addon Kanoah Tests, andando ad approfondire i post che nel passato abbiamo dedicato all’argomento.

Andiamo in dettaglio

Vediamo quali sono le ultime novità, andandole ad esaminare in dettaglio:

Rich text support

E’ stato fornita la possibilità di editare i commenti ed i testi con formattazione (grassetto, italico, etc), come mostrato nella seguente figura.

Permission

Abbiamo a disposizione una unica area, nella sezione di amministrazione, per gestire le permission dei vari utenti, gruppi e ruoli.

Tracciatura storico test

Viene data la possibilità di poter tracciare lo storico dei vari test, delle varie operazioni, come mostrato in figura.

Abilitare/Disabilitare l’addon

Viene data la possibilità di poter abilitare/disabilitare l’addon per specifici progetti. Questo significa che possiamo attivare l’addon solo per alcuni di essi e non attivarlo per altri. Provate a pensare se avete delle situazioni in cui si dispone di progetti, preesistenti, che sono già operativi ed avviati. Questo è un ottimo risultato.

Migliorata la gestione dei Run Test

E’ stata migliorata la gestione dei Run Test, consentendo una migliore interazione con gli stessi e consentendo di poter meglio gestire il tutto.

Conclusioni

La Kanoah ci sorprende con nuove sorprese. Sono sicuro che non finirà di stupirci. Rimaniamo in attesa di nuove implementazioni 🙂

User Macro

In questo post andremo ad consultare un articolo presente in questo blog, che ritengo molto interessante. Lo esamineremo e cercheremo di approfondire l’argomento, in quanto lo ritengo un ottimo esempio didattico.

Andiamo in dettaglio

L’articolo del blog spiega come realizzare una alternativa alla macro Space Detail Macro, usando le macro per ottenere un risultato migliore 🙂

In particolare il risultato che offre con la sua macro è il seguente:

L’ho scelto perché si tratta di una macro molto semplice e, dal punto di vista didattico, la macro risulta realizzata molto bene.

Vediamo il codice

La configurazione preliminare della macro è molto semplice. La seguente immagine la riassume:

Il codice è molto semplice. Lo riporto di seguito nella sua interessa e successivamente lo andremo ad esaminare pezzo per pezzo, in modo da capire come viene eseguita ogni singola operazione.

## Macro title: Space Meta Data
## Macro has a body: Y or N (N)
## Body processing: Selected body processing option
## Output: Selected output option
##
## Developed by: Andrew Frayling
## Date created: 03/05/2012
## Installed by: <your name>

## Macro to display information such as number of pages, number of blog posts, attachment size, etc. about a Space. 

## @noparams

## Get space details
#set ( $spaceName = $space.getName() )
#set ( $spaceKey = $space.getKey() )
#set ( $spaceHome = $space.getHomePage() )
#set ( $spaceCreator = $space.getCreatorName() )
#set ( $spaceCreationDate = $space.getCreationDate() )
#set ( $spaceDescription = $space.getDescription() )
#set ( $pageCount = $spaceManager.findPageTotal($space) )
#set ( $blogCount = $spaceManager.getNumberOfBlogPosts($space) )

## Get all pages in the current Space
#set ( $allPagesInSpace = $pageManager.getPages($space, true) )

## Reset total attachment file size
#set ( $totalAttachmentFileSizeForSpace = 0 )

## Reset total number of attachments
#set ( $totalAttachmentCount = 0 )

## Loop through all pages in the current Space
#foreach ($page in $allPagesInSpace)
  ## reset the attachment count for each page
  #set ( $pageAttachmentCount = 0 )
  ## reset the attachment file size total for each page
  #set ( $totalFileSizePerPage = 0 )
  ## get the attachments for each page
  #set ( $allAttachments = $page.getAttachments() )
  ## Loop through each attachment
  #foreach ($attachment in $allAttachments)
    ## Increment the attachment count for the page
    #set ( $pageAttachmentCount = $pageAttachmentCount + 1 )
    ## Sum the size of the attachments on the page
    #set ( $totalFileSizePerPage = $totalFileSizePerPage + $attachment.getFileSize() )
  #end
  ## End looping through attachments
  ## Increment total attachment count for the current Space
  #set ( $totalAttachmentCount = $totalAttachmentCount + $pageAttachmentCount )
  ## Sum the total size of attachments for the current Space
  #set ( $totalAttachmentFileSizeForSpace = $totalAttachmentFileSizeForSpace + $totalFileSizePerPage )
#end
## End looping through pages

## Convert attachment size to MBs
#set ( $attachmentSizeMb = ($totalAttachmentFileSizeForSpace / 1024.00) / 1024.00 )

## Display Space Details
<table class="confluenceTable">
  <tbody>
    <tr>
      <th class="confluenceTh">Name</th>
      <td class="confluenceTd">$spaceName</td>
    </tr>
    <tr>
      <th class="confluenceTh">Key</th>
      <td class="confluenceTd">$spaceKey</td>
    </tr>
    <tr>
      <th class="confluenceTh">Description</th>
      <td class="confluenceTd">$spaceDescription.getBodyAsString()</td>
    </tr>
    <tr>
      <th class="confluenceTh">Home Page</th>
      <td class="confluenceTd">#contentLink2($spaceHome true false)</td>
    </tr>
    <tr>
      <th class="confluenceTh">Created By</th>
      <td class="confluenceTd">#usernameLink($spaceCreator) ($action.dateFormatter.formatDateTime($spaceCreationDate))</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Pages</th>
      <td class="confluenceTd">$pageCount</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Blog Posts</th>
      <td class="confluenceTd">$blogCount</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Attachments</th>
      <td class="confluenceTd">$totalAttachmentCount (including all versions)</td>
    </tr>
    <tr>
      <th class="confluenceTh">Total Size of Attachments</th>
      <td class="confluenceTd">$attachmentSizeMb MB</td>
    </tr>
  </tbody>
</table>

Distinguiamo le seguenti sezioni nella macro:

• Testata
• Lettura parametri dello space
• Lettura della dimensione dei vari allegati
• Visualizzazione dati ottenuti

Andiamo ad esaminarle in dettaglio.

## Macro title: Space Meta Data 
## Macro has a body: Y or N (N) 
## Body processing: Selected body processing option 
## Output: Selected output option 
## 
## Developed by: Andrew Frayling 
## Date created: 03/05/2012 
## Installed by: <your name> 
## Macro to display information such as number of pages, number of blog posts, attachment size, etc. about a Space. ## @noparams

L’Intestazione della macro è quello che avevo già descritto nel mio primo post. In questo caso, l’autore ha realizzato una intestazione molto ben fatta, chiara, semplice e di rapido effetto.

Spiega subito le caratteristiche della macro in poche righe.

## Get space details
#set ( $spaceName = $space.getName() )
#set ( $spaceKey = $space.getKey() )
#set ( $spaceHome = $space.getHomePage() )
#set ( $spaceCreator = $space.getCreatorName() )
#set ( $spaceCreationDate = $space.getCreationDate() )
#set ( $spaceDescription = $space.getDescription() )
#set ( $pageCount = $spaceManager.findPageTotal($space) )
#set ( $blogCount = $spaceManager.getNumberOfBlogPosts($space) )

## Get all pages in the current Space
#set ( $allPagesInSpace = $pageManager.getPages($space, true) )

## Reset total attachment file size
#set ( $totalAttachmentFileSizeForSpace = 0 )

In questa sezione, invece, va a leggere tutte le informazioni dello Space, impostando tutte le variabili con le informazioni che si vogliono visualizzare nella macro. Notiamo le variabili, definite con la sintassi che è stata già spiegata nei precedenti post.

## Reset total number of attachments 
#set ( $totalAttachmentCount = 0 )

## Loop through all pages in the current Space
#foreach ($page in $allPagesInSpace)
  ## reset the attachment count for each page
  #set ( $pageAttachmentCount = 0 )
  ## reset the attachment file size total for each page
  #set ( $totalFileSizePerPage = 0 )
  ## get the attachments for each page
  #set ( $allAttachments = $page.getAttachments() )
  ## Loop through each attachment
  #foreach ($attachment in $allAttachments)
    ## Increment the attachment count for the page
    #set ( $pageAttachmentCount = $pageAttachmentCount + 1 )
    ## Sum the size of the attachments on the page
    #set ( $totalFileSizePerPage = $totalFileSizePerPage + $attachment.getFileSize() )
  #end
  ## End looping through attachments
  ## Increment total attachment count for the current Space
  #set ( $totalAttachmentCount = $totalAttachmentCount + $pageAttachmentCount )
  ## Sum the total size of attachments for the current Space
  #set ( $totalAttachmentFileSizeForSpace = $totalAttachmentFileSizeForSpace + $totalFileSizePerPage )
#end
## End looping through pages

## Convert attachment size to MBs
#set ( $attachmentSizeMb = ($totalAttachmentFileSizeForSpace / 1024.00) / 1024.00 )

In questa sezione del codice, viene eseguito un esempio di ciclo sulle varie pagine, per determinare la dimensione dei vari allegati alle pagine dello Space. Questo è sicuramente un ottimo esempio che mostra come sono reperite le informazioni usando il codice delle macro.

In aggiunta vediamo come eseguire il reperimento dei dati, quali le pagine presenti dentro uno space, e degli allegati. La sintassi non è affatto difficile e consente di poter lavorare agevolmente.

## Display Space Details
<table class="confluenceTable">
  <tbody>
    <tr>
      <th class="confluenceTh">Name</th>
      <td class="confluenceTd">$spaceName</td>
    </tr>
    <tr>
      <th class="confluenceTh">Key</th>
      <td class="confluenceTd">$spaceKey</td>
    </tr>
    <tr>
      <th class="confluenceTh">Description</th>
      <td class="confluenceTd">$spaceDescription.getBodyAsString()</td>
    </tr>
    <tr>
      <th class="confluenceTh">Home Page</th>
      <td class="confluenceTd">#contentLink2($spaceHome true false)</td>
    </tr>
    <tr>
      <th class="confluenceTh">Created By</th>
      <td class="confluenceTd">#usernameLink($spaceCreator) ($action.dateFormatter.formatDateTime($spaceCreationDate))</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Pages</th>
      <td class="confluenceTd">$pageCount</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Blog Posts</th>
      <td class="confluenceTd">$blogCount</td>
    </tr>
    <tr>
      <th class="confluenceTh">Number of Attachments</th>
      <td class="confluenceTd">$totalAttachmentCount (including all versions)</td>
    </tr>
    <tr>
      <th class="confluenceTh">Total Size of Attachments</th>
      <td class="confluenceTd">$attachmentSizeMb MB</td>
    </tr>
  </tbody>
</table>

Questa è la parte che si occupa della visualizzazione. Notiamo che si tratta di HTML, che sfrutta le classi e le proprietà di Confluence. Vediamo che tutti i risultati delle precedenti elaborazioni sono inserite in questa tabella, in maniera molto rapida.

Conclusioni

Abbiamo analizzato un esempio di macro, molto semplice ma nello stesso tempo, fondamentale. Con esso è possibile comprendere e capire meglio come si può realizzare una macro, come possiamo sfruttare i vari punti del linguaggio per realizzare le funzionalità di cui si abbisogna senza, in questo caso, dover installare nulla :-). Scusate se è poco 😀

Ringraziamenti

Un ringraziamento particolare va all’autore del post blog. L’articolo è ben fatto e, anche se in inglese, è molto chiaro. I complimenti all’autore sono d’obbligo. 🙂

Una piccola novità….

In questo post andremo a riportare una curiosità, di cui mi sono accorto in questi giorni. Seguirà un post con opportuni approfondimenti 🙂

Di cosa si tratta?

Andiamo al dunque. Lavorando tutti i giorni con la versione Cloud di Confluence e JIRA, quasi non faccio caso alle ultime novità. Ma questa volta ho notato una piccola …. variante 😀

Nella fase di creazione di nuovi contenuti, è stata introdotta una variante. Il tasto Create è stato modificato in modo da semplificare il lavoro dell’operatore. Questo significa che se vogliamo creare una singola pagina, basta selezionare il tasto. Se invece abbiamo la necessità di creare una pagina da Template, allora quello che possiamo fare  selezionare il tasto con i tre punti, posto a fianco del tasto Create .

Conclusioni

Si tratta di un piccolo miglioramento, ma nel lavoro di un operatore, si tratta di una variante molto interessante. Se ci concentriamo sul lavoro di un operatore generico, questo lo aiuta notevolmente nell’aumentare la produttività e nel semplificarsi la vita. Non è cosa da poco 🙂

Approfondiamo l’argomento

In questo post andremo ad approfondire l’argomento dello UserProfile, affrontato in questo post. Vediamo una ulteriore alternativa disponibile 🙂

Enterprise Directory & Org Chart for Atlassian Confluence

Si tratta di un addon, realizzato dalla AppFusions, che permette di disporre di una buona integrazione con Active Directory o LDAP e mette a disposizione un sistema per poter navigare e rappresentare in maniera efficace la User directory.

L’interfaccia per la ricerca è molto semplice e diretta e consente, agli utenti, di poter cercare in maniera agevole tra i dati della People Directory.

Altra caratteristica importante è quella di consentire una rappresentazione gerarchica degli utenti. Questa è una funzionalità non indifferente: Avremmo a disposizione sempre la possibilità di poter creare il nostro organigramma. Al momento solo in questo post abbiamo visto come poter generare un diagramma simile.

Conclusioni

Abbiamo visto una ulteriore alternativa alla UserProfile di Confluence. Abbiamo visto che, in questo sistema, non esiste una sola alternativa alla funzionalità standard, ma abbiamo un ampio ventaglio di alternative, che possiamo scegliere in base a quali sono le nostre esigenze. Prova su strada seguirà nei prossimi post 🙂

Reference

Maggiori dettagli dell’addon sono reperibili qui.

Ringraziamenti

Mi permetto d ringraziare David Simpson per la segnalazione inviatami, che aiuta tutti noi a capire meglio come orientarci in questo grande insieme di addons per Confluence.

Pillole di esperienza

In questo post iniziamo a trattare un argomento più complesso, ma anche molto più interessante :-), in quanto iniziamo a capire meglio, oltre che ad usare questo strumento dal punto di vista tecnico, come farlo rendere al meglio. Iniziamo ad introdurre alcuni concetti che stanno alla base dell’uso di un Wiki e che aiutano a migliorare la vita. 😀

Alcune precisazioni

Prima di affrontare questo argomento, occorre fare alcune precisazioni. L’argomento trattato può essere facilmente esteso a qualsiasi WIKI, senza alcuna difficoltà, in quanto si tratta di indicazioni che vanno bene per tutti. Il WIKI è uno strumento, e come tale deve essere trattato.

In aggiunta, un WIKI non è uno strumento che vive di vita propria. Deve essere curato costantemente, occorre sempre verificarne pagine e contenuti. Un WIKI Necessita di costante intervento umano, altrimenti non serve assolutamente a nulla. Diventa un banale contenitore di informazioni e ogni utente dovrà perdere tempo nel reperire le stesse.

E’ come se mettiamo degli oggetti in una grande scatola e l’unico sistema per accedere alla scatola è buco dove a malapena entra una mano. Se vogliamo prendere uno degli oggetti dobbiamo infilare la mano e, alla cieca, cercare di prendere l’oggetto che vogliamo. Non ha assolutamente senso.

A cosa serve un Wiki?

Un Wiki è uno Strumento che aiuta ad organizzare le informazioni, in modo efficiente e semplice. Il vantaggio di usare un wiki è che il sistema di organizzazione delle informazioni è molto flessibile e si basa sulla collaborazione degli stessi utenti, il cui obbiettivo non è solo la scrittura e fruizione delle informazioni, ma anche il costante miglioramento delle stesse.

Molto spesso si da per scontato che, una volta adottato un WIKI, tutti i problemi sulla documentazione siano stati superati. Errore numero 1 – Siamo appena all’inizio :-).

Tuttavia, una volta che è stato avviato, nei modi e nei tempi corretti, abbiamo a disposizione uno strumento che ci può semplificare la vita di tutti i giorni. Questo richiede uno sforzo iniziale molto forte, ma se ben fatto il risultato ripaga molto delle fatiche che sono sostenute nella fase iniziale di redazione e tutte le modifiche/estensioni successive sono poi di facile esecuzione.

Wiki come punto centrale

Inserire le informazioni solo su WIKI è un vantaggio enorme. Questo significa che le stesse sono presenti solo li, non sono duplicate o la duplicazione è ridotta al minimo possibile, e, molto importante, sono tutte collegate tra di loro, fornendo un filo logico di lettura e consentendo agli utenti di poterle visionare senza grandi problemi.

Il vantaggio di una centralizzazione è evidente: avere un unico punto dove far risiedere le informazioni riduce la possibilità di errore (non dobbiamo andare a cercare le informazioni a destra e manca) ed aumenta la produttività. Se l’informazione è sul WIKI, questa sarà ricercata li e non su mail o file system o chissà che altro.

In organizzazioni molto strutturate, molto spesso, sono dotati di complessi portali e sistemi farraginosi il cui obbiettivo è la centralità delle informazioni. Molto spesso questo non è vero, in quanto si tratta di soluzioni molto rigide, studiate per una necessità particolare e, come sempre accade, questa necessità non può essere facilmente adattata ai cambiamenti.

Un WIKI è una soluzione tra le più flessibili, in quanto le rigidità dei portali praticamente non esistono. Occorre che gli utenti sfruttino il più possibile questa flessibilità a proprio vantaggio. Il non farlo causa dei grossi problemi in fasi successive, quando si fruisce della informazione stessa. Come scrivevo prima, scrivere delle pagine alla rinfusa, non aiuta affatto, occorre che ci sia uno schema e che le informazioni siano collegate.

Facilità di uso

Le informazioni su WIKI devono essere organizzate in maniera semplice e devono essere fruibili altrettanto facilmente. Di conseguenza, in base alle esigenze aziendali, queste devono essere organizzate, collegate, referenziate in maniera opportuna. Più lo schema adottato è semplice, più è semplice fruirne. Maggiore caos nelle informazioni, maggiore caos nella ricerca, maggiore caos nel reperire le informazioni. Allora non ha alcun senso creare delle pagine su di un WIKI, sperando che gli utenti facciano da soli. Essere utenti non significa essere macchine.

Un primo passo è quello di dotare le pagine di una determinata gerarchia e, successivamente, collegare le pagine in maniera da poterle …. navigare. Avere delle pagine con la semplice informazione, ma letteralmente buttata alla rinfusa, serve a nulla. Avere delle pagine con informazioni e collegate tra di loro, dove un utente può, partendo da una determinata informazione, risalire alle altre, questo si che è un vantaggio non indifferente ed il modo di gestire un wiki. Sul come fare, abbiamo tutti gli strumenti del caso 🙂

Il secondo passo è aggiornare costantemente queste informazioni. Mantenere delle informazioni statiche, non ha molto senso. Aggiornarle costantemente ha il suo vantaggio. Per aggiornarle si intende sia estendere le informazioni presenti nella pagina, sia estendere la rete di collegamenti tra pagine.

Evitiamo le mode

Altro punto fondamentale: Non si usa un wiki solo perchè l’azienda concorrente lo usa e fa affari d’oro. Lo si usa per migliorare l’azienda, dare un valore aggiunto, ridurre la complessità e arrivare prima degli altri ai propri obbiettivi. Discorsi del tipo: loro lo usano e vanno benissimo; non servono a nulla: Errore numero 2. :-).

Uno strumento deve essere adottato in azienda solo se serve, no perché va di moda. Le mode passano. Le metodologie valide rimangono ed i risultati si vedono.

Percorso di Lettura

Altra caratteristica importante per un WIKI, riguarda come si può eseguire la lettura delle pagine. Questo è un concetto molto importante. Ogni pagina deve essere inserita in un opportuno percorso di lettura, attraverso il quale l’utente naviga alla ricerca delle sue informazioni.

Questo significa che la pagina del WIKI non è scollegata, ma è connessa con altre pagine. L’utente deve poter reperire questa pagina principalmente attraverso la navigazione di pagine. La ricerca deve essere l’ultima possibilità di reperire le informazioni, e non la normalità. Se ogni informazione viene reperita solo attraverso la ricerca, allora questo non va bene.

Facciamo un esempio. Supponiamo di avere un applicativo, cui abbiamo realizzato delle personalizzazioni per determinati clienti. Se, ad esempio, dobbiamo cercare una determinata personalizzazione, questa deve essere reperita attraverso:

• la pagina del cliente. Da li deve essere possibile poter risalire alla personalizzazione. Se questa è comune a più clienti, allora si deve poter risalire dalle pagine dei clienti coinvolti.
• la pagina dell’applicativo. Dalle indicazioni generali deve essere possibile risalire al particolare sviluppo operato.
• la pagina delle personalizzazioni. Dalle indicazioni riassuntive delle personalizzazioni, deve poter essere possibile risalire alla informazione particolare del o dei clienti coinvolti.

Se non abbiamo molti elementi, allora conviene cercare per la ricerca.

Come descritto, prima di arrivare a cercare attraverso la maschera di ricerca, siamo transitati dalle pagine principali di altre informazioni, tentando una navigazione che ci porti a quello che stiamo cercando. Questo è l’utilizzo

Conclusione

Siamo giunti al termine di questo primo post, dedicato ai concetti fondamentali di un WIKI. Nei prossimi, cercheremo di fornire ulteriori approfondimenti che aiutino gli utenti (utilizzatori e scrittori) a fare meglio il proprio lavoro.

UserProfile

In questo post andremo a vedere una alternativa alla macro standard Userprofile. Si tratta dell’addon della Communardo.

UserProfile: Cosa è?

La UserProfile Macro è una funzionalità che consente di poter visualizzare una scheda riassuntiva degli utenti, come mostrato nella figura successiva.

Questa funzionalità è sicuramente utile, quando in fase di redazione delle pagine di progetto, si realizza la sezione del team di lavoro. Con questo semplice accorgimento, abbiamo nome e cognome di chi si occupa di una determinata mansione, programma, autore; come mostrato in figura:

Questa funzionalità può essere anche utile quando, nella redazione di verbali, si inserisce l’immagine dei partecipanti. Una immagine vale più di 1000 parole.

Alternative?

Abbiamo un addon che mette a disposizione una macro simile, ma con caratteristiche in più. Si tratta di User Profiles for Confluence della Communardo. Ho avuto il piacere di sperimentare questo addon qualche anno fa, rimanendone piacevolmente soddisfatto. Andiamo in dettaglio:

Questo addon consente di poter aggiungere delle informazioni aggiuntive al profilo. Queste informazioni possono essere legate anche al sistema LDAP, con possibilità di sincronizzazione, come mostrato in figura:

e come si può notare, il sistema di creazione e sistemazione dei campi è molto semplice ed intuitivo.

Macro ad hoc permettono di poter rappresentare i profili in differenti maniere, ovvero:

• tabellare, ovvero come una tabella, dove sono specificate le informazioni richieste;
• treeview, indicando anche una sorta di gerarchie;
• avanzato, ovvero comprendente tutte le informazioni, comprese quelle nuove

In aggiunta, viene fornito anche un People Directory esteso:

permettendo di poter disporre di un vero e proprio elenco telefonico. Quando lo installai, questa funzionalità non era ancora disponibile, ma a suo tempo inviai una richiesta per realizzarla :-). Adesso è disponibile.

Anche l’operazione di ricerca è stata estesa, in modo da poter comprendere anche la ricerca di …. profili. Si tratta di un lavoro eccezionale.

Conclusioni

Abbiamo esaminato una funzionalità molto importante, dal punto di vista grafico, che permette di inserire la propria…faccia su Confluence :-). Abbiamo anche visto un esempio di addon, che mette a disposizione delle ulteriori macro parallele alla funzionalità standard, che consentono di poter aggiungere valore alle nostre pagine Confluence. Al momento, l’addon è disponibile solo per le installazioni server, ma non disperiamo. Come già notato in precedenti post, questo addon potrebbe essere presto disponibile.