...
Le tipologie di issue da utilizzare per iniziare a tracciare e convertire una richiesta in attività sono :
- BUG → coda PTL
- TASK → code PTL
- STORY → coda SO
- REQUIREMENT → coda PTL
- EPIC → coda PTL, SP_1
alcune premesse sulla guida:
- sono indicati i ruoli di responsabilità, non necessariamente quelli che svolgono l'attività o l'analisi
- per DSSA si intende un qualsiasi membro del team di di disegno e sviluppo soluzioni applicative
- la linea di demarcazione tra cosa considerare sviluppo e cosa configurazione è motivata dall'architettura di Drupal, dall'esperienza nell'ambito e dalle modalità di svolgimento del lavoro quotidiano e ha lo scopo di evitare sprechi di risorse e di allungare oltre misura i tempi di alcune lavorazioni senza che ce ne sia una reale necessità.
- la guida comprende(rà) i documenti descrittivi del modello funzionale della soluzione portali così come viene erogata a ottobre 2024 e le sue future evoluzioni.
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.
...
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)
Chi può aprire o segnalare una issue di tipo BUG ?
CC: supporto livello1
GA: supporto livello 2
PO,RM,PM,RU,TL,DSSA: quando notano un malfunzionamento che compromette la fruibilità delle informazioni del sito all'utente finale o che non permette di utilizzare una o più funzionalità del backoffice
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 DSSA, 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, PO, PM (nell’ambito di un progetto): 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 ?
...
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 per richiedere attività in capo a DSSA quali quali:
microanalisi tecnica ai fini dello sviluppo
delivery delle soluzioni
problemi di infrastruttura
risoluzione di problemi normativi (se su normativa già conosciuta o applicata) 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: 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 devono esser tutte generate da una story tranne nei seguenti casi:
...
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 (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)
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 cinecaTL (adegaumento tecnologico), PO (processo story)