Il metodo BitBoss e lo sviluppo software a ciclo continuo

Nel suo libro più celebre, l'inventore del metodo Scrum Jeff Sutherland racconta di come nel 2010, al tempo in cui Facebook, Amazon e Google stavano scrivendo la loro storia, l'Agenzia Governativa di Polizia Federale degli Stati Uniti d’America (FBI) raccoglieva ancora la maggior parte dei suoi rapporti sulla carta, rinchiudendo gli agenti federali in freddi scantinati illuminati al neon e ricolmi di scaffali. L'Agenzia Governativa più famosa del mondo, per coordinarsi e arrestare i terroristi, utilizzava una tecnologia che era ferma agli anni ’80, ma nel 2010.

Racconta Jeff Sutherland che all’epoca, quando un agente dell’FBI voleva cimentarsi in qualche attività, che si trattasse di pagare un informatore, inseguire un terrorista o di archiviare una pratica, il processo era sempre lo stesso. L’agente doveva scrivere un documento al pc e stamparlo in tre copie. Una copia sarebbe finita nella catena di approvazione attraverso i vari reparti, un'altra sarebbe stata archiviata localmente e con la terza copia l'agente avrebbe dovuto prendere una penna rossa e cerchiare le parole chiave da inserire nel database, al fine di indicizzare i rapporti. Se una richiesta di indagine veniva approvata, la copia di carta veniva rispedita ai piani alti che applicavano su di essa un numero stampato e veniva rimandata in archivio. Quello era il modo in cui l’FBI teneva traccia di tutti i suoi casi. 

Per di più, continua Jeff, ogni ufficio agiva per compartimenti stagni prendendo le proprie decisioni in autonomia e senza coinvolgere gli altri livelli decisionali. Questo faceva sì che, come a suo dire avvenne per l’attentato dell’11 settembre, capitava che nello stesso momento un ufficio seguisse i movimenti di un sospettato, un altro si domandasse come mai in quel periodo tanti stranieri sospetti stessero prendendo lezioni di volo e un altro ancora avesse qualcuno su una lista di osservazione, ma non c’era speranza che qualcuno riuscisse a mettere insieme queste informazioni.
Perché un’organizzazione così ben strutturata e piena di menti brillanti come l’FBI soffriva queste problematiche? 

Il problema, dice l'autore, non era l’incapacità delle persone o la mancanza di risorse, ma la totale mancanza di organizzazione e condivisione delle informazioni. La causa risiedeva nel metodo di lavoro sbagliato che veniva utilizzato. Tutti percepivano il problema, ma continuavano ad utilizzare quel metodo perché era ciò che era stato insegnato e che veniva loro imposto da 30 anni dai livelli più alti della catena. Il mondo era cambiato e non se n’erano accorti, persino i terroristi l’avevano capito prima di loro.

Quel sistema in teoria sembrava funzionare: un gruppo di decisori si sedeva al tavolo e cominciava a pensare a come costruire un sistema che funzionasse, dopodiché  si sceglievano un certo numero di persone capaci e qualificate per progettare il sistema e poi si sceglievano altre persone per crearlo esattamente com'era stato pensato.

Il problema era che in questo modo l’informazione si perdeva lungo la strada. Si creava una catena decisionale che non prevedeva un collegamento tra il primo anello, dove venivano prese le decisioni e l’ultimo dove si metteva in pratica il lavoro. Ogni ufficio ragionava per compartimenti stagni e le informazioni difficilmente sarebbero risalite lungo la catena. La parte alta finiva per non essere mai informata su quanto stesse succedendo all’interno dell'area esecutiva.

Il metodo a cascata nello sviluppo di software

In ambito software si vengono spesso a riscontrare problemi molto simili a quelli incontrati a suo tempo dall’FBI. Molto spesso non si riesce a prevedere il cambio di direzione che sta prendendo il progetto e ci si trova a rimanere indietro rispetto alle richieste del cliente. In altri casi non ci si accorge del cambio repentino degli input che arrivano dall’ambiente esterno perché si è troppo concentrati a seguire un rigido piano stilato a priori all'inizio del progetto. 

