I metodi "leggeri" servono?

Via twitter ho scritto:

Adottare una metodologia di sviluppo software leggera [i.e. "agile"] non serve.

1) Se le persone sono competenti ed oneste, non hanno bisogno di adottare alcun metodo [esterno], perché un metodo già ce l’avranno e sapranno usarlo in sintesi tra di loro.

2)Se le persone sono incompetenti o disoneste, nessuna metodologia leggera può essere di aiuto. Infatti: 

se sono incompetenti, allora è ovvio

se sono disoneste, allora può aiutare solo un metodo pesante, un Leviatano, ovvero un metodo tipo Waterfall.

Ora elaboro questa tesi.

Ho usato due termini: “competente” e “onesto".

Nella mia accezione “essere competente” vuol dire non solo “saper fare” ma anche conoscere i propri limiti.

I programmatori sapranno (singolarmente) realizzare, con gli strumenti che conoscono, delle soluzioni software in grado di eseguire uno o più compiti che vengono comunicati in modo chiaro dai richiedenti. Sanno anche cosa manca alle loro conoscenze, e quanto ci vorrà per acquisirle.

Coloro che commissionano un lavoro di programmazione sono competenti se: 

1. conoscono il problema che vogliono risolvere, 
2. conoscono il dominio (o ambito) del problema stesso, 
3. sono in grado di spiegarlo in modo chiaro.
4. conoscono i propri limiti in relazione a punti precedenti, e non lo nascondono (spesso certe cose si devono necessariamente scoprire nel corso del tempo).

Ora cerco di argomentare la prima delle due tesi.

Punto 1. Se le persone sono competenti ed oneste, non hanno praticamente alcun bisogno di adottare un metodo esterno. A loro basta adottare un metodo che sia la sintesi di quelli che già avrebbero adottato come singoli.

Per ipotesi i committenti conoscono in buona parte il compito per il quale richiedono una soluzione, e sanno comunicarlo in modo chiaro. Evitano quindi di scrivere cose fumose e polverose. Se invece lo fanno, con vaghezze o ambiguità nella comunicazione, forse la cosa indica un qualche interesse a farlo, per esempio per nascondere delle proprie eventuali lacune nella conoscenza del problema (cosa che è contro l’ipotesi).

Quanto detto sopra suggerisce che esiste la possibilità di adottare una buona comunicazione, a prescindere dal linguaggio o dai formalismi. Un modo di definire la buona comunicazione in effetti esiste, ed è principio cooperativo di Paul Grice, che consiste nelle seguenti regole: Qualità, Quantità, Rilevanza, Maniera.

La regola di quantità raccomanda il giusto equilibrio tra il non dire troppo e il non dire troppo poco.

La regola di qualità raccomanda di non dire ciò che sai essere falso né ciò per cui non hai sufficienti prove per assumere che sia vero.

La regola di rilevanza raccomanda di dire cose pertinenti all’argomento e al contesto.

La regola di maniera raccomanda di evitare espressioni oscure o ambigue, e raccomanda piuttosto di essere succinti e di rispettare un opportuno ordine (sequenza).

Dunque i committenti possono comunicare bene quello che sanno, perché esistono i principi del comunicare bene.

Oltre a saper comunicare il cosa, è utile saper comunicare il perché, lo scopo, secondo il principio sistemico per cui “per decidere in modo appropriato il come [fare una cosa], bisogna conoscere anche il perché [cioè lo scopo], oltre al cosa”.

Per ipotesi, i programmatori del gruppo sono persone che singolarmente sono competenti ed oneste. In generale questa condizione è necessaria affinché l’intero gruppo nel suo complesso possa essere considerato “competente” ed “onesto”,  ma, pur essendo necessaria, in effetti non è una condizione sufficiente. Commetterei una fallacia di composizione se dicessi che è anche una condizione sufficiente. "Fallacia di composizione" significa sostenere che “quando qualcosa vale per le parti di un insieme, allora vale anche per tutto l’insieme” (il che è falso, e quindi fallace).

Provo a tentare di superare la fallacia di composizione in modo semplice.

Accenno alle singole tecniche comunemente usate, ed al fatto che esse stesse in effetti sono già predisposte per il lavoro di gruppo. Cioè possono “scalare”. Alcuni esempi:

