Il Teatro Agile

J. Favaro and P. Falcone-Fàvaro, “Il Teatro Agile,” in: Computer Programming, CP130, Infomedia S.r.l., Ponsacco, Dicembre 2003, pp. 69-70.

Si guardavano l’un l’altro con sorpresa. Nessuno si aspettava questo nuovo scenario. Era tardi, avevano appena finito di affrontare l’ultima storia. Perché ora? Era solo un test per vedere se sarebbero stati in grado di farcela? Non aveva importanza. In pochi minuti tutta l’esperienza e la preparazione tecnica del team cominciava ad affiorare in superficie. Due membri del team riconobbero i pattern della struttura sottostante nella nuova storia e cominciarono ad elaborare la bozza per una soluzione. Gli altri membri del team afferrarono al volo – avevano lavorato insieme sia in team che in coppia in ogni possibile combinazione – e presto la soluzione emerse, divenendo così patrimonio comune.

E’ una descrizione di un team Extreme Programming (XP) che sta lavorando su un programma di calcolo degli stipendi per un cliente particolarmente esigente? O forse è un team Crystal sotto pressione perché deve consegnare a breve scadenza un nuovo sistema per la gestione Web delle polizze sulla vita? Niente di tutto questo: è un gruppo di improvvisazione teatrale.

In questi ultimi anni gli informatici hanno spesso potuto arricchire il loro bagaglio di conoscenze della loro stessa disciplina attraverso la disamina di altre, partendo dalle discipline più ovviamente vicine, come la manifattura integrata e l’architettura, e giungendo a considerare discipline meno ovvie, come il giardinaggio e la musica (ad esempio, i membri della prestigiosa Atlantic Systems Guild una volta hanno preso lezioni di canto corale per la ricerca di qualche nuova sfumatura nel lavoro in team). In quest’articolo con l’aiuto di una regista teatrale che è anche consulente di comunicazione, esamineremo la relazione tra l’informatica – in particolare i cosidetti “metodi agili” – e il teatro – in particolare di quel settore conosciuto come “improvvisazione teatrale.”

A prima vista, il teatro e lo sviluppo del software potrebbero sembrare molto lontani tra loro come il sole e la luna. Ad ogni modo consideriamo la seguente prospettiva: al cuore dello sviluppo del software c’è l’esplorazione, l’analisi, e la formalizzazione del comportamento. È così è anche in teatro – con la piccola differenza che il teatro se ne occupa da secoli.

Forse più sorprendente è l’affermazione che le tecniche di improvvisazione teatrale possono essere applicate a ciò che, dopo tutto, è normalmente associato alla rigida precisione tipica di una disciplina ingegneristica. Tuttavia si sta cominciando a ammettere che la programmazione è un’attività molto più sociale di quanto precedentemente riconosciuto (anche se qualche libro pionieristico già sosteneva questo da anni) [1] [2]. Stiamo inoltre comprendendo che, invece di essere un’attività lineare e metodica, lo sviluppo del moderno software normalmente implica una reazione e un continuo adattamento a condizioni esse stesse soggette a continue mutazioni.

Prima di cominciare, dissipiamo un comune equivoco circa la natura dell’improvvisazione teatrale. La maggior parte di noi ha familiarità con un tipo di improvvisazione teatrale che potremmo definire “online.” Ci riferiamo all’intrattenimento nel quale un attore (Roberto Benigni e Dario Fo ne sono un esempio) o un gruppo di attori chiede al pubblico idee o temi e successivamente procede ad elaborarli in uno scenario, normalmente umoristico. Come abbiamo visto all’inizio, è evidente un’immediata analogia con un team di programmatori agili, che devono affrontare requisiti in continuo cambiamento. Ma c’è un’altro uso, ancora più importante, dell’improvvisazione: come strumento di studio che potremmo definire “offline.” In quest’ultimo caso l’attore usa l’improvvisazione come uno strumento tecnico, per la ricerca di tutte quelle qualità sottili del personaggio, senza essere forviato dal testo teatrale e dalla sua struttura fissa e statica. Lavorando in questo modo dall’esterno verso l’interno, l’attore è in grado di portar fuori ciò che ha trovato in se – esattamente come la statua che Michelangelo riteneva di scoprire all’interno dello stesso blocco di marmo che stava lavorando. L’approccio tecnico dell’attore è quello di rompere la realtà in tante componenti, studiarne le singole parti e successivamente ricomporre il tutto senza cuciture apparenti. È a questo punto che possiamo cominciare a trarre qualche conclusione per lo sviluppo del software.