Un esempio emblematico e più vicino a noi di questa incapacità di accorgersi dei cambiamenti esterni e improvvisi è il caso del data leak che ha colpito il sito dell’INPS avvenuto in tempi di lockdown di cui tutti siamo ormai informati. Anche se tutto si è tradotto in un malfunzionamento tecnico, l’errore si è probabilmente generato a monte, all’interno dell’area organizzativa che non ha saputo affrontare il picco di accessi al portale che ha dato origine alla rottura del sistema. 

Perché esiste quest’incapacità di prevedere i cambiamenti che arrivano dall’esterno? Cos'hanno in comune i problemi che affliggevano l’organizzazione dell’FBI nel 2010 e quelli che si sono presentati all’INPS, in Italia, in tempi più recenti? E più in generale cosa li accomuna allo sviluppo software? 

Il problema risiede nella struttura organizzativa delle aziende e dei progetti. Spesso le organizzazioni sono fatte in modo che chi detiene il potere decisionale, trasferisca le istruzioni a chi sta più in basso con un flusso a cascata. Si viene così a formare una situazione in cui alcune persone hanno il compito di immaginare e pianificare che cosa andrebbe fatto e altre invece che hanno il compito di mettere in pratica ciò che è stato in precedenza pensato. Questo flusso è a senso unico e impedisce lo scambio di informazioni, che si muovono inevitabilmente sempre verso il basso. Non risalgono quasi mai. I piani più alti della catena non riescono quindi ad entrare in possesso delle informazioni che potrebbero essere cruciali nel momento in cui vengono prese le decisioni.

Nell’ambito dello sviluppo software questa cascata è resa anche più complessa dalla presenza di più aree tecniche che devono comunicare e coordinarsi tra di loro: il team di design deve comunicare con il team di sviluppo ed entrambe dovranno comunicare con chi gestisce il progetto e che ha a che fare con il cliente.

Va da sé che in questa situazione i team di lavoro sono raggruppati anche in base ai loro ruoli di competenza. Un team lavorerà su una fase del progetto e poi passerà la palla a un altro nel momento in cui la sua parte sarà completata e tra di loro non ci sarà più alcuno scambio.

Sviluppo software a ciclo continuo

Prendendo ispirazione dal mondo agile e in particolare dal metodo Scrum è possibile trasformare la cascata e darle la forma di un cerchio. Viene così a formarsi un ciclo di sviluppo che interessa tutte le aree coinvolte nella realizzazione del software. In questo modo l’intera struttura viene appiattita e l'area decisionale è portata allo stesso livello di quella esecutiva. La distanza tra i diversi attori coinvolti si riduce notevolmente favorendo il flusso di informazioni.
Questo tipo di processo viene chiamato sviluppo a ciclo continuo o sviluppo iterativo e suddivide l’intero progetto in cicli di lavoro brevi che in Scrum vengono chiamati sprint e che qui assumono una struttura circolare. Ogni ciclo rappresenta quindi uno sprint, che solitamente ha la durata di 2-3 settimane. All’inizio del ciclo si decide cosa si può sviluppare in quell’arco di tempo, dopodiché si informano le altre aree, che passano gli input agli attori successivi fino a tornare alla base.

Alla fine del periodo si ricomincia il ciclo di sviluppo successivo con un’esperienza nuova, sapendo quali sono le difficoltà che si sono affrontate in precedenza. In un progetto di sviluppo software però entra in gioco un attore in più, che è il motore che dà il via a tutto il processo. Questo attore è il cliente ed è colui dal quale parte l’input iniziale che dà il via a tutto il processo e che deve necessariamente essere strettamente connesso con tutti gli altri attori all’interno del cerchio.

La struttura a ciclo continuo fa sì che tutti coloro che sono presenti in ogni area del cerchio siano costantemente messi al corrente delle difficoltà che ci sono state e che ci saranno nell’intero processo ed è possibile applicare questo modello ad ogni ciclo di sviluppo.

Un fattore fondamentale sta nel fatto che il percorso comunicativo non è a senso unico, ma tutte le aree e tutti gli attori devono comunicare ed essere coinvolti in egual misura. Questo fa sì che nessuna area possa essere isolata o prevaricare eccessivamente sulle altre:

