Redmine, an overview

Purpose of this post is to give an overview of Redmine main functionalities to simplify evaluation for adoption into your organization.

Redmine is an application written and maintained by Jean-Philippe Lang (link) that improved over the years so to be an accountable alternative as issue tracker due to its open nature and GPLv2 license.
Issue tracker management is of course a fundamental step to achieve mature operations: into this article I will mention main features and settings from administrator and user perspectives to simplify your choice adapting tool to your established process.
For a good reference book I can suggest “Mastering Redmine”, by Andriy Lesyuk (link).

Trackers

Sorry, translation yet to be done here

Nel gergo utilizzato dai traduttori della versione italiana, le attività sono chiamate “segnalazioni”, la scelta può in un primo tempo sembrare fuorviante ed è dettata dal fatto che la funzione primaria del tool è storicamente legata al tracciamento dei “bug” (nel qual caso è corretto parlare di “segnalazioni”). Le segnalazioni sono totalmente configurabili per venire incontro alle esigenze dell’organizzazione, il cuore del tool consiste nel formalizzare e tracciare le attività attraverso “workflow” che vengono impostati da un utente con ruolo di amministrazione seguendo le guidelines aziendali. L’elevato grado di configurabilità del tool permette quindi di formalizzare nella sua customizzazione quelli che sono i processi dell’azienda.

Gestione della segnalazione lato amministratore

L’amministratore può liberamente configurare i tipi di segnalazioni, utilizzando il menu Amministrazione > Tracker, nell’esempio in figura:

Gestione tipologia segnalazioni

 

  • Nuova funzione
    • Vengono tracciate le attività di introduzione nuove funzionalità
  • Bug
  • Modifica
    • Tracciamento attività modifica di funzionalità già esistenti
  • Review
    • Attività di revisione (può essere un documento di qualsiasi tipo)

L’esempio è puramente indicativo, può ad esempio essere aggiunta l’attività (segnalazione) “Meeting”, utile per associare le sotto-attività che nascono dalle riunioni di avanzamento del progetto.

Per ogni “Tracker” (anche qua la traduzione italiana non aiuta, un tracker è semplicemente un tipo di attività) deve essere impostato il workflow secondo l’istruzione operativa aziendale: si tratta di una matrice di transizione degli stati delle attività, che normalmente è differente per ogni ruolo (anch’essi liberamente configurabili a seconda delle esigenze dell’organizzazione). Ad esempio, nella figura successiva sono riportati 3 ruoli modificabili, mentre sono sempre disponibili 2 ruoli “Non membro” e “Anonimo” di default, con il quale un utente può comunque consultare informazioni senza effettuare login.

Gestione ruoli

Nel seguito viene visualizzata un esempio di matrice di transizione impostata in Redmine per l’attività di gestione dei bug per i ruoli di “Sviluppatore” e “Tester”: in verde le transizioni permesse, ad ogni riga lo stato di partenza, mentre sulle colonne sono riportati gli stati di arrivo.

Workflow bug per sviluppatore

Dalla tabella è stato permesso allo sviluppatore di chiudere un bug, respingendolo con adeguato commento, mentre viene interdetta la transizione da Risolta a Verificata, che deve essere effettuata dal ruolo di Test Engineer (vedi Figura successiva). Lo stato “Verificata” comporta la chiusura della segnalazione, il tool segnala in grigio barrando ogni riferimento verso tale segnalazione, quando l’attività ha raggiunto lo stato di chiusura.

Workflow Bug per Test Engineer

Gestione segnalazioni lato utente

Lato utente, l’inserimento di una segnalazione avviene premendo la tab “Nuova Segnalazione” nella pagina di progetto, si entra quindi in una web form come in figura:

Inserimento nuova segnalazione

I campi presentati all’utente sono anch’essi configurati dall’amministratore a seconda del ruolo e del tipo di segnalazione. Per esempio nella figura sopra viene visualizzato il campo obbligatorio “Injection Discipline” perché, essendo l’attività presa ad esempio la correzione di un problema (Bug), l’organizzazione vuole tracciare in quale fase del processo di sviluppo è stato commesso l’errore, per poi effettuare delle statistiche sul numero di fasi tra introduzione e rilevamento del problema.
Con le checkbox in basso, possono essere selezionati degli osservatori che verranno successivamente notificati automaticamente via mail di ogni attività relativa alla risoluzione di questo “Bug”.

In ogni momento l’utente può visualizzare lo stato delle segnalazioni ed impostare attraverso l’interfaccia grafica delle query specifiche visibili solo dal proprio utente o rese pubbliche all’interno dell’applicazione. Nell’esempio sono filtrate le segnalazioni aperte attualmente assegnate all’utente che ha effettuato il login.

Elenco mirato delle segnalazioni

Selezionando l’ID (numero progressivo univoco assegnato automaticamente dal tool) o la descrizione nel campo “oggetto” si passa alla visualizzazione dello stato attuale dell’attività, nel quale in giallo viene evidenziata la situazione attuale (percentuale avanzamento, assegnatario, stato, …), in basso la cronologia delle modifiche. E’ possibile collegare attività tra di loro con la funzione “Aggiungi” nella parte “Segnalazioni correlate”, utile specialmente nel caso un’attività sia bloccata dal completamento di un’altra attività o nel caso di segnalazioni duplicate. In “Sottoattività” è possibile aggiungere attività “figlie” che partono logicamente dalla macro-attività “padre”, questa funzionalità è utile specialmente per effettuare raggruppamenti gerarchici che vengono messi automaticamente in evidenza nei diagrammi di Gantt.

