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 che siano risolvibili senza sviluppo di codice custom.
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) tramite viste
- 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 SSA, sebbene alcuni TASK di configurazione a tendere potranno esser svolti in autonomia da GA
Se il TASK non rientra nelle casistiche indicate il TL segnala l'incongruenza a GA e PO per una nuova analisi
Chi può aprire o segnalare una issue di tipo TASK ?
GA: supporto o attività di progetto
PM: attività di progetto
PO: supporto, richieste di mercato/change, attività di progetto, normativa, progetti interni
TL : adeguamento tecnologico, normativa dove non è necessaria approvazione del PO, progetti interni cineca
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 SSA
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: supporto o attività di progetto
PM: attività di progetto
PO: supporto, richieste di mercato/sviluppo prodotto, attività di progetto, normativa, progetti interni
RM: richieste di mercato, piano operativo, normativa, progetti interni
RU: attività di presale, richieste di mercato
QUANDO APRO UNA EPIC ?
Le issue di tipo Epic vengono utilizzate per raggruppare task o requirement al fine di generare la release note.
Nel caso dei portali assumono la funzione di rappresentazione di una macro attività.
Chi può aprire o segnalare una issue di tipo EPIC ?
PO: a seguito di una story generata da richieste di supporto, di mercato/sviluppo prodotto, attività di progetto, normativa, progetti interni
PM: fase di progetto
TL: adeguamento tecnologico, normativa, progetti interni
QUANDO APRO UN REQUIREMENT ?
I requirement servono a gestire tutte le attività di sviluppo
Nel caso dei portali consideriamo attività di sviluppo:
- creazione o modifica di moduli custom
- creazione o modifica script (jquery/javascript/phyton)
- scrittura o modifica funzioni hook del tema
invece vengono considerate configurazioni (salvo casi eccezionali per complessità o per tematiche completamente nuove):
- creazione o modifica al css
- templating con twig da interfaccia o su file del tema
Chi può aprire una issue di tipo REQUIREMENT ?
PO: a seguito di una story generata da richiesta di supporto, di mercato/sviluppo prodotto, attività di progetto, normativa, progetti interni
TL: adeguamento tecnologico, normativa quando non necessita approvazione PO, progetti interni cineca