La Nostra Metodologia
Di Sviluppo Agile
Negli sviluppi tradizionali, quando i requisiti non sono perfettamente definiti a livello funzionale e tecnico, i progetti sono stimati con un certo margine di errore, il che non è preferibile per vari motivi:
- La probabilità di deviazione in tempi e costi è molto alta.
- Si corre un alto rischio di sopravvalutare o sottovalutare il progetto, compromettendo le finanze del cliente o della società di consulenza.
- Per rispettare il piano, non sarà mantenuta la necessaria flessibilità per le modifiche dei requisiti, che possono avere un impatto su un prodotto finale che non soddisfa i requisiti che il mercato dovrebbe soddisfare.
- Si verifica un’usura dell’attrezzatura dovuta a costanti discussioni per scadenze, tempi e costi.
Pertanto, con l’obiettivo di realizzare uno sviluppo che mantenga la flessibilità nei requisiti ma senza intaccare i costi del progetto oltre a quanto effettivamente necessario, adottiamo la seguente metodologia Agile, basata su Scrum.
Ciclo di vita del progetto
Il nostro obiettivo è quello di fornire un prodotto di qualità il più rapidamente possibile attraverso uno sviluppo evolutivo flessibile ai cambiamenti, quindi utilizziamo SCRUM implementando il processo come segue:
Il cliente, in qualità di principale referente e stakeholder, dovrà fornire al Product Owner, tutte le informazioni necessarie (sotto forma di user stories correttamente definite) in modo da poter trasformare queste User Story in product backlogs utilizzabili dal team, che non sono altro che le funzionalità del sistema da sviluppare correttamente definite. Se non si dispone di un tale livello di definizione, forniremo supporto al cliente per creare il suddetto backlog tecnico*.
* Il “backlog tecnico” non è un vero e proprio documento SCRUM, ma un nostro documento interno che fornisce il livello di dettaglio sufficiente per delimitare l’architettura e l’ambito tecnico-funzionale del prodotto da sviluppare. I diagrammi, le strutture o le definizioni che contiene dipendono dalla natura di ciascun sistema. L’obiettivo non è quello di fornire una documentazione finale del progetto, bensì una definizione tecnica precisa e sufficiente per effettuare una stima a basso margine di deviazione.
Importante
Prima di procedere con il primo sprint, è necessario disporre di tale backlog tecnico che consenta di delimitare l'ambito del progetto e confermare la stima preliminare.
Ciascuno di questi product backlog sarà trasformato in sprint backlogs (funzionalità specifiche da sviluppare in un’iterazione) in una riunione di Planning, che si svolge immediatamente prima dell’inizio di ogni sprint. Durante questa fase, il main stakeholder o referente del cliente, insieme al product owner e allo scrum team, definiscono ciò che verrà costruito nella successiva iterazione. Le iterazioni potrebbero essere sia settimanali che quindicinali, a seconda di vari fattori.
Durante la stessa si svolgono quotidianamente varie attività in forma ciclica e ripetitiva. Una delle principali consiste nel processo di perfezionamento o riunione di Refinement
dei product backlog in modo che abbiano tutte le informazioni necessarie affinché il team possa includerlo nello sprint successivo (non nello sprint in corso). In questa cerimonia è necessaria la partecipazione del cliente.
Ogni giorno si svolge un daily meeting interno. Al fine di fornire trasparenza, proponiamo al cliente di realizzare una weekly meeting per avere un punto di contatto e controllo di avanzamento.
Ogni iterazione completata produce un risultato più raffinato rispetto all’iterazione precedente. Questo processo viene ripetuto fino al completamento dello sviluppo concordato. Nella Sprint Review, alla chiusura di ogni sprint, la consegna viene presentata al cliente.
Nel corso del progetto viene utilizzato il software Agile.MyTaskPanel come strumento di gestione online del progetto per fornire visibilità durante l’intero ciclo di sviluppo. Un user verrà consegnato al cliente in modo che possa seguire quotidianamente lo stato del progetto.
Índice
Caratteristiche principali
Team Multidisciplinari E
Auto-Organizzati
Sviluppo Agile
Aumenta La Motivazione
Nel Team
Cliente Integrato
Nel Team
Feedback Rapido Del
Prodotto In Fase Di Sviluppo
Flessibilità Nell'Integrazione
Delle Modifiche
Riduzione Del Tempo Di
Consegna Finale Del Progetto
Contattateci senza impegno
Comunicateci le risorse di cui avete bisogno e prepareremo una proposta per voi
-
- Independent (indipendente): ogni User story deve essere auto-spiegabile, non deve dipendere da altre User story.
- Negotiable (Negociable): evitar incluir demasiado detalle, para que las historias de usuario sean flexibles y puedan ser modificadas.
- Valuable (Pregiato): le User story devono fornire un valore aggiunto all’utente finale.
- Estimable: (Stimabile): devi essere in grado di stimare le risorse necessarie per completare ogni User Story.
- Scalable (Scalabile): semplifica le User story, in modo che possano essere affrontate e prioritarie.
- Testable (Verificabile): spiega i criteri di verifica e approvazione, in modo che il team li conosca e li applichi quando una storia è completa.
Checklist per accettare una User Story
- La User story contiene tutte e tre le "W"?
- È conforme al criterio INVEST?
- I criteri di accettazione sono chiaramente definiti?
Esempio
È un caso molto semplice, ma credo che chiarisca i concetti spiegati prima. Come startup founder, voglio essere in grado di creare un account sul sito XYZ, in modo da potermi unire alla comunità di investitori e mentori.Criteri di accettazione
- Essere in grado di creare un account manualmente (compilando il modulo di sign-up)
- Creare un account tramite Google
- Creare un account tramite Facebook
Product Backlogs
Non è altro che le User story trasformate in una lista prioritaria di risultati (deliverables) che devono essere implementati attraverso il processo di sviluppo. Un product backlog item (PBI) è un unico elemento di tale elenco. Esso deve contenere tutte le informazioni necessarie affinché il team possa eventualmente includerlo in un’iterazione (trasformato in uno sprint backlog).
Potrebbe sembrare inizialmente che sia come una user story, ma non lo è. Quest’ultima va oltre un cambiamento o una richiesta in particolare. Mette l’utente al centro e descrive una caratteristica del sistema dal suo punto di vista.
Sprint Backlog
Durante la riunione di Planning, si selezionano i PBI che formeranno parte del prossimo sprint e si dividono in uno o più sprint backlog item (SBI). In poche parole, non è altro che un PBI in uno sprint. In realtà, è un po’ di più, perché è necessario che tale SBI abbia un livello di dettagli più elevato. Inoltre, un PBI può generare diversi SBI.
Non sono altro che riunioni con diversi partecipanti e progettate per scopi molto specifici. Per essere chiari, non si commenterà tutto ciò che si svolge in tali riunioni, ma si chiarirà la finalità di tali riunioni.
Planning
In questo incontro, che si svolge prima dell’inizio di uno sprint, i PBI che si sviluppano all’interno dello stesso vengono selezionati e trasformati in SBI.
Refinement
In questa riunione, che si verifica nei primi giorni dell’inizio di un’iterazione, vengono analizzati e perfezionati i PBI da sviluppare nello sprint successivo (non nell’attuale). Cioè, si riducono ad un livello di dettaglio sufficiente per poter essere ulteriormente sviluppati.
Daily
Questa riunione quotidiana serve a vedere ciò che è stato fatto il giorno prima, ciò che sarà fatto in giornata odierna e gli impedimenti che potrebbero esistere.
Review
In questa riunione, che si svolge al termine di un’iterazione, viene presentato al cliente il risultato della stessa.
