Questa mini guida ha lo scopo di definire uno standard nella gestione delle richieste sui portali indipendentemente dal canale che le ha generate.
Le tipologie di issue da utilizzare per iniziare a tracciare e convertire una richiesta in attività sono :
- BUG
- TASK
- STORY
- REQUIREMENT
- EPIC
QUANDO APRO UNA ISSUE DI TIPO BUG ?
I bug possono essere segnalati attraverso CUSTOMER TK, o direttamente da GA, PO, RM, RU, PM in caso di anomalia del backoffice che non permetta il completamento di una operazione redazionale o del frontend che non permetta la corretta consultazione totale o parziale di una pagina.
L’anomalia per esser e classificata come BUG deve essere ripetibile ed evidente, ovvero devono essere noti i passaggi che la generano e deve essere facilmente e universalmente riscontrabile l’evidenza del malfunzionamento su uno o più browser.
Il destinatario del BUG è sempre il TL che provvede alla gestione in ambito DSSA
Se il bug non è rilevato secondo i principi di ripetibilità ed evidenza il tk va passato a GA per una valutazione di secondo livello.
ATTENZIONE !
La mancanza di una funzionalità può essere ricunducibile a un errore, ma NON è classificabile come BUG.
Nel caso occorre verificare che la funzionalità fosse originariamente prevista per quel CUSTOMER (nel caso procedere con un TASK di manutenzione) e se così non fosse procedere con un TASK di tipo change o una STORY (a seconda delle caratteristica della funzionalità richiesta)
QUANDO APRO UNA ISSUE DI TIPO TASK ?
Le issue di tipo TASK vanno aperte per gestire sia le attività change sia in manutenzione ordinaria che in manutezione evolutiva e in generale per il supporto di terzo livello
Tipiche attività di tipo TASK sono:
- istallazione nuova docroot
- delivery nuovo multisite a progetto
delivery e configurazione iniziale di nuovo sito derivato da un modello noto (a prodotto o generato nell'ambito dello specifico progetto)
upgrade drupal core (minor realease)
delivery e upgrade moduli già noti ed approvati
verifica o esecuzione procedura di sincronizzazione dati
- attivazione nuova sincronizzazione dati standard
importazione dati massiva tramite migrate
- backup o esportazione dati tramite DB o VISTE
- creazione serivi rest o feed (solo output)
- implementazione e configurazione tipiche funzionalità backoffice a modello o da documentazione tecnica di progetto come:
- modifica/aggiunta di content type, tassonomie, media
- configurazione gestione visualizzazione form
- configurazione/attivazione moduli contrib o custom disponibili
- multilingua
- workflow e moderazione contenuti
- gestione gruppi redazionali, ruoli e permessi
- implementazione frontend come da documentazione tecnica di progetto
- modifiche al frontend esistente (a patto che non abbia impatti importanti sulle funzionalità) come:
- configurazione gestione visualizzazione
- modifiche ai template
- modifiche alle viste
- modifcihe ai fogli di stile
produzione di report di accessibilità
il destinatario dei TASK è sempre il TL che li valuta e provvede alla gestione in ambito DSSA, sebbene alcuni TASK di configurazione a tendere potranno esser svolti in autonomia da GA
Chi può aprire o segnalare una issue di tipo TASK ?
GA, PO, PM (nell’ambito di un progetto)
QUANDO APRO UNA ISSUE DI TIPO STORY ?
La issue di tipo story serve a ingaggiare il PO con lo scopo di valutare la liceità della richiesta stessa e di affinare / aggiungere funzionalità alla soluzione.
La story va aperta sulla coda di sviluppo offerta SO, assegnata al PO, e indicati CUSTOMER e COMPONENT.
Nella story va riportata e descritta con dovizia di particolari la richiesta e tutte le informazioni a contorno che si conoscono e che possono essere utili per una migliore valutazione.
Indipendentemente se si tratta di un progetto di avvio o di una richiesta pervenuta via tk si deve aprire sempre la story quando la funzionalità richiesta:
prevede la modifica a uno qualsiasi dei moduli custom di integrazione
prevede l’istallazione di un modulo drupal diverso da quelli approvati
prevede l’integrazione di un servizio extra rispetto a quelli già integrati prima
prevede la progettazione di una sezione o una funzionalità del portale non presente tra quelle censite a modello o fuori dallo scope di progetto
prevede l’ideazione di un nuovo modello di sito federato
prevede la modifica di uno dei modelli di sito esistenti (sia quelli a prodotto che quelli specifici del progetto)
fa parte di un pacchetto di modifiche richieste dallo stesso customer, da cui si evinca l’intenzione di un “parziale restauro” del proprio portale/ecosistema
prevede un nuovo progetto di avvio non a modello
Da una story possono poi derivare una issue di tipo requirement o epic contenente un insieme di requirement che verranno gestiti da DSSA
NON si deve aprire la story per richiedere attività in capo a DSSA quali:
microanalisi tecnica ai fini dello sviluppo
delivery delle soluzioni
problemi di infrastruttura
risoluzione di problemi normativi o legati alla sicurezza
verifica bug nel codice
test e qa applicativo
sviluppo codice
In questi casi l’ingaggio, se necessario, va fatto sulle issue di supporto, di prodotto o di progetto già aperte per dirimere la questione.
Chi può aprire o segnalare una issue di tipo STORY ?
GA, PO, RM, RU, PM, DSSA
QUANDO APRO UNA EPIC ?
Le issue di tipo Epic devono esser tutte generate da una story tranne nei seguenti casi:
- Epic di progetto (a cura del PM)
- Epic di adeguamento tecnologico (a cura del TL)
Chi può aprire o segnalare una issue di tipo EPIC ?
PO (processo story), PM (progetto), TL (adeguamento tecnologico)
QUANDO APRO UN REQUIREMENT ?
Le issue di tipo requirement sono aperte in automatico a partire dalla story e non devono essere aperte manualmente tranne nel caso di attività di adeguamento tecnologico (a cura del TL)
Chi può aprire una issue di tipo REQUIREMENT ?
TL (adegaumento tecnologico), PO (processo story)