Agile Tech: per non scordarsi dell’eccellenza tecnica

Oltre Agile?

Sempre più spesso, nelle nostre attività di coaching agile presso i clienti, ci troviamo a dover specificare cosa “agile” sia e non sia… Di fatto, la percezione che delle varie tematiche Agile si ha, specie nelle grandi aziende, è ultimamente molto spostata verso il lato “relazionale”, “organizzativo”, “di processo” e molto meno verso l’aspetto tecnologico e informatico.

Eppure il “movimento agile” nasce come comunità di sviluppatori che stanno “scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso”.

Però, in molti ambiti, in cui si è arrivati da poco all’“agilità”, Agile viene spesso percepito solo come un tema “consulenziale” o legato alle trasformazioni aziendali, all’organizzazione, e molto meno al discorso “software”.

Un approccio globale

Intendiamoci: va anche bene così. Molte cose sono cambiate rispetto al momento storico in cui fu formulato il Manifesto Agile (2001) e oggi anche molte aziende che non sviluppano software come attività primaria traggono beneficio dall’applicare ai loro processi metodi come Kanban o Scrum.

Noi di Agile Reloaded, quindi, siamo i primi a credere nel valore di questo ampliamento della visuale.

Ma non dimentichiamo il software

Partiamo però anche dalla constatazione che la maggior parte delle persone che lavorano in AR proviene da esperienze di sviluppo software, che alcuni di noi hanno seguito fin dalle primissime mosse tutta l’evoluzione del Movimento Agile in Italia e che una delle nostre “aree di coaching” è dedicata ad Agile Tech.

Abbiamo pertanto deciso di parlare in questo post delle situazioni in cui eccellenza tecnica e software funzionante rappresentano i perni su cui incardinare tutto il lavoro di “agilizzazione” da svolgere in determinati contesti.

E non usiamo questi termini a caso: il settimo principio del Manifesto Agile recita infatti “Il software funzionante è il principale metro di misura di progresso”, e il nono ribadisce che “La continua attenzione all’eccellenza tecnica e alla buona progettazione esalta l’agilità”.

L’azienda, il manager e lo sviluppatore

Entriamo nel vivo del discorso guardando i temi legati allo sviluppo del software in ottica agile da diverse prospettive; cercando di mettersi nei panni delle diverse componenti che interagiscono nell’organizzazione che ingaggia dei coach agili a svolgere le loro attività.

Dovendo fare un discorso complessivo, sarà necessaria qualche generalizzazione nonostante ogni realtà abbia i suoi caratteri di peculiarità. Però va pure sottolineato come le considerazioni che seguono nascano sostanzialmente da esperienze dirette su casi reali.

Cosa cerca l’azienda

Se si fa eccezione per quelle poche aziende che hanno come core business proprio la produzione di software, riscontriamo in genere che le grandi organizzazioni non hanno sviluppatori interni o, per essere più precisi, non hanno al loro interno gruppi di sviluppatori stabilmente strutturati e sufficientemente numerosi per coprire le loro esigenze di sviluppo del software.

Nel panorama attuale, però, anche per aziende che non sono software house, lo sviluppo di software e la creazione/gestione di una piattaforma digitale, diventano attività che non possono essere considerate collaterali. Per aziende del ramo bancario, finanziario, assicurativo, ad esempio, oggigiorno il software non può essere considerato una commodity, poiché ormai è diventato una attività di primaria e suprema importanza anche per chi non lo sviluppa come core business. E questo vale per molti altri settori industriali e commerciali.

Tra avere tutto il proprio software sviluppato in consulenza esterna e fare ogni cosa all’interno dell’azienda esistono varie gradazioni. Magari internamente ci sono alcuni elementi a cui vengono demandati compiti di raccordo, ma mancano spesso dei team cross-funzionali e ben “addestrati” sia in termini di metodologie che di competenze tecniche legate alla programmazione.

