Elementi essenziali per il dimensionamento del backlog

Esamina ciascuna User Story E il set

ScopeMaster fornisce automaticamente una stima delle dimensioni in base al testo della storia dell'utente.

il dimensionamento del backlog inizia con l'interpretazione funzionale di ciascuna user story

Perché il dimensionamento automatizzato con ScopeMaster è migliore del dimensionamento del team

ScopeMaster non solo fornisce una stima ragionevole delle dimensioni del backlog, ma può farlo senza sforzo, istantaneamente e dimensionando gli elementi del backlog mancanti!

Conoscere le dimensioni porta a processi decisionali gestionali più sofisticati e alla pianificazione dei progetti
Dimensionamento del backlog software automatizzato da ScopeMaster®
Dimensionamento e stima del backlog software sono normalmente uno spreco di tempo e un gioco. Tuttavia, stime affidabili sono essenziali per prendere decisioni di investimento valide e pianificare in modo efficace.

La stima delle dimensioni del backlog software (e successivamente dei costi e della pianificazione) è importante per consentire ai manager di comprendere quanto costerà e quanto tempo richiederà. Manager e dirigenti devono costantemente affrontare decisioni difficili sul lavoro del software. Nei progetti più grandi, i budget e i programmi vengono spesso superati, il che porta a notevoli sprechi e inefficienze. Manager è necessario conoscere il costo e la durata probabili sviluppare software in modo che possano pianificare di conseguenza. Ci si aspetta che prendano decisioni affidabili in merito alle priorità e all'allocazione del personale, ma spesso lo fanno senza una stima software affidabile del tempo e dell'impegno necessari.

La maggior parte dei professionisti del software ritiene che sia impossibile stimare il lavoro di sviluppo del software o che richieda molto tempo. Non è così.

Perché le stime degli sviluppatori sono inaffidabili?

Gli sviluppatori spesso hanno difficoltà con la stima. La stima utilizzando tecniche come story points o dimensionamento delle magliette, è in realtà solo un indicatore per indovinare ore o giorni di lavoro. Le squadre sosterranno il contrario, ma si tratta principalmente di offuscamento da promuovere. Quando gli sviluppatori forniscono stime per una parte di un lavoro, possono deliberatamente sottovalutare il lavoro, forse per “vincere” il lavoro e proteggere il proprio lavoro. Potrebbero anche sovrastimare per evitare di dover svolgere un lavoro che non vogliono fare.

L'uso improprio delle stime degli sviluppatori è prevalente

Una volta che gli sviluppatori hanno fornito a un manager una stima di una user story, di uno sprint di lavoro o anche di un intero arretrato, il manager potrebbe quindi continuare a utilizzare quella stima come obiettivo, misura di controllo o addirittura impegno, il tutto sono usi inadeguati della stima dello sforzo di base.

Sottovalutare è la natura umana

Gli sviluppatori quasi sempre sottovalutano il tempo e gli sforzi effettivamente necessari per consegnare il software. È nella natura umana farlo. Considerano solo i fattori che conoscono, eppure nel software ci sono spesso incognite che causano ritardi, tesi che raramente vengono prese in considerazione nella stima tecnica. Inoltre le proposte iniziali degli sviluppatori sono solitamente basse per “vincere il lavoro”.

Come stimare il backlog dei prodotti software in modo affidabile?

Decine di fattori possono influenzare il tempo e gli sforzi necessari per sviluppare software (come la complessità, l'ambiente di lavoro, il supporto esecutivo, l'esperienza tecnica, la volatilità dei requisiti). IL il singolo fattore più significativo nel determinare lo sforzo o il costo è la dimensione, nello specifico dimensione funzionale.

La dimensione funzionale del software è il fondamento della stima del backlog

Una volta che conosci il funzionale misurare, puoi ricavare rapidamente stime valide per altre dimensioni, ad esempio:

  • personale
  • tempo per svilupparsi
  • costi
  • test necessari per ottenere una qualità adeguata
  • e altro ancora

Cos'è la dimensione funzionale?

