Stima dei costi del software: perché no?

A volte mi sembra di non vivere nello stesso mondo di tutti gli altri. ero (e sono), coinvolto nella stima del software professionale, Analisi comparativa, e contrarre processi per quasi metà della mia vita, e ancora la maggior parte delle persone con cui parlo non ha la più pallida idea di cosa si tratti. Soprattutto il "groovy"., Freddo, nuovo, giovane, generazione di giovani super rilassati ', non ha idea di cosa sto parlando. “La stima del software è difficile, e va sempre male, quindi perché anche provarlo?’ ‘#Nessuna stima’, dai un'occhiata su twitter, è una cosa reale. E queste persone sono serie! Credono nel potere della squadra. Questo è più facile a dirsi che a farsi quando hai un'attività da gestire. Come un mio caro amico, che lavora per un grande system integrator internazionale, mi dice sempre: 'Nessun cliente ci ha mai dato un milione di dollari con la richiesta di realizzare qualsiasi soluzione software, fintanto che porta un certo valore commerciale". Sono così infastidito ogni volta che le persone dicono che la stima del software non è più necessaria nel mondo agile della consegna. è, e anche più di prima!

I team agili usano spesso i punti della storia, un'unità di misura dello sforzo arbitrario relativa a una certa quantità di lavoro. I punti della storia non sono ripetibili, non verificabile, non obiettivo e non difendibile. Ma la comunità agile sembra riuscire a convincere il management IT su questo pianeta che le metriche basate sui punti della storia sono utili per supportare le decisioni del management.

È davvero come se qualcuno avesse convinto i pittori nel mondo a usare i "punti del muro" invece di una metrica standardizzata come il metro quadrato per misurare le dimensioni dei muri e stimare i loro lavori di pittura murale. Non credo che molte persone accetterebbero una citazione come "ti addebiterò". $ 100 per punto di parete", Giusto? Semplicemente non ha senso, poiché il numero di punti di muro non può mai essere misurato oggettivamente, in quanto non standardizzato. Per dare una citazione come '$ 100 per metro quadrato' ha molto senso, perché è standardizzato, e quindi trasparente, prevedibile e difendibile.

 

Solo oggi, Ho parlato a 2 diverse organizzazioni di clienti, sia lamentandosi che il loro fornitore, lavorare agile, ha completamente sottovalutato lo sforzo necessario per implementare un software "indispensabile"., con conseguenti gravi sforamenti di costi e tempistiche. Come è possibile anche in Agile, tu chiedi? Molto semplice! Sebbene l'ambito dovrebbe essere variabile, le organizzazioni hanno ancora bisogno di un certo insieme minimo di funzionalità (e non funzionale) i requisiti degli utenti devono essere pronti e implementati in un determinato momento e allocano anche un budget per questo, perché devono rispettare le leggi finanziarie e contabili. Se sottovaluti lo sforzo (e lo farai se utilizzi solo stime di esperti!), il team sarà troppo piccolo e il software non sarà pronto quando dovrebbe esserlo.

