Scrum Scrum e ancora Scrum

1

Da diverso tempo la filosofia Agile ha stuzzicato la mia curiosità. Un po’ perché ho sbattuto il naso sui limiti del metodo Waterfall, un po’ perché sono passati venti anni (forse più, sorvoliamo suvvia…) da quando ho iniziato: ci sarà pur qualcosa di nuovo e migliore all’orizzonte?

Premetto che sull’argomento sono alle prime armi, ed è per questo che cerco un confronto.
Il perno da cui parte tutta l’idea, secondo me, è: le esigenze cambiano velocemente, più velocemente del tempo che si impiega a consegnare il software.
E qui entra in gioco Scrum, un metodo/framework per gestire lo sviluppo software in modo circolare e non a cascata, e che permette di adattare lo sviluppo nel tempo, fino ad arrivare alla consegna di un software che centra gli obiettivi, anche se questi sono cambiati nel tempo.
Affascinante a dir poco.
Per iniziare a capirne qualcosa mi sono guardato questa serie di video, di una software house che sviluppa soluzioni per organizzare il lavoro:

Riassumendo fino all’osso:

  • Vengono creati dei Teams, non più di 6/7 persone, interdisciplinari, a cui assegnare i progetti.
  • Il Product Owner mantiene aggiornato il Backlog, cioè la lista delle funzionalità che il prodotto in sviluppo deve avere.
  • Lo Scrum Master è l’esperto del metodo Scum ed è un facilitatore/conduttore delle varie Cerimonie.
  • A scadenze fisse (giornaliere, ogni due settimane…), con tempi di svolgimento differenti, il Team si ritrova (Cerimonia) per fare il punto su cosa è stato fatto e cosa si andrà a fare, in base al Backlog.
  • Tenendo conto di questi incontri e delle mutate esigenze del mercato/cliente, il Product Owner modifica il Backlog, cambiando priorità alle cose da fare, eliminando quelle superflue, aggiungendo le nuove.

Vi invito a vedere i video perché ho esposto il tutto in modo indecentemente riduttivo.

Ora, di domande/dubbi/perplessità ne avrei molte, ma il primo dubbio é:
Mi sembra un metodo che può essere usato da aziende di grandi dimensioni, con un personale numeroso, in cui puoi spezzare la tua forza lavoro in sottogruppi e dedicarli ai singoli progetti. Ma se la mia situazione fosse contraria? Cioè un numero ridotto di personale che segue molti progetti?
E` ancora utilizzabile e funzionale? In che modo?

2 Mi Piace
2

Non è facile dare una risposta anche perchè, per come l’ho inteso io, il movimento Agile si basa su dei principi volutamente poco normati (ma non significa poco chiari).
A chiunque si avvicina alla filosofia Agile consiglierei come prima cosa andare a fondo sui principi esposti nel manifesto. Le varie metodologie, più o meno agili, dovrebbero essere un po’ come un vestito che ti cuci addosso (tu inteso come alla tua organizzazione) e che aggiusti di giorno in giorno (magari perdi un kilo, magari lo prendi, magari serve una toppa sul gomito).
Personalmente seguo il movimento Agile dal 2000 circa, leggendo XP di Kent Beck, frequentando forum (agilemovement.it, ora credo non esista più) e mailing list (extremeprogramming).
Una cosa su cui ho sempre discusso in quei contesti è che non esiste il metodo “salvatutti” (il silver bullet della situazione), la differenza la fanno sempre le persone, sia nei metodi waterfall che in quelli agili. La loro esperienza, la loro apertura mentale, la loro autoconsapevolezza (intesa sia come personale che di gruppo/organizzazione).
Ci sono contesti in cui agile (metodo adattivo?) funziona bene altri dove funziona meglio waterfall (metodo predittivo?).
Se attacchiamo qui a discuterne possiamo andare avanti anni. Ti consiglio di seguire le fonti sul web, ce ne sono tante, che più senti affini e iniziare a sperimentare ma senza aspettarti chissà che cosa, ne mollare se al primo tentativo ti sembra di creare più confusione.
Una cosa che a me piace ma che non è facile usare, sia con Inde sia con le GUI, è il TDD.
Altra cosa che trovo super utile sono le sessioni di pair programming (che dovrebbero andare a braccetto con TDD ma anche senza sono super utili).
Ma la cosa che ho capito provando e riprovando è che devi sempre chiederti “mi serve questa cosa?” “la posso fare meglio?” “le persone con cui la metto in pratica quanto comprendono il valore di questa cosa?” “quanto è per me il valore di questa cosa?” e poi bisogna provare provare provare e poi …ancora provare :smiley:

Questa è solo una risposta veloce per darti il mio personale parere sull’argomento.
Chi, secondo me, porta avanti delle belle iniziative è Agile Reloaded https://agilereloaded.it/

Per rispondere a qualche domanda puntuale:
“Mi sembra un metodo che può essere usato da aziende di grandi dimensioni,” ti direi di no, il numero di componenti del team ideale di solito è 3-8. Le grandi aziende con più team che devono coordinarsi fanno fatica a implementare metodi agili. C’è un framework per questo, SAFE, ma è molto criticato da chi è nel settore.
“Un numero ridotto di personale che segue molti progetti” boh. Le persone sono coinvolte su più progetti contemporaneamente o ogni persona segue un progetto alla volta per almeno un paio di settimane? Può funzionare per entrambi i casi ma devi adattare il metodo alla situazione.
Contesto: un periodo di tempo (una settimana o due oppure un mese?). Due obiettivi: organizzazione del todo e realizzazione dei todo. Due risultati: il done e la misurazione del done rispetto ai todo (per stabilire capacità e velocità del team e valutare meglio le stime degli sprint successivi).
“E` ancora utilizzabile e funzionale?” per me ni. Ci sono in giro progetti e team sfasciati perchè applicano questa o l’altra metodologia agile come fosse i dieci comandamenti. Se applichi senza capire continui a girare il cacciavite anche con la vite spanata e pensi che il cacciavite è rotto.
Per me ogni metodologia va presa più come un caso di studio. Si devono capire contesto e team e capire come “traslare” nel nostro quotidiano qualche buona pratica.
In scrum la figura del PO e dello SM sono fondamentali, anche la loro sinergia.
I daily standup se son fatti male diventano una rottura di palle.
Etc etc.

