...
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 SSA 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 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
...
Da una story possono poi derivare una issue di tipo requirement o epic contenente un insieme di requirement che verranno gestiti da SSA 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
...