La dimensione funzionale deriva dalla misurazione della dimensione funzionale (FSM). Si tratta di una tecnica standardizzata matura e comprovata per il dimensionamento del software. È un pratica ingegneristica formale approvata dai gruppi di standardizzazione ISO. È agnostico rispetto alla tecnologia e alla metodologia di sviluppo. La dimensione funzionale è una misura universale che si applica a tutti i tipi di software. È considerato dal prospettiva degli utenti. È oggettivo, valido e coerente. Due persone che misurano la dimensione funzionale dovrebbero ottenere ogni volta lo stesso numero. L'unità di misura è il punto funzione, nello specifico il punto funzione COSMIC o CFP. La CFP può essere stimata o conteggiata (esattamente) solo a partire dai requisiti e dalle specifiche. La dimensione funzionale è indipendente dal linguaggio di codifica utilizzato per svilupparla. La FSM esiste da molti anni e ha dimostrato di essere la misura più affidabile delle dimensioni del software. FSM consente di stimare o misurare le dimensioni prima, durante e dopo la scrittura del codice.

Stima innovativa del Product Backlog

ScopeMaster è il primo e unico strumento per stimare in modo affidabile le dimensioni funzionali, direttamente e automaticamente da un arretrato di requisiti scritti. Non limitarti a crederci sulla parola però. Esperti e accademici di tutto il mondo concordano sul fatto che ScopeMaster® è uno strumento di dimensionamento automatizzato rivoluzionario: Convalida accademica di ScopeMaster come strumento di dimensionamento automatizzato.

Dai certezza al tuo lavoro software con la misurazione automatizzata delle dimensioni funzionali.

Per ulteriori informazioni sulla misurazione delle dimensioni funzionali COSMIC, visitare https://www.cosmic-sizing.org

Il bello di conoscere le dimensioni prima della codifica è che puoi allocare la giusta quantità di tempo e fondi per portare a termine il lavoro. Semplicemente conoscendo la dimensione, di solito puoi risparmiare 10% o più su un progetto software più grande, a volte anche di più.

Stima software automatizzata con ScopeMaster

Tre standard principali automatizzati:

ScopeMaster è stato concepito come uno strumento per automatizzare il lavoro d'ufficio volto a misurare la dimensione funzionale del software a partire dai requisiti. “Il motivo per cui ho deciso di scrivere uno strumento per farlo è perché, come project manager software, l’ho trovato dimensione funzionale è il singolo fattore più significativo di cui ho bisogno per gestire un progetto con successo.” Colin Hammond, Fondatore.

ScopeMaster interpreta l'intento funzionale della storia dell'utente o dei requisiti software, ed è quindi in grado di farlo automatizzare il dimensionamento funzionale, che può poi essere utilizzato per ulteriori scopi stima dello sviluppo del software.

Non solo ScopeMaster è molto più veloce della misurazione manuale (almeno 4 volte più veloce), ma costa sostanzialmente meno del dimensionamento manuale, i contatori certificati sono scarsi e ScopeMaster elimina gran parte del lavoro faticoso. ScopeMaster “legge” i requisiti, interpreta l'intento funzionale e quindi li dimensiona di conseguenza. Può stimare la dimensione a circa 3 CFP al secondo. Potresti dimensionare un insieme di requisiti di 1.000 CFP (circa $1m di software in outsourcing) in circa 2 o 3 minuti. Potresti quindi rivedere i risultati per a) correggere eventuali errori relativi ai requisiti e b) verificare la dimensione funzionale di ciascun requisito. Una volta verificata dall'analista, la stima diventa un conteggio/misurazione esatta, che può essere utilizzata anche per l'outsourcing a prezzo fisso del lavoro di sviluppo software.

Dimensionamento Funzionale COSMIC

Nel corso degli anni sono state create diverse varianti della metrica della dimensione funzionale. Solo cinque hanno ottenuto il riconoscimento ISO (COSMIC, IFPUG, Mark II, NESMA e FiSMA). IFPUG, Mark II, NESMA e FiSMA sono tutti simili in quanto derivano dal set di regole originale creato da Allan Albrecht presso IBM negli anni '80. IL Metodologia della dimensione funzionale COSMIC si è evoluto da metodologie precedenti, progettate specificatamente per affrontarne le carenze. I principali vantaggi che rendono la metodologia di dimensionamento COSMIC più rilevante per il software moderno sono:

  1. Si basa sui principi del software, trattando elegantemente gli strati software interconnessi e le architetture software.
  2. È possibile effettuare stime e misurazioni prima che tutti i requisiti siano noti, il che è particolarmente adatto allo sviluppo Agile.
  3. È stato automatizzato e quindi richiede un apprendimento trascurabile.