P.S. la cosa più difficile nella modalità agile è la contrattualizzazione ma questo è un altro discorso.

3 Mi Piace
3

Segnalo questo articolo ben fatto:

2 Mi Piace
4

Uso questo thread per segnare risorse interessanti sull’argomento.

Qui si parla di SAFe

3 Mi Piace
5

Ciao, scusa per il ritardo estremo nella risposta, ma mi ero perso il thread.

Noi usiamo Scrum da 6 anni: i primi 3 un po’ “a caso” (e direi inutili :sweat_smile:) e gli ultimi 3 dopo aver fatto un corso Certified Scrum Master con Agile Alliance.

Siamo un team di 6 persone e ormai lo usiamo bene. Diciamo che “agile” è come dire “sport”, mentre Scrum è “i 100 metri piani”: una declinazione concreta di agile.

L’idea chiave è il miglioramento continuo: parti un po’ alla buona, poi a ogni sprint migliori qualcosa. Di sicuro lo sviluppatore è più felice e meno ingabbiato. Certo, il rischio “anarchia” o “pirateria” c’è, ma Scrum aiuta anche in questo.

Noi (friulani :grinning_face_with_smiling_eyes:) ogni due anni andiamo a Lubiana a fare il corso con Suzi Sochova, una Scrum evangelist super in gamba. Quest’anno coincideva con l’evento di Riccione, ma per noi era anche l’anno “no”, avendolo fatto l’anno scorso.

Il vero vantaggio è che rilasci software funzionante a ogni sprint. Noi facciamo sprint di 2 settimane — abbiamo provato quelle da 1, ma le sprint review troppo frequenti disturbavano i colleghi.

Scrum è rivoluzionario rispetto al metodo classico: va provato. Parti con uno sprint e poi decidi. Al massimo hai “perso” due settimane, ma in realtà avrai imparato un sacco.

La cosa più difficile per noi è che il Product Owner e lo Scrum Master sono anche sviluppatori — un mezzo sabotaggio di Scrum, ma nelle aziende piccole è normale: si fa tutto.

Abbiamo anche un collega indiano, quindi facciamo Scrum in inglese (solo noi dev parliamo inglese :sweat_smile:).

Direi: prova Scrum. Un corso in presenza è top, ma non indispensabile. È un framework flessibile che puoi adattare alla tua realtà.

Spero sia utile. Ciao!

4 Mi Piace