Se il successo di un progetto dipendesse dalla qualità
In perenne ritardo
31
gen
2012
Tra l’incudine di sviluppatori che chiedono tempo e il martello di dirigenti che chiedono time-to-market, a rimetterci è spesso il livello del software.
Sarà anche considerato un social network noioso e prevalentemente ad uso e consumo di imprenditori e venture capitalist, ma su Quora trovo spesso contenuti molto interessanti. Tra le tante domande pubblicate, mi è balzata all’occhio quella dal titolo Why are software development task estimations regularly off by a factor of 2-3?.
Particolarmente divertente ed interessante la risposta di Michael Wolfe, che utilizzando la metafora del viaggio spiega quanto sia facile fare stime totalmente sbagliate:
Holy shit! We are starting day 5 of a 10 day trip and haven’t even left the Bay Area! This is ludicrous! Let’s do the work to make an accurate estimate, call our friends, probably get yelled at, but get a realistic target once and for all. My friend says, well, we’ve gone 40 miles in 4 days, it is at least a 600 mile trip, so that’s 60 days, probably 70 to be safe. I say, “no f–ing way… yes, I’ve never done this walk before, but I *know* it does not take 70 days to walk from San Francisco to Los Angeles”.
In molti casi le stime falliscono perché sono il prodotto di una negoziazione tra sviluppatori e management, con i primi che tendono in modo difensivo a sovrastimare e il secondo che per comprensibili motivi economici o di time-to-market ha il desiderio di tagliare i tempi, ignorando però l’intrinseca complessità del processo di sviluppo software. In tutto questo, la vittima sacrificale è quasi sempre la qualità del software che viene prodotto.
Non sarebbe forse più opportuno usare come metrica per valutare il successo di un progetto di sviluppo la qualità del software prodotto piuttosto che quella del tempo di realizzazione?
No. La metrica non può essere la qualità del prodotto perché non è vendibile ne stimabile.
L’unica cosa che il management, regolarmente composto da incompetenti in materia di sviluppo, può tentare di capire è il tempo necessario. Siccome tempo=denaro meno tempo = più denaro.
Soprattutto in Italia abbiamo ancora manager che credono che risorse infinite = tempo di sviluppo 0
Guarda caso i progetti gestiti da ex sviluppatori sono generalmente completati entro il tempo previsto.
Peccato che siano mosche bianche nel panorama IT italiano.
Lordmax permettimi di dissentire: la qualità del software – inteso sia come codice sia come prodotto finito – è misurabile. In industrie come quella aerospaziale ad esempio il codice viene sottoposto a severi test e/o si utilizzano tecniche di Model Checking per verificarne la validità. Il caso di Ariane 5 in ha fatto scuola almeno in quell’ambito (http://www.around.com/ariane.html). Ma senza scomodare la verifica formale di correttezza del software uno sviluppatore che correda il proprio codice di Unit test, functional e integration test e che utilizza soluzioni di continuous integration e deployment produrrà sicuramente del codice di migliore qualità. Dal codice di migliore qualità al prodotto finale che funziona meglio il passo è breve.
@Andrea. Sì, verissimo quello che hai detto, nulla da eccepire.
Ora, io non so che lavoro fai ma io sono un analista sviluppatore e credimi quando ti dico che negli ultimi dieci anni almeno non ho mai trovato un project manager a cui fregasse minimamente qualcosa (quando sapeva di cosa di trattava ovviamente) di unit test, functional test, non regression test e qualità in generale. Il punto era solo e sempre:
“Quando mettiamo la deadline?”
“Possiamo anticipare questo o quello?”
“Ma se mettiamo due risorse in più riusciamo a dimezzare il tempo”
E ancora il massimo della qualità richiesto è: “fallo che funzioni poi in futuro vediamo”… e questo è già molto avanzato.
Uno degli aspetti che non avete affrontato è che il buon analista oltre a saper sviluppare( un codice ben strutturato di facile manutenzione, e di semplice interpretazione/lettura) deve essere anche in grado di saper valutare il tempo a lui necessario.. Spesso , molto spesso o si tira ad indovinare, o meglio abbondare per poi non trovarsi nei guai, ecc ecc. Nella mia lunga carriera prima di sviluppatore, poi di analista ed infine come project manager , pochi sono stati gli analisti che conoscevano le tecniche per la valutazione metrica/temporale del segmento di progetto di cui si dovevano occupare
Un saluto e buon lavoro ben valutato…..
Zag(c)