Punti storia e punti funzione: qual è la differenza e perché è importante? I punti della storia sono indicatori arbitrari dello sforzo previsto. Sono incoerenti e inadatti all'uso come metrica principale nei progetti software. Ti consigliamo di passare ai punti funzione COSMIC standard ISO e di fornire 14 ragioni per cui.
Punti storia e punti funzione: qual è la differenza e perché è importante? I punti della storia sono indicatori arbitrari dello sforzo previsto. Sono incoerenti e inadatti all'uso come metrica principale nei progetti software. Ti consigliamo di passare ai punti funzione COSMIC standard ISO e di fornire 14 ragioni per cui.
Cosa sono gli Story Point?
Nei progetti software Agile, uno story point (SP) è la quantità di impegno concordata da parte di un team per svolgere del lavoro. Le attività sono stimate nel numero di SP necessari per svolgere il lavoro. Gli story point sono una “valuta locale” arbitraria. Non esistono regole ferree su quanto dovrebbe essere grande un punto della storia. Non fanno nemmeno parte della Scrum Guide. L'entità di un punto della storia varia da squadra a squadra. Può variare anche nel tempo. Un punto della storia e la stima della dimensione di un pezzo di lavoro in SP è solo una "ipotesi collettiva" del team in un dato momento utilizzando una metrica incoerente. Essenzialmente i punti della storia sono un proxy inaffidabile per ore secondo Mike Cohn. Per ulteriori sfide con SP, vedi Problemi con i punti della storia.
Da dove vengono gli Story Point?
Gli story points sono il frutto di alcuni dei firmatari del Manifesto Agile. Vengono utilizzati solo dai team di sviluppo software agili. Uno dei principi fondamentali dello sviluppo software Agile è che i team si auto-organizzano. Di conseguenza, è diventata una pratica accettata che essi debbano anche inventare i propri indicatori di impegno. I punti della storia differiscono da squadra a squadra e cambiano anche nel tempo. Di conseguenza sono incoerenti e inaffidabili per qualsiasi scopo gestionale. Qualsiasi riferimento alla “velocità agile” basato sui punti della storia forniti, ha solo un valore modesto come indicatore del tasso di progresso.
Consentire al team di determinare la propria metrica per dimensioni/impegno ha un certo valore nel migliorare la coesione del team. Inoltre, è utile disporre di uno strumento per stimare il lavoro ausiliario (attività non specifiche per la fornitura di funzionalità), sebbene sia possibile utilizzare anche una semplice stima in ore.
I problemi con i punti della storia
- I punti della storia lo sono incoerente, nel tempo e da squadra a squadra.
- Essi non può essere utilizzato come metrica di base sui progetti
- Sono inadatto ai contratti
- Lo sono generalmente inadatto al miglioramento del processo
Punti Storia vs Punti Funzione COSMIC
| Scopo/vantaggio | Punti funzione COSMICA | Punti della storia |
|---|---|---|
| Buono per la stima dello sprint | SÌ | SÌ |
| Buono per il dimensionamento dell'applicazione | SÌ | NO |
| Il tempo dedicato al dimensionamento delle storie degli utenti migliora la qualità | SÌ | SÌ |
| Coerente tra i team | SÌ | NO |
| Coerente tra organizzazioni e settori | SÌ | NO |
| Adatto per contratti di sviluppo | SÌ | NO |
| Contratti di sviluppo con portata incerta. | SÌ | NO |
| Adatto per l'apprendimento organizzativo | SÌ | NO |
| Aiuta a ridurre i costi di sviluppo in outsourcing | SÌ | NO |
| Adatto per prevedere e riferire sulla qualità | SÌ | Un po' |
| Adatto per una stima anticipata delle dimensioni e dei costi | SÌ | Un po' |
| Buono per la stima del progetto | SÌ | Un po' |
| Buono per dimensionare il lavoro non funzionale | NO * | SÌ |
| Ottimo per il dimensionamento del portafoglio software e la pianificazione di alto livello | SÌ | NO |
| Il dimensionamento può essere automatizzato | SÌ | NO |
| Buono per il reporting a livello di consiglio (delle attività di sviluppo e manutenzione) | SÌ | NO |
| Utile per confrontare la produttività del team | SÌ | NO |
* Molti requisiti non funzionali possono effettivamente essere riarticolati come requisiti funzionali.
Il fattore più significativo nel determinare un progetto software è la dimensione del software da consegnare. Ci sono anche molti altri fattori significativi. Ma la dimensione è #1. Senza una valuta comune per le dimensioni del software, i progetti sono difficili da stimare, sono ancora più difficili da misurare e se non è possibile misurarli, sono molto difficili da gestire.
Incoerente
Le stime dei punti della storia sono specifiche per il team che svolge il lavoro. Uno story point è in realtà un indicatore dell'impegno stimato per svolgere un certo lavoro. In genere c'è solo una "sensazione" per le dimensioni. Man mano che i membri del team vanno e vengono, l'opinione sulla quantità di impegno necessaria per svolgere un certo lavoro può variare, quindi l'entità di un punto della storia può cambiare. Di conseguenza, le stime delle dimensioni in story point non hanno senso per i confronti con un altro team, per non parlare di un altro progetto, organizzazione o altro settore.
Prematuro
I team agili in genere stimano le dimensioni in story point solo poche settimane prima di svolgere il lavoro. Ciò rende davvero molto difficile il lavoro di pianificazione a lungo termine del project manager.
“Il fattore più importante in un progetto software è la dimensione del software. E il modo migliore per misurare le dimensioni del software sono i punti funzione COSMIC. “
Le organizzazioni devono migliorare
È praticamente impossibile nella maggior parte delle organizzazioni essere in grado di guardare avanti o indietro rispetto a un progetto e utilizzare i punti della storia per confrontare o apprendere le caratteristiche di un progetto rispetto a un altro. I punti della storia inibiscono l’apprendimento.
La metrica principale su un progetto software
Le preoccupazioni principali quando si gestisce un progetto software sono: dimensioni del software, impegno, tempo, qualità e rischio. Le organizzazioni necessitano di parametri coerenti per tutti questi aspetti. Se conosci le dimensioni, puoi determinare rapidamente le metriche appropriate per qualità, pianificazione e risorse. La dimensione è la metrica fondamentale. I punti storia confondono le dimensioni e l'impegno del software, quindi non possono essere misurati correttamente.
Le organizzazioni hanno bisogno di misure indiscutibili per valutare e apprendere.
Se si riesce a stimare in modo coerente la dimensione del software da fornire e si dispone di dati sulle prestazioni di progetti comparabili passati, è possibile determinare rapidamente l'impegno e la pianificazione stimati e quindi le risorse necessarie. Questo non può essere fatto con gli story point quando non è chiaro se misurano la dimensione o lo sforzo. Ciò che rende la gestione del progetto molto più semplice ed efficace è avere una serie di metriche indiscutibili con cui lavorare. Affidarsi solo agli story points inibisce l’apprendimento e il miglioramento organizzativo.
Gli Story Point non sono adatti allo sviluppo in outsourcing
Gli story point non trovano posto nei contratti di sviluppo in outsourcing. Ad esempio, non è possibile stipulare un contratto per fornire 100 story point, poiché non esiste una comprensione assoluta e coerente dell'entità di uno story point. Il risultato di ciò è che il cliente non ha visibilità del rapporto qualità-prezzo né alcun modo di controllarlo.
La qualità soffre
I contratti agili tendono ad essere caratterizzati da incertezza e mancanza di dettagli sui requisiti, prima di assumere un appaltatore di sviluppo. Di conseguenza, la maggior parte dei contratti per lo sviluppo di software sono essenzialmente tempo e materiali basato. In un contratto T&M è difficile negoziare un prezzo per la funzionalità con una determinata qualità a un determinato costo. Molti fornitori accetteranno di creare un team in grado di fornire qualsiasi funzionalità richiesta dal cliente. In molte circostanze riscontrate dall'autore, l'organizzazione di sviluppo ha anche il diritto di farsi pagare per lo sforzo di correggere i bug nel software che ha consegnato. Possono guadagnare tanto denaro risolvendo i propri bug quanto sviluppando la funzionalità in primo luogo. Per affrontare questo problema. proponiamo contratti basati su prezzo fisso fisso per punto funzione con vincoli di qualità basati sui difetti rilevati per punto funzione.
Gli Story Points possono gonfiare i costi
Su un contratto di sviluppo in outsourcing spesso assistiamo a ritardi e superamenti dei costi causati da un lavoro di scarsa qualità. Spesso i problemi di qualità sono causati dal cliente che ha fornito requisiti di qualità scadenti. Potrebbe non essere nell'interesse commerciale dell'organizzazione di sviluppo mettere in discussione la qualità dei requisiti o anche solo evidenziare i pericoli derivanti dalla continuazione. Indipendentemente da quale parte sia responsabile della creazione di lavoro extra, spesso è nell'interesse commerciale dell'organizzazione di sviluppo consentire che i problemi di qualità causino il ritardo e quindi essere pagati extra per eseguire il lavoro di riparazione. In che modo è colpa dei punti della storia, chiedi? I punti della storia perpetuano l'ambiguità e tale ambiguità porta a contratti T&M invece che a un contratto basato su un prezzo unitario fisso per la funzionalità fornita.
“Il solo utilizzo degli Story Point nei contratti di outsourcing perpetua una scarsa qualità e costi più elevati”.
STOP, c'è un modo migliore, ed è sempre stato qui.
Punti funzionali COSMIC: i migliori amici del responsabile dello sviluppo
Pochi gestori di software sono effettivamente consapevoli del fatto che esistono standard universali comprovati per misurare le dimensioni delle funzionalità del software. L’idea di misurare le dimensioni funzionali esiste da molto tempo. Il Function Point è il software equivalente alla misurazione del peso in chili.
L'edizione più aggiornata è la COSMIC Function Point (CFP). È la raffinatezza moderna di una tecnica collaudata. È gratuito (open source) e si basa sui principi fondamentali del software e quindi è universalmente applicabile.
Il processo di misurazione è chiamato dimensionamento funzionale ed è un modo per misurare la dimensione delle funzionalità del software utilizzando una metrica sempre uguale e quindi confrontabile tra team, progetti, organizzazioni e settori.
- Perché è meglio?
- Supera tutti i limiti dei punti della storia come menzionato sopra.
- È collaudato e maturo (uno standard ISO)
- Perché non ne ho sentito parlare prima?
- Insomma, non è andata di moda
- Fino ad ora, il lavoro di misurazione ha richiesto molto tempo.
- Dovrei usare il CFP così come gli story point?
- Sì, puoi continuare a utilizzare gli story point insieme al CFP.
- I punti della storia funzionano per me, dovrei cambiare?
- Dipende da chi intendi con "me". In alcuni team software interni (maturi e stabili), gli story point possono funzionare abbastanza bene per stimare le User Story e gli sprint, e ci sono pochi motivi per cambiare per quanto riguarda un singolo team. Ma, per tutte le ragioni sopra elencate, i punti deboli restano a livello organizzativo. Queste debolezze non verranno mai superate se continui a utilizzare solo gli story points.
“Il fattore più importante in un progetto software è la dimensione. E il modo migliore per misurare le dimensioni è utilizzare i punti funzione COSMIC”
Leggi di più per ulteriori prove dell'uso riuscito e elevata prevedibilità della CFP su progetti Agile
Conclusione e raccomandazione
Consigliamo a qualsiasi squadra che sta già utilizzando gli story point di continuare a farlo. Oltre a ciò, dovrebbero anche misurare il loro software in Punti Funzione Cosmica. Limitare l'uso di SP al lavoro all'interno del team di sviluppo. Quando si esaminano la stima, i parametri contrattuali, la capacità di sprint e la gestione del progetto, utilizzare solo CFP. Col tempo, potresti scoprire di non utilizzare più SP, concentrandoti invece sulla dimensione funzionale del software fornito.
Scopri di più sui Function Point COSMIC: tutta la documentazione completa del metodo COSMIC è disponibile per il download gratuito su www.cosmic-sizing.org. Ti consigliamo di iniziare da leggendo questa introduzione al dimensionamento COSMIC . Il metodo di dimensionamento si basa sui principi fondamentali dell'ingegneria del software ed è molto facile da apprendere.
Di Colin Hammond, CEO di ScopeMaster Ltd e Carlo Symons, Cofondatore di COSMIC
