Responsabilità nello Sviluppo del Software

Accountability in software development è uno degli articoli più interessanti che parlano di etica nella produzione del software. Le parole di Kent Beck rappresentano molto bene anche le mie convinzioni su questa bella professione. Ho pensato che valesse la pena leggere questo lungo e piacevole testo in lingua italiana. Buona lettura.

"Una volta un contadino intervistò un ragazzo per un lavoro come bracciante in fattoria. Il ragazzo disse una cosa che lasciò particolarmente perplesso il contadino: 'io posso dormire quando soffia il vento'. Il contadino non sapeva cosa egli intendesse, ma il ragazzo sembrava competente ed quindi fu assunto.

Qualche mese dopo il contadino venne svegliato nel bel mezzo della notte da una tremenda bufera. Preso dal panico, corse verso la branda dove trovò il bracciante quasi addormentato. Scuotendolo brutalmente per svegliarlo, gli disse:

'Dobbiamo far rientrare gli animali!'.
'Sono già dentro.'

'Dobbiamo chiudere le finestre.'
'Sono già chiuse.'

'Dobbiamo ricoprire il fieno.'
'Già fatto.'

Dopo che i suoi timori fossero calati ed essere stato rassicurato che tutto era al suo posto, il contadino finalmente comprese il senso di quella misteriosa frase. Avendo cura di terminare ogni lavoro e lasciando la fattoria al sicuro ogni notte, il bracciante poteva dormire quando il vento soffiava.

Il contadino tornò a letto e disse alla moglie ciò che aveva appena appreso. Lei sorrise con un aria d'intesa e i due tornarono a dormire, cullati dal suono della burrasca."

Lo sviluppo del software va meglio se lavoro in modo che io possa "dormire quando soffia il vento". Sono più a mio agio con me stesso e il mio lavoro, i miei clienti sono più soddisfatti dai risultati che vedono, e i miei colleghi del team possono fidarsi di me. Comunque trovo difficile raggiungere questo livello di performance con la sola forza di volontà. Mi serve il supporto, l'incoraggiamento, e la responsabilità. Ho bisogno di essere un membro di una comunità per dare il massimo. Un elemento chiave per tutto ciò è la responsabilità: impegnarsi, lavorare in modo che io ne sia orgoglioso e rendere conto sulle mie attività in modo chiaro e diretto.

Quando iniziai a parlare di responsabilità, incontrai molta resistenza da parte dei programmatori che dicevano di odiare l'idea della responsabilità. Raccontavano storie del tipo "...e allora lui mi dice: 'ti considero responsabile per questa proroga sui tempi del progetto". Questo non è ciò di cui sto parlando. Questo è colpevolizzare, un tentativo per evitare o deflettere le conseguenze. Colpevolizzare è uno scarso presupposto a partire dal quale lavorare. Colpevolizzare necessita che tu spenda tempo e energia per proteggere te stesso. In un ambiente di biasimo non è opportuno dire quello che fai e quello che non sai. Colpevolizzare lascia ognuno preoccupato da coloro che sono lì fuori pronti ad incastrarlo. Tutta l'energia che spendono per nascondere potrebbe venir usata per interagire e aggiungere valore al progetto. Il lavoro perde in efficienza. La responsabilità è un potente presupposto a partire dal quale iniziare a lavorare. Lavorando bene e in modo trasparente si creano legami forti. Accettando responsabilità si prepara il terreno alla soddisfazione per un lavoro ben fatto. È un peccato che la parola 'Responsabilità' venga mal interpretata, perché ciò oscura un concetto utile.

La responsabilità può essere offerta, richiesta e persino demandata, ma non può esser forzata. 'Ti ritengo responsabile' non ha senso. 'Sei tu il colpevole' o 'spero che ne accetterai le conseguenze' possono aver senso, anche se sono indice di relazioni di lavoro che poggiano su fragili fondamenta. I manager possono richiedere e demandare responsabilità. Per esempio, un manager può domandare che il software sia pronto per il deploy alla fine della settimana, così che i progressi del team siano visibili. D'altro canto la responsabilità può essere offerta anche se non richiesta. "Vi posso mostrare un log di come ho speso il mio tempo la settimana scorsa' è un offerta di responsabilità.

Offro responsabilità per dimostrare la mia affidabilità e per incoraggiare me stesso a comportarmi al meglio. Per esempio, quando rendo conto alla mia sposa della questioni finanziarie, noi discutiamo su come spendere il denaro. Ci accordiamo sugli obiettivi e i principi delle nostre finanze. Io rendo conto a lei per come spendo veramente il denaro. Se perdessi dieci dollari per qualche cosa di inutile, direi solamente le cose così come stanno e attenderei la sua risposta. Avendo queste discussioni preliminari e sapendo che dovrò rendere conto, mi aiuta a spendere il mio denaro in maniera più saggia e a far crescere il nostro legame.

Nello stesso modo, quando programmo offro responsabilità, come un modo per dimostrare la mia affidabilità incoraggiando il mio miglior comportamento. Pair programming (la programmazione in coppia); test-first programming (programmazione scrivendo prima i test); integrazione continua; cicli quotidiani, settimanali e annuali resi visibili; rilassamento; e stime sono uno dei modi per prendermi degli impegni pubblici e rendere conto delle mie attività. Sapere di essere onesto e responsabile influenzerà il modo in cui svolgo il mio lavoro, così come sapere che sto nascondendo o occultando negativamente influisce sul modo in cui svolgo il mio lavoro. Assumere delle responsabilità per mia scelta e azione allontana la colpevolezza. Non c'è nessuna vergogna se tutto quello che faccio è sotto gli occhi di tutti.