Gli story point sono prevalenti in tutti i progetti Agile e rappresentano una misura proxy dell'impegno specifica del team. Ogni squadra ha una comprensione comune dell'entità di un punto della storia, in genere è nell'ordine di poche ore di impegno, ma non esistono regole rigide. Gli Story Point non sono una valuta universale. Non sono uno standard e non possono essere utilizzati in modo affidabile per confrontare team o progetti. Gli story point sono un utile indicatore interno dello sforzo previsto, se non sono disponibili altri mezzi di stima. I Function Point, tuttavia, sono universali, standard e altamente applicabili allo sviluppo Agile tanto quanto a qualsiasi altra metodologia di sviluppo. Clicca qui per saperne di più sui vantaggi di CFP e Story Points

La dimensione è la pietra angolare della stima del software

Una volta che conosci la dimensione funzionale nei punti funzione COSMIC (CFP), puoi stabilire rapidamente altre metriche direttamente correlate alla dimensione, come costo, impegno e pianificazione. Una volta stabilita la dimensione in CFP, è possibile utilizzare i valori di conversione del settore che associano i punti funzione all'impegno, ai costi e alla pianificazione. Invece di utilizzare le conversioni di settore, puoi utilizzare i dati storici del tuo progetto per stabilire i tuoi benchmark di velocità.

Stima agile

Piuttosto che perdere tempo discutendo di punti della storia o giocando con le carte di Fibonacci. Secondo la nostra esperienza, la stima agile si ottiene meglio tramite il dimensionamento funzionale con COSMIC FP.

Cosa puoi stimare in base alle dimensioni?

  • Velocità (CFP medi erogati a settimana)
  • Programma (numero di settimane necessarie per la consegna)
  • Costo (costo totale per progettare, sviluppare, testare e consegnare)
  • Sforzo (sforzo necessario per progettare, sviluppare, testare e fornire)
  • Qualità (potenziali difetti per ciascun componente della consegna)

Quanto velocemente puoi ricavare le stime?

Manualmente, un analista competente può contare (misurare) i punti funzione a una velocità di circa 100-500 FP al giorno (circa $100k – $500k di software). Ciò dipende dalla qualità e dalla chiarezza dei requisiti e delle specifiche. La velocità dipende anche dall'esperienza e dall'abilità dell'analista. Con ScopeMaster puoi aspettarti di raggiungere queste regole circa 4 volte più velocemente.

Stima automatizzata in punti funzione COSMIC

Stima mentre scrivi le storie degli utenti

Utilizzando ScopeMaster Story Analyser per Jira, puoi stimare la dimensione funzionale delle tue storie senza nemmeno uscire da Jira. Il testo della tua storia utente viene analizzato dal potente motore linguistico di ScopeMaster per rilevare l'intento funzionale e la dimensione funzionale.

La dimensione non è l'unico fattore che determina i costi e la pianificazione del software, ma è quello più significativo.

Problemi con i punti della storia e le magliette

  • Incoerente
  • Giocabile
  • Non lineare

Gli story point sono un'opinione basata sul team sulla quantità di sforzo necessario per creare un software dal punto di vista di uno sviluppatore. I punti della storia sono essenzialmente un proxy per le stime dell'impegno, ad esempio un punto della storia potrebbe essere l'equivalente di 1 giorno di persona ideale. Sono altamente soggettivi e dipendono dalle opinioni del team. Variano da squadra a squadra e anche nel tempo all'interno della stessa squadra. La loro incoerenza e capacità di gioco li rendono poco pratici come metrica ingegneristica affidabile.

Per coloro che considerano la stima dannosa, non importante o semplicemente troppo difficile, consulta l'eccellente articolo di Steve Mconnell sul perché la stima è un'abilità importante e preziosa di cui hanno bisogno i project manager.