Stato segnalazione
Stato segnalazione

Query personalizzate

Il tool supporta il salvataggio delle query personalizzate per gestire comodamente le segnalazioni, gli utenti possono definirne di nuove su base globale o di progetto, mettendo queste query a disposizione degli altri utenti. Per esempio può essere salvata una ricerca “Aperte e assegnate a me” in modo da avere lo stato globale delle attività che l’utente deve chiudere, per default queste vengono ordinate per priorità decrescente:

Query personalizzata
Query personalizzata

Gestione progetti

Gli utenti con ruolo di amministratore sono in grado di gestire l’apertura/chiusura dei progetti, selezionare i moduli da utilizzare e le persone assegnate a ciascuno di essi nonché stabilirne l’organizzazione gerarchica in sotto-progetti. Un modulo è una funzionalità di Redmine che può essere attivata o meno sul singolo progetto, quelli disponibili nell’installazione base sono:

  • Tracking delle segnalazioni: la gestione delle attività come visto nei paragrafi precedenti, è la funzionalità base del sistema. Ha senso non utilizzare questo modulo quando il progetto è utilizzato come contenitore per raggruppare altri progetti correlati logicamente sui quali il “tracking” è invece abilitato. Il progetto padre può comunque essere utilizzato per gestire documenti, forum e Wiki comuni a tutti i sotto-progetti.
  • Time tracking: report e tracciamento delle ore spese sulle attività
  • Notizie: una pagina nel quale pubblicare novità rilevanti sul progetto, per esempio il raggiungimento di una milestone nel quale inserire i altri link per approfondimento.
  • Documenti: una pagina nel quale pubblicare documenti, gli attachments sono correlati ad una pagina web descrittiva
  • File: simile a documenti, ma senza la parte descrittiva, può essere utilizzato come contenitore di documenti sul quale vengono gestiti i contatori sui numeri di upload e visualizzato un checksum md5
  • Wiki: uno spazio Wiki collaborativo su cui gli utenti possono cooperare per creare un mini sito di progetto. Un classico utilizzo è la release note, non a caso le Versioni del progetto permettono di associare una pagina Wiki
  • Repository: la connessione con il tool di Configuration Management (SVN, Git, Mercurial, …)
  • Forum: utilizzabile per tracciare discussioni che non necessitano di una vera e propria attività (esempio: supporto informativo, FAQ, …)
  • Calendario: vengono visualizzate le milestone legate alle attività
  • Gantt: il diagramma viene automaticamente generato con le informazioni relative alle attività.

L’utilizzo corretto del tool, in particolare l’inserimento delle date di inizio e fine attività (nonché l’aggiornamento della percentuale di progressione) permette di generare automaticamente il Gantt delle attività esportabile anche in formato pdf o come immagine png. E’ possibile inoltre applicare dei filtri per generare un diagramma parziale solo con le attività di interesse.

Diagramma di Gantt
Diagramma di Gantt

Versioni

Per “versioni” si intendono le milestone del progetto, si stabilisce un’etichetta ed una data di consegna. A seguito della creazione della versione è possibile associare attività di qualsiasi tipo costruendo così una roadmap del progetto, la percentuale di avanzamento delle singole attività contribuisce automaticamente al calcolo dell’avanzamento della versione (milestone). In Figura 14 un esempio nel quale la versione “0.4” è all’80 % di completamente (con 10 giorni di ritardo) mentre la “prossima versione” è aperta e senza una data di consegna specifica. E’ sempre possibile cambiare il nome della versione, per cui è pratica comune specificare una generica “prossima versione” sulla quale associare le attività per poi modificare a posteriori il nome appena disponibile.

Dettaglio versione
Dettaglio versione

Conclusioni

Dopo aver fatto qualche esperimento ed introdotto l’utilizzo dell’applicazione in un progetto di prova, personalmente ho optato per l’utilizzo di Redmine all’interno dell’organizzazione considerando la completezza delle sue funzionalità, valide oltre che come issue-tracker anche come strumento di project management a tutto tondo. La mia esperienza pregressa è stata principalmente nei confronti di tool commerciali come Jira (link) del quale sono presenti le principali funzionalità. L’espandibilità con un ricco set di plugin permette di colmare qualche mancanza del progetto principale, a mio parere i principali problemi di Redmine sono relativi ai plugin per l’integrazione con i principali IDE (traballante ma funzionante quella con Netbeans,  mentre non sono mai riuscito nell’integrazione con Eclipse) e alla generazione di rapporti customizzabili da utilizzare per i misuratori relativi alla qualità (defect leakage, trend report, …), funzionalità assente fino alla versione 3.2.1.

Infine, per chi vuole valutare ulteriormente l’applicazione è sicuramente degna di nota la possibilità di scaricare macchine virtuali pre-configurate dal sito Bitnami (link).

Leave a Reply