Nel precedente post abbiamo parlato del Critical Mass of Software System (CMSS), definendolo come:
“il fattore di complessità che separa la convenienza di manutenere ed estendere il sistema con quella di riscriverlo interamente”
ed evidenziando l’opportunità di utilizzare pratiche Agili/Lean per aumentare la manutenibilità del software e gestire il debito tecnico, primi di elementi della governance della CMSS.
In questo post chiuderemo il cerchio parlando del terzo elemento che condiziona la Massa Critica, ovvero il “business”, intenso come quella componente aziendale poco interessata alle questioni tecniche ma concentrata su quelle economiche. Nonostante in un’azienda spiccatamente Agile/Lean technicality e business dovrebbero essere fortemente connesse, quasi a formare un uroboro, purtroppo la realtà è ben diversa e bisogna tenerne conto.
Quindi, il problema con cui dobbiamo confrontarci è: come facciamo a convincere il nostro business a supportare azioni che aumentano la qualità del software, sacrificando, spesso, tempo e risorse (e quindi aumentando i costi)? Un esempio: la necessità di abbattere il debito tecnico potrebbe richiedere la necessità di effettuare un refactoring per aumentare la qualità del codice scritto, introducendo un nuovo design pattern. Se il software ha superato i test (in particolare di accettazione), da un punto di vista funzionale tale azione non introduce nessun valore immediatamente percepibile, ma ne aumenta i tempi di sviluppo. Chiaramente il sistema ne guadagna, al minimo, in manutenibilità.
Laddove vengano adottate tecniche di riduzione del debito tecnico, siamo difronte ad un Delay Point, che graficamente abbassa la linea dei costi di manutenzione, ritardando il punto di massa critica.
Delay Point
Per convincere il management, possiamo sfruttare “l’effetto paura” (fear effect), associato al fattore di Massa Critica e al rischio di dover ricominciare da capo poco dopo il rilascio della prima versione del sistema prodotto. Meglio ancora se il tutto è presentato in forma grafica.
A questo punto ci scontriamo con il problema, già evidenziato nel post precedente, di trovare un modo per stimare il punto di Massa Critica, esercizio che attualmente, allo stato dell’arte delle tecnologie informatiche, non è ancora realisticamente possibile. Quello che invece voglio proporre è il calcolo di un nuovo valore che definiremo Indice di Massa Critica del Software (Critical Mass of Software System Index, CMSSi), ovvero un indicatore compreso tra 0 e 1 che indica la probabilità di deferimento del punto di CMSS.
Il modello di calcolo del CMSSi, definito in base alla mia personale esperienze e chiaramente migliorabile, è il seguente:
CMSS = (Delivery Time / Software Complexity) + Team Maturity
con Team Maturity = (Project Numbers / Co-working Years) * Skills Factor
in cui:
- -Delivery Time = tempo disponibile per lo sviluppo del progetto (in anni solari);
- -Software Complexity = Complessità stimata del progetto espressa in Story Point;
- -Team Maturity, il grado di maturità raggiunto dal Team in quanto tale
o Nel caso di costituzione di un nuovo Team, il rapporto (Project Numbers / Co-working Years) è considerato pari a 0, annullando di fatto anche il peso allo Skills Factor. Ciò è assolutamente in linea con il mondo Agile/Lean in cui l’individualità lascia il posto al Team;
o Lo Skills Factor indica il peso delle professionalità presenti nel team con un delta di valori ammissibili tra 0 ed 1, maggiorato di 0,1 per ogni figura senior.
Il modello evidenzia come il CMSSi sia direttamente proporzionale al tempo disponibile e inversamente proporzionale alla complessità del software che si sta realizzando. Inoltre la maturità del Team influisce in modo lineare.
Facciamo alcuni esempi:
· ProgettoA:
o Delivery Time = 6mesi = 110 gg
o Software Complexity = 400 Story Point
o Team Maturity = (1/2)*0,4 = 0,2
§ CMSS = 110/400 + 0,2= 0,475
· ProgettoB:
o Delivery Time = 1anno = 220gg
o Software Complexity = 400 Story Point
o Team Maturity = (1/2)*0,2 = 0,1
§ CMSS = 220/400 + 0,1= 0,65
· ProgettoC (Team con meno di un anno di lavoro congiunto)
o Delivery Time = 1anno = 220gg
o Software Complexity = 400 Story Point
o Team Maturity = (0)*0,2 = 0
§ CMSS = 220/400 + 0 = 0,55
· ProgettoD (progetto con un Delivery Time assolutamente insufficiente)
o Delivery Time = 1mese= 20gg
o Software Complexity = 400 Story Point
o Team Maturity = (1/2)*0,2 = 0,1
§ CMSS = 220/400 + 0,1= 0,15
Utilizziamo ora il CMSSi per convincere il proprio business della necessità di tener conto del fattore di massa critica, sfruttando due grafici semplici ma, al contempo, ricchi di significato.
Prendiamo il precedente ProgettoC, il cui indice è 0,55:
CMSSi 0,55
Se allo scenario base del ProgettoC, concediamo al Team altri 6 mesi (110gg circa), affinché possano colmare le lacune dovute al fatto che si tratta di un Team neo-costituito, il CMSSi diventa il seguente: 330/400 + 0,1 = 0,925, dilatandosi molto.
CMSSi 0,925
Graficamente il risultato è decisamente evidente e difficile da ignorare.
A questo punto abbiamo convinto il business? Probabilmente no, ma abbiamo uno strumento in più per confutare le nostre asserzioni e spingere l’azienda ad investire sulla qualità.
Prima di chiudere è utile evidenziare che il modello proposto per il calcolo del CMSSi non esclude che l’indice possa essere maggiore di 1. In tal caso le risorse spiegate per il progetto sono probabilmente eccessive e si può procedere ad una loro rivalutazione a ribasso, con estrema felicità del management.
