Function points e Snap points: come creare un preventivo rigoroso

Abbiamo già parlato delle difficoltà legate al preventivo in un precedente articolo, nel quale ci siamo soffermati sul lato commerciale e di relazione con il cliente. Oggi vorremmo parlarne ancora, affrontando l’argomento da un punto di vista più tecnico, lato operatore.

Vediamo quindi quali sono le difficoltà principali e quali le possibili soluzioni.

Stimare un lavoro e quindi la complessità di un task per organizzare gli sprint (secondo i correnti approcci agile), costruire il budget per un progetto e definire i tempi di milestone e release sono problemi ricorrenti e critici per ogni sviluppatore software.

Ognuno ha il proprio metodo ed è inutile negare che l’esperienza giochi un ruolo importante. In questo articolo vi metteremo a disposizione la nostra, proponendovi un approccio più sistematico e oggettivo possibile.

Perché l’approccio dovrebbe essere sistematico e oggettivo?

Domanda lecita. Facciamo un esempio. Immaginate un fruttivendolo che non possa per qualche motivo stimare il valore della sua merce; sarebbe costretto ad andare a occhio, affidandosi all’esperienza. Inoltre dovrebbe bilanciare la necessità di esser prudente per non andare in perdita e quella di non sparare cifre troppo alte per tenersi il cliente. Diventerebbe un lavoro molto rischioso, il fruttivendolo.

Lui però ha due elementi molto efficaci su cui basarsi: il peso della merce e il prezzo al chilo. Bastano a metterlo in condizione di stabilire un prezzo finale preciso, esatto. A partire da quello potrà poi fare delle personalizzazioni, aggiungendo degli elementi non quantificabili ma comunque importanti, ad esempio una quota per la consegna a domicilio o perché, semplicemente, ha potuto constatare che le sue fragole sono le più profumate sulla piazza, quest’anno.

Nello stesso modo anche l’informatico, che pure tratta un tipo di prodotto completamente diverso, ha bisogno di parametri oggettivi di partenza e di un sistema che gli permetta una base solida di valutazione.

Come possiamo fare?

Utilità Vs Caratteristiche

Partiamo dall’inizio: un software può essere valutato su due scale: requisiti funzionali (la quantità di operazioni che riesce a svolgere) e requisiti non funzionali (la qualità del codice, la sua manutenibilità, e molto altro).

La complessità e qualità di un software, insomma, dovrebbe essere tradotta in modo oggettivo sulla base dell’utilità reale che fornirà agli utenti per cui è realizzato, e non sulla base delle caratteristiche interne.

Se prendiamo un software che calcola il perimetro di figure geometriche piane e lo confrontiamo con uno che calcola sia il perimetro che l’area, risulterebbe evidente che il secondo è più grande del primo, perché in grado di svolgere più funzioni (cioè soddisfa un maggior numero di requisiti funzionali).

Nel caso dei requisiti non funzionali questo confronto è più difficile ma non meno importante. Ad esempio, supponiamo di voler costruire un software che calcola la somma dei primi 1000 di numeri:

soluzione1:
long tot = 0; 
for ( long i = 0; i <= 1000; i++ ) { 
tot = tot + 1; 
}

Queste righe di codice effettuano il calcolo e rappresentano una possibile soluzione , anche se forse non la migliore.

Per fare il conto si potrebbe considerare la formula matematica n * (n+ 1) /2

soluzione2: 
long n = 1000 
long tot = n * (n + 1 ) /2

questa seconda soluzione è sicuramente più elegante ma se ne possono immaginare di pessime. Ad esempio:

soluzione3: 
long tot = 0; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
tot = tot +1; 
... (ripeto la riga 1000 volte)

Ce ne sono infinite altre, realizzabili con vari sistemi e linguaggi ma soffermiamoci su queste: soluzione1, soluzione2 e soluzione3. Qual è davvero la differenza?

Dal punto di vista dell’utilità finale (requisiti funzionali) sono equivalenti ma se invece consideriamo la qualità (requisiti non funzionali) non lo sono per niente: la manutenibilità di soluzione1 e soluzione2 è la stessa, mentre quella di soluzione3 è peggiore. Allo stesso modo le performance di 1 e 3 sono equivalenti mentre soluzione2 è nettamente superiore.

Questo ci porta a un’osservazione importante: requisiti funzionali e requisiti non funzionali compongono, insieme, il valore di un software. Al tempo stesso queste due scale, pur costituendo insieme la natura del progetto, non sono la stessa cosa e non si possono semplicemente sommare.