Accade quindi che le aziende ricorrano a consulenze esterne in grado di fornire il personale che serve per fare sviluppo software. Chiaramente qui le scelte possibili sono diverse: si può puntare al massimo risparmio, oppure si può guardare a un modello di qualità elevata, in grado di fornire affiancamento tecnico e accelerazione con team esterni e di “formare” anche personale interno.

Iniziare ad avere all’interno persone dotate di elevate competenze, formarle con un coaching tecnico sulla programmazione e sulle metodologie, mantenerne elevato il livello con un aggiornamento costante, è un costo che, per quanto elevato, migliora sul medio e lungo termine la qualità del prodotto realizzato, riduce gli sprechi e, in definitiva, crea un know-how che resta dentro l’azienda e che ne diventa una risorsa di valore. Alla lunga, dopo il significativo investimento iniziale, l’azienda riduce i costi e il time-to-market.

Questa tendenza comincia a farsi strada, seppur non in maniera maggioritaria, perché il meccanismo appena descritto viene compreso laddove sia in atto un cambiamento di mentalità: vedere il software come un asset e non come come una commodity.

Cosa pensa il manager

Se ci focalizziamo a un livello di “ingrandimento” più prossimo a dove si sviluppa effettivamente il software, le nostre esperienze ci hanno fatto intravedere alcune situazioni tipiche.

Ad esempio, un fatto ricorrente riguarda le aziende italiane che fanno parte di grandi gruppi multinazionali. Negli ultimi anni, dai livelli più elevati, in molti casi è arrivato l’input top-down “Bisogna passare all’Agile!”.

Il manager che recepisce questo tipo di indicazione, che non ha seguito l’evoluzione del Movimento Agile e che non ha la passione e la competenza relativa alla programmazione – e stiamo volutamente semplificando – che potevano avere certi sviluppatori negli anni della “rivoluzione agile” tra fine anni Zero e primi anni Dieci, cosa fa? Cerca un po’ di orientarsi, chiama qualche azienda di Agile Coaching, sottopone richieste e ascolta pareri e magari poi parte con qualche iniziativa.

Ma in tutto questo, i decisori in genere non chiamano per interventi di tipo tecnico quanto piuttosto per ragioni legate alle trasformazioni agili, al miglioramento dei processi, alla facilitazione dell’individuazione delle caratteristiche di un nuovo prodotto. Ma è raro che si chieda, come prima domanda, “La Total Cost Ownership di questo sistema è ragionevole? Oppure il debito tecnico accumulato finirà per avere un costo insostenibile?”. In genere, la risposta scontata alla prima parte di questo interrogativo è sempre “Sì”, oppure “Al momento, si tratta di un aspetto meno importante degli altri”.

Cosa fa lo sviluppatore…

…o, come sarebbe sempre auspicabile, il team di sviluppo. Quando arriviamo a chi, effettivamente, sviluppa il software, quello che vediamo è un quadro abbastanza variegato, con livelli anche molto diversificati di competenza. Non è un giudizio di valore: semplicemente in molti casi le persone non hanno avuto le occasioni per diventare designer bravi, tester metodici, progettisti che impieghino gli approcci più “agili” (stile architetturale a microservizi, piattaforme ad API etc.).

E infatti, laddove ci siano gruppi interni all’azienda, riscontriamo che gli sviluppatori sono mediamente ben disposti e qualche volta davvero molto motivati ad apprendere nuove competenze e a intraprendere un processo di crescita. Abbiamo notato anche un cambiamento di mentalità da parte di alcuni di essi: pur essendo dei dipendenti, hanno cominciato a immaginarsi come dei professionisti che si aggiornano continuamente indipendentemente dagli input che arrivano dall’alto. Ma è importante che sia loro lasciato tempo e modo di sperimentare e di studiare: l’apprendimento strutturato, per quanto più pratico possibile, non si fa direttamente sulla produzione…

Detto questo veniamo al tema più strettamente tecnico e legato alla programmazione. Una cosa che ci sembra di poter dire è che eXtreme Programming, come canonicamente codificata dai suoi creatori, non esiste nelle realtà che vediamo o perlomeno è confinata a pochi, rarissimi casi di team molto avanzati o di piccole software house.