• Se la progettazione avesse un ruolo predominante sulla parte operativa, tutto il lavoro diventerebbe troppo astratto e mancherebbe l'aspetto pratico. Tuttavia in uno scenario contrario il progetto risulterebbe funzionale nel breve termine ma perderebbe la capacità di sopportare le evoluzioni future.

• Se l'area design prevaricasse sull'area di sviluppo, nel breve termine il progetto potrebbe funzionare, ma si ignorerebbero molte delle difficoltà che gli sviluppatori incontreranno nel lungo periodo e il progetto non sarebbe sostenibile.

• Se l'area di sviluppo prevaricasse sull'area che si occupa dell'architettura, non si sarebbe in grado di scalare e di affrontare eventuali picchi di richieste.

Comunicazione con il cliente

Il cliente, colui che utilizzerà il prodotto finale, è l’attore principale di tutto il processo. Da lui arrivano gli input che danno azione a tutto il ciclo di sviluppo, ma anche i feedback che riguardano il lavoro svolto fino a quel momento. In base a quanto è avvenuto nel ciclo precedente si può determinare cosa ha funzionato e cosa invece si può migliorare nello sprint successivo.

Attraverso i feedback continui che arrivano dal cliente quindi, si decide cosa si può sviluppare nell'arco di tempo successivo, sapendo le difficoltà che si sono affrontate in quello precedente. I feedback devono però essere analizzati e deve esserne valutata la fattibilità delle richieste del cliente per il prossimo ciclo di sviluppo.

Chi ha il compito di dialogare con il cliente deve essere in grado di tradurre i feedback in azione e comunicare a chi viene dopo gli input per iniziare lo sviluppo del software.

Design

Quest’area si occupa della parte visual del software, ovvero dell'interfaccia grafica che gli utenti finali vedranno e attraverso la quale interagiranno con il software. A sua volta si suddivide un due reparti che lavorano a stretto contatto tra loro: la progettazione e lo sviluppo visivo.

Il primo recepisce tutti gli input e li trasforma in un’idea di interfaccia per capire in che modo il cliente dovrà comunicare con il software. Si tratta di decidere quale sarà l’impatto grafico del software e di progettare l’esperienza che l’utente avrà sulla piattaforma. Il secondo reparto è quello di sviluppo grafico che prende le idee e le trasforma in grafiche, mockup e schermate.

Sviluppo

La terza area rappresenta il cuore di tutto il processo, ovvero lo sviluppo del software e delle funzionalità descritte dai mockup, basandosi sulle scelte tecniche discusse in precedenza.

Anche quest’area a sua volta si suddivide in due reparti che lavorano a stretto contatto. Il primo è quello di progettazione che deve decidere a livello teorico cosa il software dovrà fare e deve descrivere dettagliatamente le caratteristiche che dovrà avere il sistema per poi passare la palla a chi si occupa dello sviluppo pratico, dove si va a implementare effettivamente il software.

Architettura

La progettazione dell'architettura si rivolge alle macchine, ai server e al tipo di architettura e di struttura su cui il software si deve poggiare. La progettazione anche in questo caso è teorica e deve dare l’input alla parte di sviluppo architetturale che comprende tutte le attività di messa in piedi delle macchine su cui dovrà poggiare l’intera struttura.

In sintesi

Lo sviluppo a ciclo continuo, che noi abbiamo integrato all’interno di quello che definiamo Metodo BitBoss, permette quindi ad ogni area coinvolta nel progetto di essere soggetta ad un lungo ciclo di feedback che interessa tutti coloro che ne fanno parte. In questo modo le informazioni circolano liberamente e tutti gli attori sono ugualmente coinvolte nel processo. Non solo tutti gli attori hanno libertà decisionale, ma le decisioni prese sono subito recepite dagli altri tramite il ciclo di feedback continuo. 

Il motivo dello stravolgimento del metodo a cascata per lo sviluppo dei software in virtù di un sistema a cerchio è volto a favorire la comunicazione e a capire le difficoltà che potrebbero sorgere prima che queste si verifichino.

Per questo la direzione del flusso di informazioni nel ciclo continuo non è a senso unico, ma i feedback si spostano in continuazione tra le parti, fino a tornare al cliente, che avrà il compito di dare il via al ciclo successivo, fino al completamento dell’intero progetto.