"Quindi, voglio parlarti di Agile e Scrum ."
"All'inizio del 21° secolo, il modo in cui le persone pensavano alla programmazione è stato capovolto".
"Tutti erano convinti che la pianificazione a lungo termine non funzionasse, quindi hanno deciso di abbandonarla del tutto".
"Come hanno fatto?"
"Ecco come."
"Hanno inventato l'approccio di gestione dei progetti più flessibile possibile".
Ecco le idee principali alla base dello sviluppo agile :"
- le persone e la comunicazione sono più importanti dei processi e degli strumenti;
- un prodotto funzionante è più importante di una documentazione esaustiva;
- collaborare con il cliente è più importante che rispettare i termini di un contratto;
- la volontà di cambiare è più importante che attenersi al piano originale.
Ecco i principi del rapido sviluppo:
- soddisfare il cliente fornendo software di valore in modo tempestivo e continuativo;
- accogliere cambiamenti nei requisiti anche alla fine dello sviluppo (questo può aumentare la competitività del prodotto finale);
- consegnare frequentemente software funzionante (ogni mese o settimana o più spesso);
- stretta comunicazione quotidiana tra cliente e sviluppatori durante l'intero progetto;
- il progetto viene elaborato da persone motivate che ricevono le necessarie condizioni di lavoro, sostegno e fiducia;
- il metodo preferito per comunicare informazioni è una conversazione personale (faccia a faccia);
- il software funzionante è la migliore misura del progresso;
- sponsor, sviluppatori e utenti dovrebbero essere in grado di mantenere un ritmo costante per un periodo indefinito;
- attenzione costante al miglioramento dell'eccellenza tecnica e del design user-friendly;
- la semplicità è l'arte di non fare lavori superflui;
- i migliori requisiti tecnici, design e architettura provengono da un team auto-organizzato;
- costante adattamento alle mutevoli circostanze.
"Il problema principale con lo sviluppo del software era che in nessuna fase nessuno dei partecipanti aveva informazioni complete su cosa fare".
"Il cliente può dirti come immagina il programma, ma tralascerà qualcosa o darà qualcosa per scontato."
"Il manager generalmente deve tradurre i requisiti dal gergo di programmazione alla lingua del cliente e viceversa."
"C'è troppa incertezza".
"Spesso i requisiti del cliente sono così: fallo in qualche modo, poi mostramelo - se non mi piace, allora puoi rifarlo."
"Ehm... è orribile."
"Secondo il nuovo paradigma, i programmatori non stanno più sviluppando un prodotto o un programma. Invece, stanno implementando la funzionalità di cui il cliente ha bisogno."
"Qual è la differenza?"
"Bene, supponiamo che lo sviluppo del programma richiedesse un anno. E dovessero passare sei mesi prima che ci fosse qualcosa da guardare. È come costruire una grande casa: prima si scava una fossa per le fondamenta, poi si versano le fondamenta, il costruire le pareti, il tetto, le rifiniture, ecc."
"Ma ora i programmatori cercano di rilasciare le funzionalità necessarie il prima possibile. Sarebbe come costruire prima una capanna, poi una casa mobile, poi una piccola casa e solo dopo una grande casa, a rate".
"Considerando che il cliente probabilmente non sa esattamente cosa vuole, allora questo è un approccio molto ragionevole."
"Supponiamo che il cliente desideri un grande casino di caccia."
"Gli sviluppatori gliene costruiscono una piccola. Ci vive per un inverno. Poi decide che non gli piacciono le case di legno. Facciamone una di mattoni."
"Vive vicino al lago per un'estate, ma le zanzare lo divorano vivo. Aveva sentito da qualche parte che i laghi sono freschi, e così ha immaginato di averne uno. Ma ora non vuole un lago. E sarà più facile costruire la casa in questo modo: nessun lago significa nessuna minaccia di inondazioni, e puoi costruire la casa sul terreno invece che su palafitte, che sarà il 25% più veloce."
"Un'analogia interessante. I clienti cambiano davvero le loro esigenze così spesso?"
"Sì, ma il problema non è il cliente."
"In primo luogo, è molto difficile immaginare come andranno a finire le cose in futuro. Anche manager, tester e programmatori lo fanno. Cambiano anche idea a seconda di come vanno le cose."
"In secondo luogo, le esigenze del cliente non sono ciò che conta di più? Dopotutto , lo scopo di tutto questo lavoro è creare ciò di cui il cliente ha bisogno , non ciò che inizialmente ha detto di creare ".
"In effetti, funzionava così: gli analisti aziendali facevano un elenco di tutti i requisiti. Includevano questo elenco in un contratto, lo firmavano e lavoravano solo in base all'elenco".
"Se nell'elenco mancasse qualcosa di cui il cliente aveva davvero bisogno ma che aveva dimenticato, nessuno farebbe nulla al riguardo."
"Capisco. È più facile seguire un piano, ma non tutto può essere fatto secondo un piano!"
"Esattamente."
"Ecco perché sono stati inventati metodi di sviluppo agili".
"E oggi vi parlerò di Scrum , il più popolare tra loro.
"La caratteristica principale di Scrum è la divisione dello sviluppo del progetto in piccole iterazioni, di solito della durata di 2-4 settimane. Ogni iterazione è chiamata sprint."
"All'inizio di uno sprint si tiene uno sprint planning meeting. Dura 3-4 ore."
"Alla fine, c'è una dimostrazione di tutti i compiti completati."
"Ecco come funziona di solito:"
"Prima del primissimo sprint, il cliente (o un rappresentante del cliente) forma un elenco di requisiti, ovvero l'insieme di cose che il programma dovrebbe essere in grado di fare. Questi requisiti sono generalmente chiamati storie utente e il cliente è solitamente chiamato il proprietario del prodotto ."
"Si chiama proprietario del prodotto , perché il prodotto è scritto per lui. Lui, e solo lui, definisce l'elenco dei requisiti: cosa, quando e in quale ordine".
"Inoltre, il proprietario del prodotto di solito assegna le priorità delle attività. Le attività con la priorità più alta verranno implementate per prime. L'intero elenco dei requisiti è anche chiamato backlog del prodotto ."
"Quando inizia uno sprint, tutti si riuniscono per una riunione. Lo scrum master , in genere un membro del team, di solito guida la riunione. L'obiettivo della riunione è selezionare le attività ( user story ) per lo sprint corrente (iterazione dello sviluppo). "
"In primo luogo, il team assegna a ciascuna attività una stima approssimativa in giorni-uomo astratti, noti anche come punti della storia. Quindi il team decide quante attività avranno il tempo di completare durante lo sprint".
"Ancora una volta, è il team stesso che decide quante attività avranno il tempo di completare durante lo sprint."
"Supponiamo che il product owner si aspettasse che il team selezionasse le prime 7 attività ma ne ha selezionate solo 5, quindi le attività 6 e 7 vengono posticipate allo sprint successivo. Se ciò non soddisfa il product owner , può aumentare la priorità delle attività 6 e 7 per garantire che vengano selezionati, ma poi alcune delle altre attività verranno eliminate dallo sprint."
"Lo scrum master può anche proporre di suddividere alcune delle attività in attività più piccole e stabilire priorità diverse per rendere il proprietario del prodotto il più felice possibile."
"Questo è il punto della riunione: i compiti possono essere modificati e suddivisi, le priorità possono essere modificate, ecc. Questo è il lavoro che non era visibile all'inizio, ma che porta molto valore".
"Capito. È come guidare un'auto. Anche se inizialmente credi di dover solo andare dritto, la realtà è che devi costantemente evitare le buche, sterzare a destra e a sinistra e sorpassare gli altri o lasciare che ti sorpassino."
"Sì, qualcosa del genere."
"L'elenco delle attività scelte per lo sprint si chiama sprint backlog ."
"I programmatori decidono chi farà cosa, e solo allora si mettono al lavoro. "Per migliorare l'efficienza, Scrum suggerisce di tenere ogni giorno una riunione di 5-15 minuti in cui tutti possono raccontarsi cosa hanno fatto ieri e cosa sono faremo oggi".
"Lavoro di squadra. Posso rispettarlo!"
"Per rendere le cose più facili da visualizzare, di solito si consiglia di visualizzare lo stato corrente dello sprint su una bacheca speciale:"
"Nota le tre colonne a sinistra."
"I nomi abbreviati delle attività sono scritti su note adesive. E le note adesive sono posizionate in colonne diverse a seconda del loro stato (pianificato, in corso, completato)."
"Sulla destra, puoi vedere un grafico di burndown . Per ogni giorno, questo grafico elenca le attività che rimangono ancora incomplete. Idealmente, il numero di attività incomplete scende a zero durante lo sprint."
"Quando lo sprint è finito, lo scrum-master dà una demo per mostrare l'elenco di tutto ciò che è stato completamente completato."
"Poi tiene uno sprint retrospective meeting , che dura anche un paio d'ore. Durante questo incontro, i partecipanti di solito cercano di capire cosa è andato bene e cosa (e come) le cose avrebbero potuto essere fatte meglio".
"Di solito dopo 2-3 sprint, puoi identificare ed eliminare i problemi principali che impediscono al team di lavorare in modo più efficiente. Ciò porta a una maggiore produttività senza aumentare il carico di lavoro del team. Questo non era possibile prima dell'era delle metodologie agili. "
"A volte durante lo sprint si tiene anche una riunione di toelettatura. Il suo scopo è pianificare lo sprint successivo. I partecipanti di solito chiariscono le priorità delle attività in questa riunione. Possono anche suddividere alcune attività in parti e/o aggiungere nuove attività al backlog del prodotto . "
"Beh, questo è praticamente tutto quello che ho. Questa è solo una panoramica. È impossibile spiegare tutto in poche parole, ma puoi leggere un buon articolo sull'argomento qui:"
GO TO FULL VERSION