Quando programmo con un collega, gli rendo visibile il mio pensiero e ascolto il suo. Se sono confuso, glielo dico. Se non mi piace il nostro design, glielo dico. Siamo liberi di chiedere una spiegazione o di ottenere delle idee dagli altri. Se non possiamo arrivare ad una soluzione migliore, allora andiamo avanti come meglio possiamo. Non c'è nulla da nascondere in questo processo, nessuna colpa, nessuna vergogna.

Test-first programming è una forma di responsabilità, specialmente quando praticata nella sua forma più pura dove nessun codice applicativo è stato scritto senza un test che fallisse prima. I test rappresentano un resoconto dei miei pensieri quando programmo. Essi registrano i problemi che considero. Se un problema non è rappresentato da un test, si presume che non l'abbia considerato quando stavo programmando.

Integrazione continua rende conto al team, circa ogni ora, di ciò che si sta facendo al sistema. Fermarmi nel lavoro per assicurarmi che tutti i test girano, aggiunge responsabilità, così come accertarmi che, nel caso io abbia creato un problema al sistema, ne ponga rimedio prima di procedere.

Avere i cicli di pianificazione visibili offre l'opportunità di rendere pubblici gli impegni e, alla fine del ciclo, di render conto di questi impegni. Non sono molto contento di perdere tempo, di non domandare aiuto quando serve, di evidenziare un'informazione incerta, quando so che dovrò renderne conto al termine della mia giornata o della mia settimana. 'Ho perso tre giorni per non aver fissato il difetto 142 perché avevo timore di chiedere aiuto' è più imbarazzante che chiedere aiuto.

Fare delle stime vuol dire anche prendersi degli impegni. Senza stime io non so quanto è necessario per fare una cosa. Senza qualche incertezza nei miei piani, in ogni caso, so anche che regolarmente non manterrò questi impegni. Prendere e mantenere impegni è una componente importante nel processo di creazione di legami forti durante lo sviluppo, legami che sosterranno il team nei momenti di difficoltà.

A volte nell'offrire responsabilità ho paura delle conseguenze ('se solo sapessero quando tempo ho impiegato a correggere quel difetto, penserebbero che sono un idiota'). Lavoro tanto meglio quanto più sono affidabile. Se sono un idiota, è meglio prenderne consapevolezza, piuttosto che fingere che non sia vero. Se ho fatto del mio meglio, non ho nulla da temere dal giudizio degli altri. Se stimo con sicurezza che un lavoro mi richiederà quattro mesi, allora se qualcuno mi dice che a loro piacerebbe averlo in due mesi, posso sincerarmi su cosa loro pensano veramente. Posso rispettare la loro posizione senza necessariamente condividerla. Posso ascoltare le loro necessità, non solo le parole o i suoni. Posso cercare dei modi che siano mutualmente benefici per rispondere a queste necessità. Se io sono sicuro delle mie stime e del mio lavoro, allora "posso dormire quando il vento soffia".

Quando vedo l'evoluzione del lavoro nel mondo IT, vedo un'evoluzione verso team e organizzazioni che offrono responsabilità. Il livello 5 del CMMi ha diversi pro e contro, ma quello che effettivamente offre è visibilità. Team a quel livello dicono ciò che hanno pianificato di fare e riporteranno ciò che fanno veramente. Dopodiché essi rifletteranno su questa esperienza per migliorarsi.

Responsabilità non è semplicemente una questione di riportare i fatti. Se so che ho creato dei difetti questa settimana e riporto ciò in modo accurato, allora sono onesto, non responsabile. Non ho completato il mio lavoro in modo da conviverci serenamente. Non sto agendo in modo da costruire dei legami, legami necessari al buon sviluppo del software. Extreme Programming è un modo di lavorare. I suoi principi e le sue pratiche contribuiscono alla mia abilità di essere responsabile quando sviluppo. La responsabilità mi incoraggia a fare il mio lavoro al meglio. Resisto alla tentazione di trovare delle scorciatoie o di lasciare del brutto codice quando so che altri lo vedranno e se ne prenderanno cura.

La responsabilità è importante a diversi livelli. Essere responsabile con me stesso, anche se è si tratta solo di fare e rivedere le to-do list quotidianamente, aiuta a focalizzare i miei sforzi e ottenere soddisfazione da ciò che porto a compimento. Dentro un team, la responsabilità incoraggia la formazione di fiducia, una fiducia che libera energia da usare per raggiungere gli obiettivi condivisi invece che per proteggere il proprio giardinetto. Team che offrono responsabilità ai loro clienti e alla loro organizzazione, generano anche fiducia. Quando un team responsabile dice "sei mesi", gli altri possono fidarsi di questa informazione e agire sulla base di quella informazione, certi che il team persegue un mutuo interesse. Qualche organizzazione di sviluppo si è spinta tanto oltre da rendere accessibili pubblicamente le proprie metriche interne sulla qualità, offrendo responsabilità al mondo in generale per dimostrare la loro affidabilità, per comunicare quanto credono in ciò che fanno e per incoraggiarsi a dare il massimo.

La mia esperienza è quella che quanto più è alta la mia responsabilità, quanto più esprimo i miei impegni apertamente e direttamente e riporto le mie attività, quanto più ascolto con empatia gli altri, tanto più vedo risultati migliori. Quanto più sono responsabile, tanto più sono creativo, tanto più è il lavoro che porto a termine, tanto più creo valore, tanto più apprendo velocemente, tanto più "posso dormire quando soffia il vento".

Kent Beck