IT Area - Linee guida_V1
Struttura e Gestione Operativa in Jira – Area IT
Overview Toolchain: Discovery to Delivery
Un processo strutturato in sei fasi per trasformare opportunità commerciali in iniziative reali, tracciabili e allineate alla strategia aziendale.
| Fase | Strumento | Attività | Owner |
|---|---|---|---|
| Definizione Strategica | Goals (Atlassian) | Definizione degli obiettivi strategici e case study chiave, assegnati a team o individui | Direzione / Sales |
| Raccolta Idee | Jotform | Raccoglimento di insight, opportunità e richieste tramite form strutturato | Sales |
| Validazione Tecnico/Strategica | Excel | Analisi tecnica e strategica su Excel per valutare interesse, effort e allineamento con Piano Aziendale | Program Manager / CTO |
| Prioritizzazione e Roadmap | Jira Product Discovery (JPD) | Fattibilità, Organizzazione, prioritizzazione e collegamento delle idee ai Goals tramite roadmap condivise | Program Manager / PM |
| Finalizzazione Contratto e Attivazione Progetto | Contratto → SAP/Jira | Firma del contratto → allineamento con Program Manager, PMM e Controller → apertura progetto nei sistemi aziendali | Program Manager / Controller / PMM |
| Delivery Operativo | Jira Software | Trasformazione in Epic, Story, Task e gestione operativa del progetto tracciata nello spazio Jira | Controller / AM / PM / Demand Manager |
Focus del documento: fase Delivery Operativo
Struttura e Gestione Operativa in Jira
| Livello | Descrizione | Creazione | Pianificazione | Assegnazione |
|---|---|---|---|---|
| Spazio Jira (ex progetto) | Commessa di tipo: Produttivo - R&D - Bandi | Controller | — | Controller |
| Epic | Deliverable | Demand | Demand | Demand |
| Story | Funzionalità del deliverable | Demand | Demand | Demand |
| Ticket gestionali o di supporto | Task che non richiedono tracciamento orario (Redazione documentazione - Hardware / DevOps - Rilascio) | Demand | Demand | Demand |
| Ticket esecutivi | Task e sottotask che richiedono tracciamento orario puntuale, assegnati individualmente (Bug - Helpdesk - Task_swhw - Sviluppo - Test - UX/UI - Analisi - Manualistica) | Demand / Tech Lead | Team Leader | Team Leader |
Flusso Semplificato del Processo Jira IT
1. Creazione dello Spazio (ex Progetto)
Controller Ordina la creazione dello Spazio Jira (ex progetto) ed indica PM di riferimento assegnato con ruolo di «Coordinatore del progetto Jira»
PM (Coordinatore spazio Jira/commessa) Aggiunge gli utenti allo spazio assegnando i ruoli
2. Avvio del Processo di Lavoro
Demand Crea (e assegna) l'Epic deliverabile e compila i campi obbligatori comunicati da PM:
- n° Pezzi Produzione richiesti (stima FTE cliente)
- Data di scadenza (delivery verso cliente)
3. Definizione Operativa
Demand Crea una o più Story per ogni funzionalità del deliverable. Crea i Task e sottotask necessari alla story di tipo:
- esecutivo
- analitico/funzionali
Ove necessario, assegna i task e sottotask ai Team Leader per la successiva stima e pianificazione
4. Assegnazione e Pianificazione
Team Leader Assegna agli utenti i sottotask esecutivi. In fase di avanzamento (secondo stato) compila/verifica l'inserimento dei dati obbligatori:
- Stima originale (FTE stimato reale)
- Start Date [Gantt] (pianificazione)
- End Date [Gantt] (pianificazione)
Demand Ridefinisce - se necessario - la pianificazione e stima di Story e Epic. Compila i campi obbligatori:
- Start Date [Gantt] (pianificazione)
- End Date [Gantt] (pianificazione)
* possibilità di validare i dati direttamente dal Gantt
5. Esecuzione e Monitoraggio
Assegnatari ticket
- Devono SEMPRE aggiornare lo stato di tutti i ticket assegnati, indipendentemente dalla tipologia (Sottotask, Task, Story, Epic). Ogni ticket deve essere chiuso al completamento.
- Per i ticket esecutivi, il corretto aggiornamento dello stato è fondamentale per la rendicontazione delle ore tramite Clockwork.
- Anche nel caso di svolgimento attività ONP direttamente riconducibili alla commessa specifica (con ore dichiarative), è obbligatoria la creazione quotidiana del ticket.
Reporter/Richiedenti Il reporter di ciascun ticket è il responsabile del corretto avanzamento e dell'accuratezza dei dati inseriti.
Flusso Semplificato del Processo Jira IT: Focus Step Principali in Gantt
2. Avvio del Processo di Lavoro + 3. Definizione Operativa
Demand = Crea una o più Story per ogni funzionalità del deliverable. Crea i Task e sottotask necessari alla story (di tipo esecutivo e analitico-funzionali). Ove necessario, assegna i task e sottotask ai Team Leader per la successiva stima e pianificazione. Quindi crea il Gantt del progetto (in questo step risulterà privo di qualunque dato relativo alla pianificazione – esempio in foto).
4. Assegnazione e Pianificazione
Team Leader = Assegna agli utenti i sottotask esecutivi; in fase di avanzamento (secondo stato) compila/verifica l'inserimento dei dati per la pianificazione
Demand = Ridefinisce - se necessario - la pianificazione quindi compila i campi obbligatori di Story e Epic convalidando i dati visualizzati in gantt con il comando in foto
Tabella Compilazione Campi Obbligatori
| Nome Campo Jira | Descrizione | EPIC | Story | Ticket esecutivi | Ticket Gestionali o di supporto | |
|---|---|---|---|---|---|---|
| Pianificazione cliente | n° Pezzi Produzione richiesti | Stima FTE comunicata a cliente (Target produttivo stabilito per il ticket) | Obbligatorio | non presente | non presente | non presente |
| Pianificazione cliente | Data consegna cliente | Delivery date comunicata a cliente (Deadline stabilita per l'Epic) | Obbligatorio | non presente | non presente | non presente |
| Pianificazione interna | Stima originale | Stima FTE reale prevista (Target interno di efficienza stabilito per il ticket) | Automatico – sommatoria proveniente dai ticket subordinati | Automatico – sommatoria proveniente dai ticket subordinati | Obbligatorio al 2° passaggio di stato | non necessario |
| Pianificazione interna | Start Date [Gantt] – Start date pianificato, si compila automaticamente | Data di inizio attività pianificata per il ticket | Obbligatorio al 3° passaggio di stato (possibilità di validare i dati direttamente dal Gantt – vedi slide precedente) | Obbligatorio al 2° passaggio di stato (possibilità di validare i dati direttamente dal Gantt – vedi slide precedente) | Obbligatorio al 2° passaggio di stato | non necessario |
| Pianificazione interna | End Date [Gantt] – Data di scadenza, si compila automaticamente | Data di fine attività pianificata per il ticket | Obbligatorio al 3° passaggio di stato (possibilità di validare i dati direttamente dal Gantt – vedi slide precedente) | Obbligatorio al 2° passaggio di stato (possibilità di validare i dati direttamente dal Gantt – vedi slide precedente) | Obbligatorio al 2° passaggio di stato | non necessario |
| Start Date | Data di inizio attività effettiva del ticket | Automatico al 1° passaggio nella categoria di stato attivo | Automatico al 1° passaggio nella categoria di stato attivo | Automatico al 1° passaggio nella categoria di stato attivo | Automatico al 1° passaggio nella categoria di stato attivo | |
| End Date | Data di fine attività effettiva del ticket | Automatico al passaggio nella categoria di stato finale | Automatico al passaggio nella categoria di stato finale | Automatico al passaggio nella categoria di stato finale | Automatico al passaggio nella categoria di stato finale |
Identificazione Ticket
| Tipo | Livello | Descrizione | Contenitore di riferimento | Tracciamento temporale |
|---|---|---|---|---|
| Epic | Epic | Contenitore principale del flusso, richiesta strutturata deliverabile o attività non progettuali (es. onboarding, piccoli supporti) | Spazio (ex Progetto) Jira | — |
| Story | Task | Breve descrizione di una funzionalità, spiega come un determinato lavoro apporta valore all'utente o al cliente. Formato tipico: "Come [utente], voglio [azione], così da ottenere [beneficio]." | Epic | — |
| Redazione documentazione | Task | Contenitore di attività di produzione di documentazione, non legata a una singola Story, includono sottotask specifici. | Epic | — |
| Hardware / DevOps | Task | Attività sistemistiche, script, configurazioni, ambienti, accessi, ecc. | Epic o nulla | — |
| Rilascio | Task | Attività di rilascio pianificate (inclusione nel GANTT) | Epic o nulla | — |
| Bug | Task | Tracciamento anomalie riscontrate (Assegnazione individuale) | Epic o nulla | Clockwork automatico |
| Helpdesk | Task | Supporto o richieste operative (Assegnazione individuale) | Epic o nulla | Clockwork automatico |
| Task_swhw | Task | Attività operative, non funzionali, non rientranti nelle ordinarie casistiche (es. creazione utenze, bonifiche dati) (Assegnazione individuale) | Epic o nulla | Clockwork automatico |
| Analisi | Sottotask | Raccolta requisiti, stime, HLD, stesura documenti – Assegnazione individuale | Story, Redazione documentazione | Clockwork automatico |
| UX/UI | Sottotask | Impatti sull'interfaccia utente: progettazione/revisione grafica – Assegnazione individuale | Story, Redazione documentazione | Clockwork automatico |
| Sviluppo | Sottotask | Realizzazione tecnica e implementazione. Include bug fixing post-test – Assegnazione individuale | Story | Clockwork automatico |
| Test | Sottotask | Verifica dello sviluppo. In caso negativo implica riapertura sottotask sviluppo o nuova creazione. Assegnazione individuale | Story | Clockwork automatico |
| Manualistica | Sottotask | Realizzazione documentazione tecnica o manuali utente – Assegnazione individuale | Story, Redazione documentazione | Clockwork automatico |
| ONP_S | Task | Contenitore per attività non produttive (es. formazione, riunioni, Tech Review, Code Review …) | Epic, Epic ONP dedicato | — |
| ONP_sottotask | Sottotask | Registrazione giornaliera delle specifiche ore ONP – Assegnazione individuale | ONP_S | Log manuale |
Workflow Ticket
Epic
Stati del workflow (in ordine): Create → STIMA ← Tutto → ANALISI → SVILUPPO ← (Test non superati – loop) → TEST → UAT → RILASCIO → COMPLETATO | RISOLTO ← Tutto
Redazione Documentazione / Hardware/DevOps / Rilascio
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → COMPLETATO | RISOLTO ← Tutto (IN PENDING ← IN CORSO, IN PENDING → In pausa)
Story
Stati del workflow (in ordine): Create → STIMA ← Tutto → IN CORSO ← (IN PENDING – Sospendi) → RILASCIO → COMPLETATO | RISOLTO ← Tutto
Bug
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → IN REVIEW → IN TEST DI INTEGRAZIONE → RILASCIARE IN TEST → TESTING → RILASCIARE IN PRODUZIONE → COMPLETATO | RISOLTO ← Tutto
Helpdesk / Task_swhw
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → COMPLETATO | RISOLTO ← Tutto
Sviluppo
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → IN REVIEW → IN TEST DI INTEGRAZIONE → RILASCIARE IN TEST → TESTING → RILASCIARE IN PRODUZIONE → COMPLETATO | RISOLTO ← Tutto
Analisi
Stati del workflow (in ordine): Create → DA STIMARE ← Tutto → STIMATO → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → IN REVIEW → IN APPROVAZIONE → COMPLETATO | RISOLTO ← Tutto
Manualistica / Test
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → COMPLETATO | RISOLTO ← Tutto
UX/UI
Stati del workflow (in ordine): Create → DA STIMARE → DA FARE ← Tutto → IN CORSO → IN PENDING (In pausa) → IN REVIEW → COMPLETATO | RISOLTO ← Tutto
Tracciamento Orario (Time Tracking)
Il sottotask rappresenta l'attività giornaliera svolta dall'utente per uno specifico task, per cui è necessario abilitare il tracciamento automatico delle ore lavorative tramite il plugin Clockwork – attivato/disattivato automaticamente in base allo stato del ticket.
Al momento della creazione dell'elemento, è obbligatorio inserire una stima del tempo originale per il completamento dell'attività. Ogni giorno, la stima residua si aggiorna automaticamente in base ai log di lavoro registrati dall'utente all'interno dell'elemento. Questo aggiornamento avviene automaticamente non appena l'utente sposta il sottotask nello stato attivo "IN CORSO" e si mette in pausa ogni volta che il sottotask viene spostato in uno stato non attivo.
Nel caso di creazione di ticket NPH e NPH_sottotask (dedicati ad attività non produttive ma comunque collegabili al progetto — es. riunioni con il cliente su argomenti specifici), il tracciamento del tempo non avverrà automaticamente, ma dovrà essere fatto manualmente compilando un apposito campo.
Nota: Solo un ticket con tracciamento automatico del tempo può essere attivo in un dato momento. Quando un nuovo ticket viene spostato in "IN CORSO", quello attivo viene automaticamente spostato in "IN PENDING". Questa logica non si applica ai ticket per cui non è richiesto l'uso del tracciamento automatico con Clockwork (es. Epic, Task, NPH, ecc.).
Logica degli stati per il tracciamento:
- Creazione → STATI NON ATTIVI
- Inizio lavoro → STATO ATTIVO (timer START) ← ripresa lavoro
- Lavoro in pausa → STATO NON ATTIVO (timer STOP, PENDING)
- Lavoro completato → STATO FINALE (timer STOP)