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.
Metodo di pagamento
Anche se non possiamo finanziare lo sviluppo del progetto come consulente, la nostra intenzione è che il cliente paghi solo per il lavoro svolto. Proponiamo pertanto il seguente schema.
All’inizio del progetto, faremo una stima preliminare e di alto livello dello stesso, in un intervallo di ore-uomo. Dopo la creazione del suddetto backlog tecnico, confermeremo questa stima preliminare. In caso di deviazione significativa dai tempi stimati in precedenza, il cliente può decidere se continuare o meno con lo sviluppo del progetto. Pagherà solo l’analisi tecnica fatta dal nostro team.
Focalizzati sul raggiungimento di una modalità agile di lavoro mantenendo la flessibilità ai cambiamenti, proponiamo di pianificare ed eseguire iterazioni settimanali o quindicinali con obiettivi concreti da raggiungere. Nelle prime iterazioni di ogni nuovo progetto, gli obiettivi saranno diretti all’analisi, alla progettazione e al layout, in seguito allo sviluppo e all’implementazione dei componenti. In questo modo si avanzerà in un modello agile di sviluppo generando deliveries in ogni iterazione, avvicinandosi gradualmente al prodotto finale desiderato.
Verrà emessa un’unica fattura mensile per tutte le ore impiegate nelle iterazioni chiuse nel mese.
Fintanto che l’ambito non cambi, il totale delle ore non sarà mai superiore al totale stimato in ciascun caso e sarà sempre proporzionale al grado di avanzamento compiuto. In questo modo, si potrà pagare solo il lavoro effettivamente svolto e, a sua volta, si avrà un ampio controllo dell’obiettivo del progetto, restando a discrezione del cliente se desidera apportare ulteriori modifiche o meno.
Índice
Caratteristiche principali
Team Multidisciplinari E Auto-Organizzati
Sviluppo Agile
Aumenta La Motivazione Del 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
Consúltanos sin compromiso
Cuéntanos tu idea y te preparamos una propuesta
Glossario dei termini e delle buone pratiche
Anche se non abbiamo intenzione di spiegare SCRUM in modo approfondito, in questo spazio chiariremo diversi punti che saranno sicuramente utili o interessanti se si lavora con i nostri team di sviluppo Agile.
Definizione di Scrum
Scrum:
È un framework attraverso il quale le persone possono affrontare problemi adattivi complessi, fornendo prodotti in modo efficiente e creativo con il massimo valore.
Se hai domande concettuali o desideri approfondire le informazioni, ti suggerisco di cercare su https://www.scrum.org/
I Principi di Agile
Abbiamo ritenuto opportuno includere in questo articolo ciò che per noi è la TOP 5 dei 12 principi di Agile, in modo che la nostra filosofia sia meglio compresa.
- Deliver Value Faster: La nostra massima priorità è quella di soddisfare il cliente attraverso la consegna tempestiva e continua di software di grande valore.
- Welcome Changes: Benvenuti siano i cambiamenti dei requisiti, anche alla fine del progetto. I processi agili sfruttano questo cambiamento per generare un vantaggio competitivo per il cliente.
- Work Together Every Day: Lavorare insieme ogni giorno: Il product owner, lo scrum master e l'intero team di scrum devono lavorare insieme quotidianamente durante l'intero progetto e con un unico obiettivo.
- Working Software is Key: Il software di lavoro è la chiave: Il funzionamento del software è il principale supporto di progresso.
- Simplicity: L'arte di massimizzare la quantità di lavoro non svolto è fondamentale.
Ruoli Chiave
I seguenti ruoli nella nostra implementazione di SCRUM meritano di essere chiariti.
Product Owner
È la persona che conosce il prodotto, sa di cosa ha bisogno, cosa è davvero importante e cosa non lo è. La sua responsabilità principale è interpretare il cliente (funzionalità chiave, priorità, budget, mercato, deadline, ecc.) e trasmettere al team ciò che si desidera costruire, fornendo tutte le informazioni necessarie per portare avanti lo sviluppo.
Scrum Master
Oltre ad essere un "facilitatore" per eseguire SCRUM come dovrebbe essere, sarà il principale punto di contatto con il product owner per aiutarti in tutto ciò che sia necessario.
Artefatti
I seguenti artefatti sono quelli che riteniamo meritino una spiegazione dettagliata.
User Story
È una definizione molto alta di un requisito. Dovrebbe contenere informazioni sufficienti per consentire agli sviluppatori di stimare lo sforzo per implementarlo.
Una buona User story dovrebbe considerare tutti e tre le "W" (who, what, why). Cioè, chi (who) eseguirà qualcosa, cosa (what) è quello che farà e per cosa (why). Inoltre, deve soddisfare il criterio INVEST:
-
- 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.
Cerimonie
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.
