Skip to main content

Sprint Standards

Sprint (WIP)​

Definizione​

Lo sprint è il periodo compreso tra 3 giovedì composto da 9 giorni lavorativi nella quale il team si impegna a raggiungere gli obiettivi definiti nella definizione dello stesso.

Struttura​

  • Ad ogni sprint dovrà essere associata una release con lo stesso nome ed una data definita
  • La descrizione dello sprint dovrà includere la data di release e gli obiettivi macro
  • Per ogni obiettivo indicato in sprint goal dovranno esistere altrettante storie in corrispondenza biunivoca.
    • Ogni storia dovrà illustrato l'obbiettivo che si vuole raggiungere e la definizione di completamento della storia. Deve essere chiaro al lettore (indipendentemente dal ruolo) cosa produrrà la storia e perché.
    • La storia verrà suddivisa in sotto-task più specifici che verranno usati per lo sviluppo effettivo. Ad ogni sotto-task verrà associato un branch con lo stesso nome del task.

Workflow Task​

I task seguiranno il workflow attualmente definito che parte dallo stato OPEN (task inserito ed ancora da gestire) a Released (task rilasciato in produzione).

Tranne rare eccezioni tutti i task dovranno passare dalla fase di design che consiste in:

  • Simulazione intervento con schema file da modificare ed eventuali variazioni del db (variazioni più grosse richiedono la condivisione di uno schema ER)
  • Eventuali proposte grafiche (Figma o anche disegno su carta). La proposta grafica è necessaria nel caso di task di front-end o riguardanti elementi dei clienti. (rif. Struttura proposta grafica)
  • Definition of done

Al completamento del task si dovrà:

  • testare approfonditamente il task sul relativo sito di sviluppo e solo dopo aver appurato il corretto funzionamento si potrà eseguire la pull-request.
  • Il task rimarrà nello stato di testing finché almeno un altro membro del team non avrà approvato la pull-request.
  • Ottenuta l'approvazione esterna della pull-request si potrà procedere con l'aggiornamento del task da "In Testing" a "In review"
  • Le pull-request "in review" verrà revisionate dal responsabile presente ed eventualmente mergiate a master. Prima del merge, verrà eseguito lo squash del branch.

Giorno della Release​

WIP (rif. Runbook)