• Gestione del codice sorgente. Un po’ tutti i programmatori bravi usano sistemi di controllo di versione, come bitbucket, gitlab, o github per i loro progetti, che si tratti di toy project, che si tratti di progetti professionali, open source o meno. Questi sistemi li usano proficuamente gruppi anche distribuiti geograficamente, e ci sono tanti progetti, soprattutto open source, che lo confermano. Tecnicamente ci potranno essere dei conflitti di codice durante gli allineamenti/aggiornamenti, ma sapendo programmare “bene” è sempre più difficile che ciò accada. Infatti il più delle volte, nell’aggiungere una funzionalità, possiamo evitare di introdurre side effect che coinvolgano altre funzionalità, o comunque possiamo essere in grado di rilevare e correggere un eventuale errore per tempo (considerano anche normali periodi di beta testing). Ci saranno sempre difficoltà e conflittualità, ma il punto è che queste difficoltà e conflittualità devono essere produttive ed orientate alla soluzione (e tra persone collaborative si dovrebbe poter fare). 
• Gestione dei requisiti. Se personalmente i singoli programmatori sono abituati ad usare un documento per tenere traccia delle cose da fare, scritto in linguaggio chiaro (tornando al principio cooperativo conversazionale), allora questo stesso documento lo potranno anche condividere in rete con tutti i compagni del gruppo, aperto in lettura, in scrittura, per aggiunta di commenti, eccetera. Bisogna solo decidere un minimo di standard comune, (poco male se poi questo standard rifletterà certi formati suggeriti dai metodi "leggeri": non c’è copyright sul buon senso).
• Gestione dell’ambiente di “deploy”/“esecuzione”. I cosiddetti container consentono una configurazione di esecuzione identica per tutti, sui propri laptop/desktop di lavoro, indipendentemente dal tipo o dalla specifica configurazione di questi. Nessuno potrà dire che "funzionava sulla mia macchina".

Magari ci vorrà una qualche sintesi tra queste pratiche se ognuno le usa in modo un po’ diverso, ma se si è onesti, si deve poter arrivare ad una sintesi senza conflitti infantili. 

In sintesi, nell’ipotesi fatta dovremmo avere relativamente pochi problemi organizzativi e di comunicazione, e come metodo ci basta una sintesi dei metodi che si presume dovremmo già sapere usare singolarmente.

Quindi la tesi del punto 1 mi sembra abbastanza sostenibile: non ci serve che ci venga instillato un metodo esterno.

Allora possiamo decidere di cercare di trovarci sempre nel punto 1, oppure dobbiamo dare quel minimo di supporto per creare le condizioni affinché valga il punto 1 (visto che l’ambiente e le motivazioni contano), e non andare oltre, ovvero non istituire un metodo "esterno" solo perché lo abbiamo letto da qualche parte, o visto in qualche conferenza.

Comunque, per pura ipotesi, supponiamo invece che il gruppo sia fatto di persone “disoneste” o “incompetenti”, in maniera praticamente incorreggibile. Allora il metodo non ci aiuta  più di tanto. Ci potrebbe aiutare solo un metodo pesante, prescrittivo, stile waterfall.

Non indago sull’ipotesi per cui “siamo incompetenti”, perché è un caso tutto abbastanza scontato. Non possiamo fare una certa cosa perché non ne abbiamo appunto le competenze, e questo è quanto.

Se invece siamo competenti ma comunque disonesti, allora un metodo può esistere, ma non sarà certo un metodo di tipo leggero.

Se siamo “disonesti”, allora siamo in perenne stato di guerra contro gli altri, in particolare con i compagni di gruppo, magari a causa dei propri anche legittimi interessi personali, per egoismo, egocentrismo e così via.

Thomas Hobbes sosteneva appunto che gli umani, nel loro stato di natura, sono in “guerra” tra loro. Sosteneva che quindi le persone si sarebbero dovute dare un “patto”, un “contratto sociale”, un “Leviatano” come la soluzione. Il “Leviatano”, cioè lo Stato, sarebbe servito a proteggere le persone le une dalle altre. Se adottiamo questa descrizione come metafora per un gruppo di lavoro che deve portare a termine un progetto, allora il “patto”/“contratto sociale”/“Leviatano” sarà appunto il metodo che si danno per lavorare. Allora non credo che il metodo adeguato possa essere di tipo leggero, perché questo non protegge affatto le persone le une dalle altre, quanto piuttosto le mette letteralmente le une contro le altre, anche nel del modo di gestire lo spazio fisico!