Sviluppiamo un esempio concreto, con un attore che sta esplorando un particolare personaggio. Nel teatro – come nello sviluppo del software – lavorare avendo dei precisi vincoli può essere una fonte preziosa di nuove percezioni. Ad esempio, introduciamo questo vincolo: il personaggio è un balbuziente (vincolo sia psicologico che fisico). Esplorare il disagio, lo sconforto del balbuziente è un modo per arrivare alla sua essenza – al “come” e al “perché” del personaggio.

Va notato che l’attore attraverso questa tecnica lavora fuori dal contesto di qualsiasi specifica situazione teatrale. Lavorare fuori contesto è una tecnica importante per scoprire e capire aspetti che normalmente non sarebbero presi in considerazione. Ciò rende l’attore consapevole delle scelte che può operare. Egli ha il controllo della situazione, e ciò lo rende padrone di essa, e non il contrario. A questo punto la sorpresa: l’attore cestina tutto. Sì, proprio così: egli scarta tutta l’improvvisazione. Questo significa che se la ricerca fosse rimasta in superficie, egli sarebbe giunto solo ad una imitazione del suono delle parole dette da un balbuziente. Invece la comprensione che ha acquisito sul dolore e sullo sconforto del balbuziente rimane dentro di lui ed egli la può usare in un contesto completamente diverso, come, ad esempio, in un testo fisso quale Il giardino dei ciliegi di Cechov – dove il suo personaggio potrebbe non essere affatto balbuziente, ma avere del balbuziente il disagio psicologico.

Questo è lo scopo degli spikes in Extreme Programming: indagini intense e focalizzate su problemi tecnici di natura particolarmente complessa o sottile, fuori dal normale contesto del progetto. Distaccandosi dal contesto normale, il programmatore è libero di approfondire la sua conoscenza sulla vera natura del problema. Dopo di che potrebbe cestinare tutto il lavoro esplorativo che ha appena fatto, ma le percezioni acquistate rimangono dentro di lui, e possono essere reintrodotte nel progetto. Questo distingue i metodi agili da quelli tradizionali, che generalmente non gradiscono digressioni dal piano fisso.

Tornando al teatro, consideriamo ora invece di uno, due attori. L’analogia più immediata potrebbe essere la pratica XP di pair programming (cioè programmazione in coppia) – e sicuramente quest’analogia è valida – ma l’analogia più importante è l’esplorazione congiunta di una nuova situazione in un progetto. Per esempio, supponiamo che un cameriere ora entri in scena. Il compito degli attori è scoprire che relazione c’è tra i due personaggi, quali conflitti possono sorgere, e quali soluzioni possono essere sviluppate.

A questo punto la composizione di un conflitto diventa importante. Per esempio, il comportamento che il cameriere può avere verso il cliente balbuziente determinerà la reazione di quest’ultimo. Se il cameriere è insofferente e come conseguenza il cliente balbuziente diventa sempre più balbuziente, questo potrebbe portare ad una soluzione solo negativa (es. il cliente decide di andarsene). Per questo, il cameriere dovrà scoprire cos’è necessario fare per mettere il cliente a suo agio e giungere così ad una soluzione positiva.

Potrebbe succedere che la situazione fino a quel punto esistente smetta di funzionare, perché il nuovo personaggio non può essere incluso nello scenario esistente. In una improvvisazione teatrale, questo accade quasi sempre quando non si riesce più a creare un dialogo. Quando cioè ogni personaggio finisce col fare solo un monologo. C’è solo un modo per fare emergere un dialogo: in ogni momento, c’è chi guida e chi segue, e questo può succedere, anzi deve succedere in alternanza. Più gli attori sono in sintonia, più ognuno può capire intuitivamente quando guidare e quando passare la battuta all’altro. Questo va contro la comune nozione che un grande attore deve essere sempre al centro dell’attenzione. Al contrario: più grande è l’attore, meno paura ha di fare la spalla – perché egli riconosce che anche questo può essere fonte di energia creativa. La comunicazione e il feedback tra gli attori è costantemente alimentata dall’alternanza del ruolo di leader.