La stima del costo del software è ancora molto rilevante, anche in tempi agili. Alla conferenza annuale della International Cost Estimation and Analysis Association (ICEAA), lo scorso giugno a Phoenix (IL, Stati Uniti d'America), ICEAA e Nesma hanno introdotto il Software Cost Estimation Body of Knowledge (sCEBoK). In questa conferenza, Sopra 450 stimatori di costi di organizzazioni come Boeing, NASA, Lockheed Martin, Marina americana, eccetera. convocato per discutere le pratiche professionali di stima dei costi, anche per quanto riguarda il software. Per loro non è un'opzione nascondersi dietro punti della storia arbitrari, devono rispettare gli standard internazionali e le migliori pratiche per assicurarsi che la stima sia accurata, ma anche il più difendibile possibile.

Come esperimento sociale, Ho deciso di pubblicare un messaggio per informare l'industria sull'iniziativa Nesma/ICEAA in diversi gruppi di LinkedIn, ed ero particolarmente interessato a vedere le reazioni del gruppo "Sviluppo software agile e snello", che è finita 140.000 membri. Il testo:

“I processi di stima della maturità in media sono ancora piuttosto bassi. Grandi somme di denaro continuano ad essere sprecate perché i progetti non sono stati valutati professionalmente, con conseguenti sforamenti di costi e tempistiche. Uno dei problemi in tutto il settore è il fatto che lo stimatore dei costi del software spesso non è una professione riconosciuta. In molte organizzazioni, le stime si basano sull'esperienza e sulle opinioni di esperti umani di parte, invece di basarsi su dati storici rilevanti e modelli parametrici. Nesma e ICEAA (Costo Internazionale stima e analisi Association) stanno lavorando insieme per creare un programma di formazione e una certificazione per "Software Cost Estimator", un ruolo professionale per la stima di attività e prodotti relativi al software.

In collaborazione con una serie di organizzazioni di supporto e professionisti del settore, Nesma e ICEAA hanno lavorato insieme per sviluppare un corpo di conoscenze per la stima dei costi del software (sCEBoK). In linea con i programmi di formazione e certificazione che ICEAA ha già per la stima dei costi, l'obiettivo è sviluppare un programma di formazione e certificazione specifico per il valutatore dei costi del software. Il piano è di far certificare i primi stimatori di costi software professionali l'anno prossimo alla conferenza ICEAA di maggio 2019 a Tampa, FL e all'IWSM a novembre 2019 ad Haarlem, Paesi Bassi'

Per favore, dai un'occhiata se ne hai la possibilità: https://www.linkedin.com/groups/37631/37631-6422686037318860800

 

È davvero incredibile ciò che questa comunità di professionisti pensa della stima dei costi del software. Solo alcune delle reazioni:

'Perché dovremmo voler diventare maturi sprecando il nostro tempo?'

"Mai impressionato da stime accurate sui nuovi sviluppi."

'Scusa se questo sembra sarcasmo, ma hai inventato una sfera di cristallo più sofisticata per produrre numeri casuali più precisi.'

"Penso che faresti meglio a portarlo alle comunità a cascata e ai project manager poiché le comunità agili rideranno solo di questo."

‘ Ho visto alcune cazzate di cavallo fumanti pubblicate in questo gruppo, ma questo è in cima alla pila

'Prendi in considerazione ciò che ti puoi permettere. Chiedi ai team di consegnare continuamente in modo da poter vedere cosa stai ottenendo per i tuoi soldi. Migliorare continuamente. Se non ottieni abbastanza valore, causa principale perché. '

'Ancora un'altra certificazione per gli aspiranti da acquistare… Proprio quello di cui ha bisogno questo settore.'

 

E molti altri commenti duri e ingiusti, dalla comunità che sembra non preoccuparsi affatto delle implicazioni finanziarie dello sviluppo del software (anche se c'erano anche alcuni commenti di supporto, devo ammetterlo).

Dirigenti su questo pianeta, si prega di prendere nota di queste reazioni, poiché incarnano i veri sentimenti e le convinzioni di molti professionisti del settore. Sentono davvero di non aver bisogno di stime (dato che comunque non sono i loro soldi) e non vogliono essere responsabili di nulla, esprimere la velocità in "casuale"., non ripetibile, unità di misura arbitrarie non standardizzate (per esempio., punti della storia)' e quindi mai responsabile di nulla. Gettare soldi in team agili e sperare per il meglio potrebbe funzionare in alcuni casi, ma ti deluderà nella maggior parte dei casi! “Il software è un R&D processo e risultati sono imprevedibili!' Questo non è vero! La stima del software non è facile, ma può essere fatto in modo accurato, prevenendo molti sforamenti di programma e budget come testimoniamo oggi!

In realtà, questo è il problema di fondo dell'intera industria del Software. Negando che sia possibile misurare accuratamente la dimensione dei requisiti software con l'uso di standard internazionali, la maturità stimata rimane bassa. Se studi il lavoro del professor Abran, ad esempio il suo studio sul potere di previsione dei punti della storia rispetto alla misurazione della dimensione funzionale (https://tinyurl.com/y9jf98tq), vedi che anche l'arbitraria unità di misura dello sforzo inventata affinché le squadre rimangano incomparabili e irresponsabili (punti della storia), non ha quasi lo stesso potere di previsione quando si tratta di stima del software quanto la misurazione della dimensione funzionale.

La domanda fondamentale rimane ... i dirigenti in questo mondo che si occupano di team agili continuano davvero a comprarlo? Ad un certo punto penseresti che capiscano di essere stati truffati per lanciare più soldi alle squadre con risultati discutibili da seguire: meno funzionalità del previsto/richiesto, bassa qualità, costo maggiore, soprattutto nella manutenzione.

ICEAA e Nesma sono fiduciosi che il Software Cost Estimator certificato diventerà una vera e propria professione nel settore, che aiuterà le organizzazioni a migliorare la maturità del loro processo per quanto riguarda la stima, La metrica del software o la misurazione del software è un concetto dell'industria del software, valutazione della prestazione, benchmarking e approvvigionamento. Il Software Cost Estimator aiuterà i dirigenti IT a mantenere il controllo sui loro team di consegna agili senza infastidire i team con costi generali e sprechi, apportando sufficiente trasparenza per prendere decisioni informate.

Condividi questo post su:

lascia un commento