Introdurre un metodo leggero può portare a situazioni addirittura parossistiche: per ipotesi, siamo in guerra l’uno con l’altro, eccetera eccetera, ma durante le cosiddette retrospettive dobbiamo invece cambiare mentalità, in modo netto e radicale. Per esempio, magari la settimana scorsa ci azzuffavamo perché non riuscivamo ad accordarci su qualche scelta tecnica o di altro tipo (per motivi forse egoistici o strumentali, il che è concorde con l’ipotesi data). Poi alla fine di tutti  questi parapiglia, arriva la retrospettiva e tutti dobbiamo assumere un paradigma completamente diverso, e conformarci all’assunzione che “ognuno ha fatto sicuramente del suo meglio”. Ma questa cosa non può funzionare se non la pensi per davvero.

E’ un “Comma 22”: devi chiedere feedback o cercare aiuto se serve, ma non ti conviene farlo, visto che così fornisci un pretesto ai tuoi nemici perché ti possano colpire.

Preciso che il fatto di dover chiedere feedback, “aiuto” e quant’altro non è contraddizione con il fatto di essere competenti perché essere competenti non significa essere incapaci di sbagliare. Essere competente prevede anche il fare errori, purché il sistema ci consenta di rilevarli e risolverli il prima possibile, e per rilevarli e risolverli serve in effetti anche l’apporto dei compagni di gruppo. Ci sono in effetti principi di certi metodi, per esempio stile Lean-Toyota, che forniscono un aiuto. Parlo del Poka  Yoke, che descrive una cosa di questo tipo appena descritto. Quindi è opportuno confrontarsi e anche usare delle tecniche come questa, ma per farlo non bastano, né sono strettamente necessari, metodi e cerimonie, benché i singoli principi e pratiche possono essere utili purché ci sia innanzitutto l’attitudine che descrivevo.

Naturalmente ci sono anche altre ipotesi sulla nostra natura che sono meno estreme.

Per esempio può essere che non si dà il caso che siamo in uno “stato di guerra” con tutti, ma magari possiamo simpatizzare almeno per le persone più vicine a noi. In fondo si tratta un po’ del concetto di famiglia, di amicizia… . Nel nostro codice genetico è previsto che avremo simpatia, empatia, compassione, solidarietà nei confronti di qualcuno. Tra l’altro, diranno i metodologisti (dei metodi leggeri), è per questo mettiamo il gruppo di lavoro tutto insieme nello stesso posto: così si crea una sorta di cameratismo. Ma non è così scontato che questa vicinanza, simpatia eccetera debba avvenire per i compagni del gruppo di lavoro solo perché ci hanno messi gli uni vicino agli altri. Le persone che ci sono realmente amiche sono quelle con cui usciamo insieme, mangiamo insieme, magari ci abitiamo insieme. I nostri compagni di lavoro in fondo non sono necessariamente tutto questo.

Essi potrebbero seguire una propria agenda o strategia non proprio benevola nei nostri confronti. Dunque metterci a lavorare insieme gomito a gomito in questo contesto potrebbe essere proprio una pessima idea.

Quindi in generale sembra davvero più opportuno che per proteggere noi e di conseguenza il sistema, questo sistema debba regalarci delle confort zone, anziché togliercele. Dovrebbe consentirci di aver già tutte le informazioni che servono per fare quello che dobbiamo fare.

Serve cioè qualcosa che ti dica “se segui la procedura tutto andrà bene”. Sarà un po’ alienante, ma è pur sempre meglio di una situazione che rischia di essere caotica e schizofrenica per le sue contraddizioni.

Il caso analizzato fino a questo (ipotesi 2) punto partiva dall’ipotesi che il nostro modello di comportamento è egoistico, e che siamo in perenne conflitto tra noi, eccetera eccetera.

La conclusione è che il patto, il “contratto sociale” che protegge noi da tutto noi non può essere un metodo leggero.