Se dovesse sorgere un’impasse, cosa possono fare gli attori per romperla? Anche un violento confronto fra i personaggi – mai auspicabile ma sempre possibile – potrebbe aprire la via ad un dialogo. Un’altra soluzione è rappresentata dal fare un passo in dietro e riconsiderare l’intero scenario fino a quel momento, e introdurre nuove variabili che permettano una soluzione – per esempio, il cameriere si scopre e si rivela un vecchio amico di scuola. Infine, se nessuna soluzione dovesse essere possibile, gli attori devono trovare il coraggio di cestinare tutti i presupposti e ricominciare, con nuovi tratti dei personaggi, e se necessario perfino fare tabula rasa e considerare nuovi personaggi.

I metodi agili per lo sviluppo del software sono tra i pochi che rifiutano la nozione della composizione gerarchica di un team (per esempio, il ruolo comune di chief architect non esiste). I valori essenziali di comunicazione e feedback sono promossi allo scopo di creare un continuo dialogo tra i membri del team (sia dentro che fuori delle situazioni di pair programming), senza un leader fisso del team. Il continuo dialogo crea un’ambiente ideale per un robusto adattamento ad una situazione fluttuante. Ed il valore essenziale del coraggio è promosso allo scopo di rendere capace il team di prendere la difficile decisione di cestinare tutti i presupposti considerati fino a quel momento e ricominciare daccapo – un’altra cosa che può accadere quando i requisiti cambiano continuamente. Anche in questo caso, i metodi agili si distinguono da quelli tradizionali per la loro esplicita introduzione del concetto di cestinare come un metodo alternativo e valido per arrivare ad una soluzione positiva, e pertanto totalmente diverso dalla soluzione negativa di abbandonare.

Consideriamo un nuovo team di attori ed un nuovo scenario: tutti gli uomini devono andare in guerra. Ma supponiamo che questo team sia solo maschile (una situazione che si verifica fin troppo frequentemente tra gli informatici). Cosa comporta ciò? I personaggi femminili, che forniscono un importante componente di tensione in questo scenario, mancano. Come può essere risolta questa situazione? Una regola fondamentale nell’improvvisazione teatrale è la semplicità – cioè la ricerca della soluzione più elementare possibile, usando tutti i mezzi a disposizione. Non ci sono donne, ma gli uomini, ad esempio, possono ricevere una telefonata dalle donne. In questo modo si crea il necessario dialogo uomo-donna. Questa tecnica che si usa per la creazione dei ruoli mancanti è un “pattern teatrale,” conosciuto da qualsiasi attore tecnicamente ben preparato. Come loro controparti nel disegno object-oriented, questi pattern teatrali sono solo applicabile in un contesto appropriato. Per esempio, se la scena si svolgesse nel sedicesimo secolo ovviamente la telefonata sarebbe difficilmente possibile.

In quest’ultimo caso, il team deve scavare ancora più profondamente per arrivare ad una soluzione. I componenti del team potrebbero ad esempio scoprire che la metafora essenziale dello scenario non è tanto “uomini e donne” ma piuttosto “chi parte e chi resta.” Dalla relazione fra questi ultimi ruoli nasce così quel cruciale dialogo. Ogni singolo attore dovrà per prima cosa usare tutti i mezzi a sua disposizione per capire il suo ruolo, cioè a quale dei due gruppi appartiene (ad esempio un attore più vecchio capirà di essere fra quelli che rimangono). Successivamente l’attore sarà in grado di contribuire al dialogo da cui emerge il significato della guerra (ad esempio un padre ed un figlio dovranno risolvere un vecchio conflitto prima della partenza del figlio).

La scoperta della metafora essenziale di un sistema (ad esempio “una scrivania”) è un concetto centrale nei metodi agili. Esso è necessario per supportare il concetto del comportamento emergente del sistema – cioè l’essenza del sistema nasce dal continuo dialogo dei membri del team.

Comunicazione, feedback, semplicità, coraggio, metafora – il teatro ha utilizzato questi concetti da secoli per creare alcuni dei capolavori più grandi dell’Uomo. Le ambizioni dei programmatori sono forse un po’ più modeste, ma il loro bisogno di capire ed implementare questi concetti è ugualmente grande. Che l’una disciplina impari dall’altra!

[1] Gerald M. Weinberg, The Psychology of Computer Programming, Dorset House, 1971

[2] DeMarco, Tom and Timothy Lister, Peopleware, 2nd edition, Dorset House, 1999