Ti è mai capitato di utilizzare un software che non fosse pienamente conforme alle tue esigenze o a quelle dei tuoi colleghi? O che in azienda alcuni dipendenti non riescano a raggiungere una reale autonomia con gli applicativi installati?
Non preoccuparti, non sei solo/a. Probabilmente hai sempre pensato che la causa fosse la (poca) dimestichezza con gli strumenti digitali. Ma la verità è un'altra. Nella progettazione di quel prodotto è probabilmente mancato qualcosa: un approccio orientato all'utente. Ecco perché nel mondo informatico viene in aiuto Scrum.
Spesso gli strumenti IT adottati dalle imprese, in particolare quelli amministrativi e documentali, sono completi e ricchi di funzionalità. Eppure qualcosa ti impedisce di lavorare al meglio.
La colpa, nella gran parte dei casi, non è dell'utente.
La verità è che quando un prodotto risulta difficile per chi lo utilizza, la responsabilità è di chi ha progettato quel prodotto.
Il concetto risale agli albori del design industriale e, oggi più che mai, in un'epoca in cui è il consumatore a decidere il mercato, continua a essere attuale. Sono i prodotti stessi che devono insegnare come venir utilizzati: il libretto di istruzioni è sparito.
Anche nel mondo del software vi è stato un tempo in cui i developer sviluppavano secondo il principio de "l'importante è che funzioni". Poco importava se l'usabilità era carente.
Oggi questo paradigma si è letteralmente ribaltato: qualsiasi funzionalità non può essere realizzata senza un'analisi delle esigenze dell'utente→ e delle modalità con cui questi cerca intuitivamente di risolverle.
A maggior ragione quando si parla di prodotti customizzati: sempre più aziende si orientano su software su misura→ proprio per far fronte a necessità che i prodotti sul mercato non tengono in considerazione.
Con i metodi di progettazione tradizionali, però, il prodotto viene consegnato solo alla fine.
Ma cosa succede se, solo alla fine, ci si accorge che qualcosa non va, che il software è incompleto o insoddisfacente?
Non è sempre facile capire, sin da principio, in che modo un prodotto può risolvere le varie necessità. Non è sin da subito chiaro quali requisiti bisogna soddisfare. Non è improbabile accorgersi, in fase di realizzazione, che qualcosa risulta superfluo o incompleto.
Il digitale è di natura adattabile. Progettare un software significa adottare un metodo che sia flessibile e al contempo efficiente.
La flessibilità, infatti, non va intesa come possibilità di modificare a piacimento e all'improvviso i requisiti bensì strutturare una modalità di lavoro e sviluppo in grado di far fronte in modo proattivo a nuove necessità, senza che queste diventino un'ostacolo.
Il principio di base affinché la flessibilità costituisca un'alleata, e non una fonte di intralcio, è la continua iterazione tra sviluppatori e cliente: è necessario modificare il mindset nella progettazione, passando da un approccio waterfall a un metodo incrementale. Insomma, è necessario adottare una mentalità Agile.
Nel mondo dello sviluppo software il metodo (o, meglio, il framework) maggiormente utilizzato per rispondere a questo principio è Scrum.
Vediamo di cosa si tratta.
Per capire il cuore della mentalità, partiamo dall'origine etimologica. Il significato della parola Scrum è "mischia" e deriva dal mondo del rugby. In questo sport, durante una mischia, i componenti della squadra devono trascinarsi vicendevolmente in sinergia, avanzando a piccoli passi verso la meta.
Nasce da queste premesse un vero e proprio framework. Si supera il vecchio modello di sviluppo sequenziale (progettazione di masse di lavoro, suddivisione in ruoli, approvazioni finali in blocco), per preferirvi un'ideale incrementale.
La metodologia Scrum si basa su empirismo e iterazione. Significa che nella creazione del software ogni operazione (anche la più piccola) viene ripetuta e riprovata. In base all'esperienza ottenuta si prendono decisioni su come proseguire. Proprio come nella mischia da rugby, si passa la palla avanti e indietro, per trovare il momento ideale per avanzare.
In Scrum la squadra si suddivide in soli tre ruoli, proprio per maggiore agilità.
La squadra non prevede un capo o un manager che decide per gli altri: è invece cooperativa. Ogni membro è autonomo e responsabile in egual modo del successo del progetto.
Il progetto viene suddiviso, in accordo fra tutti i membri del team, in piccoli parti, ognuna delle quali si concluderà con la realizzazione di un pezzo di prodotto perfettamente funzionante.
Questi due principi rimuovono l'effetto waterfall, dove ogni persona deve continuamente approvare il lavoro altrui per consentirne il proseguimento.
Inoltre, conferiscono un senso di maggiore responsabilità a ogni componente del gruppo.
I software realizzati con metodo Scrum, danno grossi vantaggi nel prodotto finito, innanzitutto perché si basano sull'analisi approfondita della singola azienda, come vuole il BPO→.
Ma è lo sviluppo incrementale e iterativo a portare maggior valore. Il metodo Scrum presenta infatti grande trasparenza per l'azienda committente perché prevede dei momenti dedicati a visualizzare lo stato del lavoro: in ognuno di essi si espongono status e obiettivi dello sviluppo, sia a breve che a lungo termine. Questi momenti vengono quindi sfruttati per ottimizzare lo sviluppo del software customizzato, ripetendo l'analisi e le prove se necessario.
Scrum permette aggiunte, modifiche e miglioramenti in corso di sviluppo, per rispondere in modo strutturato a esigenze sconosciute o non emerse in fase di analisi, a problemi imprevisti, a requisiti nuovi.
L'adattabilità è importantissima anche per reagire ai fattori esterni all'azienda. Cambiano spesso le esigenze di mercato, le condizioni economiche e le dinamiche sociali. Le aziende – e con esse i loro software – devono essere in grado di seguire questi cambiamenti.
Adottare Scrum per sviluppare software su misura non è sempre scontato: non è solo l'azienda fornitrice a dover adottare il framework ma è lo stesso cliente che deve entrare in quest'ottica.
Molte imprese si spaventano poiché il principio della flessibilità si riflette anche sulla pianificazione del budget: l'idea di un budget flessibile spaventa.
L'incertezza del budget, però, è prevista in Scrum per motivi ben precisi, e va vista come un valore aggiunto nel rapporto con il fornitore.
Con Scrum, si otterrà sempre un prodotto finito e funzionante, al massimo delle sue potenzialità, in relazione alla spesa sostenuta.
Ecco che anche il concetto di stima del budget si ribalta: con Scrum non vi è mai il rischio di sottostimare un progetto come avviene invece con la progettazione "a cascata".
Le aziende che adottano Scrum credono fortemente nella collaborazione con il cliente, e l'incertezza nella spesa o nella data di rilascio non va vista come scappatoia ma come opportunità per ottenere il meglio. Ed è anche un modo efficace e non aggressivo di favorire la transizione digitale nell'ambiente di lavoro→ nell'ambiente di lavoro.