Parte I/II
Gli Antipattern possono essere evitati, o almeno riconosciuti e affrontati in modo più efficace, adottando un approccio di system thinking
La comunità dei tecnici informatici, comprendendo in questa definizione tutti quelli che a vario titolo hanno a che fare con l’informatica e la teoria dell’informazione (di cui anche lo scrivente fa parte), ha conosciuto in questi ultimi anni molte “nuove” metodologie, prodotti e tecnologie funzionali alla gestione dei progetti, dello sviluppo software e del delivery in generale.
Tra le metodologie più note e utilizzate c’è senza dubbio quella Agile, un approccio allo sviluppo basato sulla distribuzione continua di software efficienti, creati in modo rapido e iterativo.
In questa sede vogliamo introdurre due concetti perfettamente integrabili a tale metodologia: antipattern e system thinking.
ANTIPATTERN
Il termine fu coniato originariamente nel 1995 da Andrew Koenig, ispirato dal libro Design Patterns: Elementi per il riuso di software ad oggetti, scritto dalla cosiddetta Gang of Four (la banda dei quattro, ovvero Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides), i quali svilupparono il concetto di pattern nel campo del software. Com’è noto i pattern sono soluzioni progettuali generali ad un problema ricorrente che può ripresentarsi durante le fasi di progettazione e sviluppo del software.
Antipattern è “una soluzione, che smette di essere una correzione efficace quando l’effetto cumulativo dell’applicazione ripetuta, di tale correzione, ha un impatto negativo continuativo”. In altri termini sono dei design pattern, o più in generale delle procedure o modi di fare, usati durante il processo di sviluppo del software, che pur essendo lecitamente utilizzabili, si rivelano successivamente inadatti o controproduttivi nella pratica.
Gli Antipattern Agile si manifestano in genere come soluzioni comunemente applicate a problemi identificabili e ampiamente riconosciuti. Al seguente link trovate una catalogazione degli Antipattern Agile, ed un approfondimento dettagliato.
SYSTEM THINKING
Il Systems Thinking è un modo di pensare volto alla risoluzione di problemi complessi e legati all’incertezza. Trae origine dalla teoria dei sistemi (più propriamente teoria del sistema di Ludwig von Bertalanffy ) ed è un settore di studi interdisciplinare, che si occupa dell’analisi delle proprietà e della costituzione di un sistema in quanto tale. Nello specifico il System Thinking è un “processo di comprensione di come le cose si influenzano l’un l’altra all’interno di un tutto (sistema) e di come queste interrelazioni impattano sugli obiettivi comuni di quel tutto”. Si tratta quindi di un approccio che cerca di utilizzare la comprensione del sistema per aiutare le organizzazioni a strutturare i processi, le attività, l’organizzazione e la gestione aziendale, in modo da favorire lo sviluppo di processi e la nascita di prodotti ad elevato contenuto innovativo. I team agile ad alte prestazioni utilizzano il concetto di system thinking in modo molto efficace, poiché ispezionano ciò che fanno e come lo fanno adattando continuamente il loro operato al fine di migliorarlo, quindi attuando una visione di contesto più ampia del semplice perimetro progettuale e di prodotto. Una caratteristica dei sistemi è infatti la capacità di mantenere stabilità attraverso il feedback.
Ironia della sorte, le organizzazioni che utilizzano Agile possono fungere da terreno fertile per gli Antipattern, poiché l’empirismo su cui questa metodologia poggia, tende a far emergere continuamente problemi e ad affrontarli, facendo si che nei team si crei un sistema interno di “ricerca problemi”.
Certamente questo può indurre talvolta ad una cultura eccessivamente orientata alla risoluzione di problemi troppo periferici. Diviene importate allora riconoscere sia il punto di origine dei problemi, sia il l’impatto più ampio delle risposte messe in campo, cioè applicare un approccio basato sul system thinking può essere di grande aiuto, proprio per evitare scenari di proliferazione di Antipattern.
Un esempio di Antipattern organizzativo o gestionale molto comune, riscontrato anche dalle indagini condotte dagli appartenenti alle comunità Agile è quello regolato dalla “legge” di Brook, che afferma schematicamente:
“l’aggiunta di personale a un progetto in ritardo lo ritarda ulteriormente”
I team di sviluppo spesso lamentano (spesso giustamente) di avere risorse insufficienti e accolgono con favore l’aggiunta di nuovi sviluppatori. Le “braccia” in più spesso creano maggior volume, ma non un’adeguata qualità, prima di tutto perchè la creazione di un volume aggiuntivo significa portarne il “peso” (sia nel bene che nel male) per cercare di riuscire a traguardare la realizzazione del prodotto.
La questione è che le soluzioni che gli Antipattern sembrano offrire possono essere estremamente seducenti e occorre un team estremamente performante ed altamente evoluto, per rifiutarle.
Parliamo di risorse extra (ciò è alla prova dei fatti, in molte organizzazioni di successo!), per prediligere soluzioni più sistemiche spostate sull’organizzazione, come ad esempio la “ricontrattazione” con l’owner di progetto dei requisiti e quindi del backlog di prodotto.
Antipattern ancora più diffuso (ampiamente sentito) è la decisione di inserire un numero di team Scrum, in un’organizzazione, nella speranza che i team Scrum possano ben funzionare e in tal modo fungere da motore per la trasformazione organizzativa. Questa soluzione raramente ha successo, laddove l’interrelazione tra i team e l’organizzazione non è chiaramente compresa e articolata.
In molti casi, questi Antipattern possono essere evitati, o almeno riconosciuti e affrontati in modo più efficace, adottando un approccio di system thinking sia da parte dei team Agile, sia all’interno dell’organizzazione in relazione agli “effetti” delle forze esercitate sui gruppi di lavoro in generale.
Nella prossima puntata approfondiremo ulteriormente questi concetti.