Bene, quindi potremmo dire (semplificando molto) che nel nostro caso l’equivalente del peso per il fruttivendolo è l’insieme di questi due fattori. Bene. Ora però ci serve una bilancia, perché di fatto “requisito” è un termine ancora troppo vago, un termine che va bene nella comunicazione con il cliente ma non per la software house che voglia seriamente valutare l’impresa. Serve uno strumento che in modo oggettivo, matematico, possa misurare questi fattori e restituirci un valore, esattamente come fa l’ago della bilancia quando il fruttivendolo ci mette sopra delle mele renette appena colte.

Beh, ce l’abbiamo.

Function Points e Snap Points

Per misurare i requisiti funzionali si possono usare i Function Point, mentre per misurare i requisiti non funzionali si possono usare gli Snap Point.

FP e SP sono standard internazionali, così come il chilogrammo è una unità di misura riconosciuta dal sistema internazionale di pesi e di misure. E dai clienti.

E’ bene, in ogni caso, non pensare che sia una questione banale. Per arrivare a capire a quanti FP corrispondano i nostri requisiti funzionali e a quanti SP corrispondano i non funzionali bisogna considerare molte variabili:

La buona notizia è che dopo tutto questo lavoro possiamo finalmente dirlo: abbiamo trovato dei valori numerici. Abbiamo l’equivalente del peso per il fruttivendolo (che sta aspettando alla cassa da un po’) nella forma di una coppia di valori: FP e SP.

Ora ci serve solo il prezzo al chilo, ricordate? L’altro necessario strumento.

Facciamo un ultimo sforzo.

Dal fatto che FP e SP racchiudono e misurano le azioni che l’azienda dovrà intraprendere per realizzare il progetto, ne consegue che tanto ogni FP quanto ogni SP abbia sia un costo in soldi sia un costo in tempo. Costi e tempi sono senz’altro correlati ma non coincidenti e vanno calcolati separatamente.

Occorre quindi trovare un sistema con cui estrarre dalla nostra coppia di valori due nuovi valori: tempo e costo. Tale sistema sarà l’equivalente del prezzo al chilo per il nostro fruttivendolo, che a questo punto avrà fretta di chiudere.

Nel nostro caso l’arma migliore è il nostro stesso portfolio, i progetti completati. Supponiamo infatti di aver calcolato e registrato quanti FP e quanti SP valessero. Chiaramente dovremo curarci di selezionare progetti omogenei tra di loro e coerenti con quello che sto cercando di misurare, altrimenti sarebbe un po’ come se il fruttivendolo applicasse lo stesso prezzo al chilo alle more di rovo e all’anguria daytona.

A questo punto possiamo fare un’analisi di regressione (usando il metodo dei minimi quadrati) e ottenere dei fattori di conversione che, di fatto, sono il nostro equivalente del prezzo al chilo. Con questi fattori possiamo creare due funzioni che, applicate ai FP e SP, ci danno una il tempo e l’altra il costo.

E si tratta di una stima precisa, che riesce a tener presente anche i costi generali di riunioni e call di allineamento, non solo il tempo degli sviluppatori.

A questo punto ci siamo: abbiamo ricavato un tempo e un costo basati su stime oggettive che rispettano sia le necessità dell’azienda che quelle del cliente; e possiamo eventualmente applicare delle variazioni alla luce di fattori specifici, se ce ne sono.

E perché nessuno li usa?

FP e SP sono in giro già da un po’. Quindi perché non vengano usati, o comunque vengono usati molto meno di quanto potrebbero o dovrebbero? Buona domanda. Le critiche sono sostanzialmente due:

1. “FP e SP” non misurano tutto: ci sono fattori, soprattutto di qualità, che non possono essere matematicamente inclusi nel procedimento. Vero. Ma provate voi a dire all’ortolano di non pesare più la merce perché la bilancia non coglie il profumo delle mele. Provate. In questo caso la logica che se il sistema non è perfetto non vale la pena di usarlo non ci convince: permette comunque di ottenere una stima molto precisa e oggettiva dei costi.
2. “FP e SP” sono difficili da misurare. Vero. E questa critica è sicuramente più incisiva della precedente. Non è un sistema facile da implementare ma dopo aver fatto un po’ di esperienza possiamo affermare che non è neanche così tremendo. Con un po’ di pratica si arriva a padroneggiarlo senza problemi e i risultati che offre giustificano completamente la difficoltà iniziale.

In ultimo, un piccolo annuncio a riguardo: Jaewa sta sviluppando un tool per rendere semplicissimo e accessibile questo metodo, anche ai non addetti ai lavori. A quel punto non ci saranno più scuse, anche perché sarà possibile fare stime più precise e più in fretta, con notevoli benefici anche economici.

Vi terremo aggiornati.

Articolo originale su: https://www.jaewa.com