Se invece vale l’ipotesi 1 per cui siamo “onesti” (o quanto meno abbiamo buone possibilità di diventarlo) allora l’adozione di un metodo esterno, che sia leggero o meno è quasi superflua (anche se non è irrilevante: alcune pratiche sono in effetti utili, come in relazione alla risoluzione dei problemi per esempio con metodo A3, alla formulazione di checklist, eccetera). Ci fidiamo già gli uni degli altri, non abbiamo bisogno di farci aiutare a “creare un clima di fiducia” perché questo clima c’è già. Conosciamo già le tecniche per scrivere codice che funziona e per manutenerlo. Siamo già convinti, e non dobbiamo “doverlo credere (?)” che i nostri compagni siano meritori e facciano sempre del loro meglio, anche quando sbagliano.

Ma quale delle due ipotesi dovremmo pensare che sia la più verosimile in un caso generale?

Personalmente condivido l’idea che in un certo senso siamo in uno stato conflittuale per la nostra natura, per diversi motivi, per esempio per effetto di alcune irrazionalità connaturate in noi, o per come potrebbe essere modellato un certo tipo di sistema in cui operiamo. Queste irrazionalità però sono a volte presentate in modo esagerato.

Un esperimento mentale per spiegare questo concetto: come programmatore mi può capitare, con il senno di poi, di valutare negativamente una mia scelta tecnica (aver introdotto un design inutilmente complicato, usare troppi parametri a volte inutili, e così via). Nonostante ciò, mi autoassolvo perché “in quel contesto lì per le informazioni che avevo ero giustificato a fare quella scelta”. 

Tuttavia se la mi valutazione avesse riguardato qualche scelta simile fatta da altri, magari sarei stato molto più severo. Questo ipotetico mio comportamento sarebbe da considerare senz’altro ipocrita. Tuttavia qualcuno mi dirà che invece è comprensibile, perché causato da un bias cognitivo, nel caso specifico l’“actor-observer asymmetry bias". Io invece penso questa storia dei bias cognitivi sia troppo comoda da raccontare. Siamo soggetti a bias cognitivi solo se facciamo lavorare troppo i nostri pensieri rapidi, impulsivi, e troppo poco quelli lenti, ponderati. Cerchiamo l'interpretazione più negativa possibile, anziché quella più benevola possibile (che è il Principio di Carità). Quindi se il mio giudizio ingiusto era dovuto ad un bias cognitivo, la causa sarà stata anche la mia pigrizia, la mia impulsività.

Dunque anche se certi nostri tratti bellicosi sono ancestrali, atavici, connaturati, fisiologici e quant’altro, penso comunque che spesso siano superabili sforzandoci un po’ con l’intelletto.

E’ comunque chiaro che nel tradimento rispetto agli interessi comuni certe volte l’irrazionalità non c’entra. Ovvero il tradire risulta essere normale anche per un agente perfettamente razionale. Lo vediamo nel modello di gioco del dilemma del prigioniero. In questo modello è effettivamente razionale tradire. Ma non dobbiamo per forza giocare a quel tipo di gioco, cioè il sistema potrebbe essere anche diverso ed adeguarsi ad un altro tipo modello. Per esempio un sistema potrebbe seguire anche il modello della versione iterata del dilemma stesso, dove il tradimento non è più una scelta razionale vincente. Infatti nella versione iterata le strategie cooperative, anche se non ingenue, sono più competitive, più adatte alla sopravvivenza.

Un sistema in qualche  modo fluido, continuo, iterativo, in effetti è molto più simile alla versione iterata che alla versione a “colpo unico” (“one shot”) del dilemma del prigioniero (è questo è sicuramente un punto, dal lato teorico, positivo dei metodi leggeri).

In definitiva, ci sono casi in cui un metodo collaborativo non può funzionare, per una cospicua presenza di "traditori", "defectors"o "free rider". I cooperatori puri non sopravviverebbero, ed anche i cooperatori non ingenui finirebbero per comportarsi esattamente come i free rider per sopravvivere. In tal caso adottare un metodo che presuppone una attitudine collaborativa è una pessima idea. Rischia di finire come una pantomima, un cargo cult, una pletora di cerimonie stucchevoli.

Se invece siamo già in massima parte cooperatori/collaboratori (non ingenui), allora dovremmo essere in grado di seguire un metodo collaborativo ed anzi potremmo persino darcelo da soli, senza bisogno che ci venga instillato.

nota: per quanto ovvio, il termine "leggero" l'ho usato come sinonimo di "agile". Ho evitato quest'ultimo termine perchè è troppo autopromozionale, sembra positivo solo a pronunciarlo. "leggèro" invece è più neutro.