Però ci sono una serie di pratiche di derivazione XP che vengono molto usate a volte in modo corretto, altre volte in modo improprio o con un’interpretazione distorta rispetto a quanto previsto “canonicamente”.

Nella prima categoria facciamo rientrare il Test Driven Development che, quando applicato, lo è in genere in modo sensato. Accanto a TDD, anche le pratiche di Continuous Integration e le loro evoluzioni si sono ritagliate uno spazio.

Diverso è il discorso per quanto riguarda il pair programming che invece abbiamo molte volte riscontrato essere malinteso; infatti, per quanto raramente applicato, esso viene concepito più come un affiancamento tra programmatore più esperto e “apprendista”, che non come la reale pratica di scrivere codice in due persone per avere un migliore controllo su quello che si sta facendo. Insomma, nella realtà, ci pare di dire che XP “da manuale” lo fanno davvero in pochissimi.

Consigli agli sviluppatori

In un articolo pubblicato un paio d’anni fa sulla rivista Mokabyte, il nostro advisor Giulio Roggero esprimeva quelle che, a suo giudizio, erano le caratteristiche di un programmatore affidabile.

Rimandando all’articolo per una disamina più approfondita, le caratteristiche e le pratiche utili a definire la figura di uno sviluppatore di qualità erano state individuate in 5 punti di un elenco aperto a miglioramenti e aggiunte:

1. Semplicità delle soluzioni: prediligere architettura e design emergenti che si raffinano a mano a mano che il progetto si evolve, senza fare overdesign fin dall’inizio, e senza affidarsi ciecamente ai framework rimanendo vincolati ad essi.
2. Bilanciamento tra debito tecnico e valore di business: il concetto del debito tecnico dovrebbe prendere in considerazione anche il costo del ritardo, ed essere inquadrato in un calcolo quanto più oggettivo del valore effettivamente per l’utente.
3. Sviluppo guidato dai test: il Test Driven Development (TDD) non è solo una buona pratica di sviluppo, ma è soprattutto una pratica per creare un codice migliore; è impegnativo, richiede disciplina, spesso viene “aggirato”, ma funziona: occorre prenderne atto.
4. Rendere tutto automatico, fin dal primo giorno: dalle build, agli aggiornamenti, dai test al branch, a continuous integration, delivery e deploy, più tutto è automatizzato fin dall’inizio, meno problemi si inseriranno nel nostro codice.
5. Non “innamorarsi” della tecnologia ma degli utenti! E questo vale sia per chi resta aggrappato a linguaggi, strumenti e tecniche che conosce bene e che non è disposto a modificare, sia per chi, al contrario, è entusiasta di ogni novità e non vede l’ora di provare qualcosa solo perché è apparso da poco all’orizzonte.

Non solo per gli sviluppatori

Ci sentiamo di continuare a sostenere queste tesi, ma con un’ulteriore sfumatura. Come nel proverbio “Parlare a nuora perché suocera intenda”, il discorso è rivolto sì agli sviluppatori, ma deve essere recepito anche da chi sviluppatore non è, però prende delle decisioni che poi vanno a impattare proprio sul software e chi lo sviluppa. In un’ottica agile, da parte dei manager e dei livelli più elevati dell’organizzazione, occorre avere consapevolezza dell’importanza che il software funzionante riveste nel successo complessivo dell’azienda.

Sperimentare

Chiudiamo questa riflessione con una considerazione ormai diventata “di rito”: non stiamo dettando una soluzione preconfezionata e valida per tutte le situazioni, ma stiamo perseguendo un approccio pragmatico che non può che svilupparsi secondo il solito schema: individuare qualche pratica tecnica che non funziona, partire da lì, fare un esperimento, creare un miglioramento, valutarlo insieme e ripetere il processo ampliando sempre più lo sguardo sull’intero orizzonte tecnico e delle metodologie.