agile estimation techniques
Stime reali in un progetto Agile: una visione completa con esempi di stima Agile
È molto importante eseguire la stima agile a diversi livelli. Questo viene fatto per una corretta pianificazione, gestione e stima degli sforzi totali che utilizzeremo per implementare, testare e consegnare il prodotto desiderato ai clienti in termini di tempo entro le scadenze specificate.
Con la mancanza di stime in Agile Project, potrebbe non esserci una corretta pianificazione e gestione che potrebbe finire con la fornitura del prodotto indesiderato e quindi lasciare il cliente insoddisfatto.
Le stime dei punti della storia vengono eseguite in progetti Agile utilizzando diverse tecniche come Planning Poker, Bucket System, Affinity Mapping, ecc. Per questo scopo vengono utilizzati diversi modelli di stima a diversi livelli, come Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , Modello User Story ecc.
Cosa imparerai:
- introduzione
- Stime dei punti della storia in Agile
- Strumento consigliato
- Diverse tecniche di stima Agile
- Calcolo del budget in Agile
- Modelli di stima nel progetto di sviluppo agile
- Fasi della stima nel progetto Agile
- Conclusione
- Lettura consigliata
introduzione
Di seguito sono riportati i 3 livelli principali della stima agile.
# 1) Livello di progetto o proposta è quello che utilizza la Quick Function Point Analysis durante le fasi iniziali dello sviluppo del Progetto.
# 2) Livello di rilascio include l'assegnazione degli story point alle user story che possono aiutare a definire l'ordine delle user story in base alla priorità e può anche aiutare a decidere quali storie possono essere prese nella versione corrente e quali possono essere prese in seguito.
# 3) Livello di scatto è quello in cui le storie degli utenti vengono suddivise nelle attività e le ore stimate vengono assegnate alle attività in base alla loro complessità. Qui, definiamo anche la persona responsabile dell'attività insieme allo stato delle attività.
Queste informazioni possono essere utilizzate successivamente per calcolare il budget per il progetto Agile. Il calcolo del budget è fondamentale per assicurarsi che il progetto non superi il budget a causa delle attività pre e post iterazione o per altri motivi.
Stime dei punti della storia in Agile
Le stime dei punti della storia sono un'analisi comparativa per stimare approssimativamente gli elementi del backlog del prodotto con il relativo dimensionamento. I membri del team per la stima delle storie degli utenti includono: Product Owner, Scrum Master, Sviluppatori, Tester e Stakeholder.
Di seguito sono riportati alcuni passaggi per raggiungere la decisione finale del dimensionamento relativo:
# 1) Analizza tutte le storie degli utenti e identifica la storia di base o di riferimento. È importante per eseguire il dimensionamento relativo. Questa storia può essere scelta dall'attuale backlog del prodotto o da quello che abbiamo fatto in precedenza. Questa storia dovrebbe essere scelta come storia di riferimento previo accordo di tutti i membri.
#Due) Scegli un'altra storia dall'attuale Product Backlog ei membri del team sono liberi di discutere qualsiasi domanda o dubbio con il Product Owner, pur comprendendo i requisiti della storia. Il Product Owner è responsabile di chiarire tutte le loro domande e dubbi.
# 3) Fai un elenco delle cose a cui prestare attenzione durante l'implementazione della user story. Questi possono essere fatti scrivendo note nella sezione note dello strumento o aggiungendo punti elenco sulla scheda storia. Questo viene fatto principalmente dallo Scrum Master.
# 4) Di seguito sono riportate alcune domande comuni tra i partecipanti:
- Design: Qual è la conoscenza preliminare e obbligatoria che dovremmo avere prima di iniziare a lavorarci?
- Codifica: Quanta codifica è necessaria per implementare questa user story. Ci siamo imbattuti in una user story simile in precedenza?
- Test unitario: Sono necessari oggetti fittizi per eseguire i test di unità per questa storia utente?
- Test d'integrazione: Questa storia influisce anche sulle altre funzionalità dello stesso modulo e di altri moduli?
- Test di accettazione: Quali sono i punti da curare per consegnare il prodotto desiderato come desiderato dai Clienti?
- Competenza: Qualcuno dei partecipanti ha già scritto una storia simile ed è un esperto?
# 5) Esegui il dimensionamento relativo per la storia selezionata. Se richiede la stessa quantità di lavoro e impegno, assegnagli lo stesso no. di punti, come assegnato alla storia di riferimento. Se richiede uno sforzo maggiore, assegnagli un valore più alto. Se richiede meno sforzo, assegnagli un valore inferiore.
# 6) Raggiungi un consenso con tutti i partecipanti per finalizzare la dimensione relativa per la user story selezionata secondo la definizione di done.
come stampare un elemento di un array in java
# 7) Dopo aver eseguito il dimensionamento relativo di tutti gli elementi del product backlog, assicurarsi che se tutte le user story con lo stesso n. di punti assegnati a loro, richiedono lo stesso sforzo e le dimensioni per essere coerenti.
Strumento consigliato
# 1) Poker agile
Poker agile è un'app ben nota per Jira per la pianificazione e le stime rapide e convenienti per team remoti e co-localizzati.
Iniziare con Agile Poker è semplice e facile poiché è stato ispirato da tre metodologie di stima standard del settore: Planning Poker®, Wideband Delphi e Magic Estimation (noto anche come Silent Grouping, Affinity Estimation, Swimlanes Sizing o Relative Estimations).
=> Scarica lo strumento Agile Poker quiDiverse tecniche di stima Agile
Esistono molte tecniche per fare stime in un progetto Agile. I principi fondamentali per eseguire le stime includono la stima relativa, discussioni per ottenere maggiori informazioni sugli elementi di cui è necessario effettuare le stime e garantire l'impegno dell'intero team nei confronti dei compiti loro assegnati.
Esistono principalmente 7 tecniche di stima del progetto Agile:
# 1) Pianificazione del poker
- In questa tecnica di stima, tutte le persone che dovrebbero fare le stime, si siedono in cerchio per la sessione di Planning Poker.
- Ogni stimatore ha una serie di carte Planning Poker di valori: 0,1,2,3,5,8,13,20,40 e 100. Questi valori rappresentano i punti della storia o la misura in cui la squadra stima.
- All'inizio della sessione, il product owner o il cliente legge la user story, descrivendone tutte le caratteristiche e i requisiti.
- Dopo la lettura della storia, avvengono le discussioni tra gli estimatori e con il proprietario / cliente del prodotto. Gli estimatori possono porre domande o chiarire i propri dubbi con il proprietario del prodotto.
- Dopo le discussioni, a tutti gli estimatori viene chiesto di selezionare una carta per stimare una user story. Se tutti gli stimatori danno lo stesso valore, questa diventa la stima finale.
- Se i valori sono diversi, gli stimatori che danno i valori più alti e più bassi spiegano le loro opinioni e il motivo per cui hanno scelto questo valore, fino a quando non viene raggiunto un consenso.
- Una buona tecnica quando è piccolo no. degli articoli deve essere stimato in un piccolo team.
=> Ulteriore lettura dettagliata su Pianificazione della tecnica di stima del poker .
# 2) Taglie della maglietta
- Proprio come nel caso delle T-shirt, vediamo le taglie: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Qui viene seguito un approccio simile. Gli articoli sono stimati in taglie di magliette.
- Questa è una tecnica perfetta per fornire una stima approssimativa del grande arretrato di articoli.
- Utile quando è necessario eseguire una stima rapida e approssimativa. Successivamente queste dimensioni possono essere convertite in no secondo il requisito.
- Una dimensione relativa (principalmente Media) viene decisa dopo la discussione reciproca e l'accordo dei membri del team o degli stimatori. Quindi, i no vengono assegnati agli articoli in base alla dimensione relativa assegnata a Dimensione media.
- Svantaggio: Ciò che a qualcuno sembra L può sembrare XL per qualcuno.
- Tutti gli stimatori assegnano la propria dimensione agli articoli. Dopo le discussioni e la risoluzione delle discrepanze, si raggiunge un consenso per ottenere la stima finale.
# 3) Voto a punti
- Questo è fondamentalmente un metodo di classificazione per decidere l'ordine del Product Backlog dalle storie con priorità più alta a quelle con priorità più bassa. Questo viene fatto per selezionare le storie più importanti che dovrebbero essere portate avanti.
- Per iniziare, pubblica tutte le storie degli utenti insieme alla loro descrizione sul muro o sulla bacheca usando adesivi gialli o in un modo che li distingua per ricevere i voti.
- A tutte le parti interessate vengono assegnati da 4 a 5 punti (per lo più sotto forma di adesivi, penne o pennarelli possono essere utilizzati anche per creare punti).
- A tutti gli stakeholder viene chiesto di esprimere il proprio voto sulle user story che preferiscono.
- Il Product Owner ordina gli elementi del product backlog dal preferito (quello con il maggior numero di punti) al meno preferito (uno con il numero minimo di punti).
- Può essere il caso in cui pochi stakeholder non sono soddisfatti dell'ordine deciso. In questo caso, le storie degli utenti sono divise in 3 gruppi dopo le discussioni: priorità alta, priorità bassa e priorità media. Le storie degli utenti ad alta priorità vengono pubblicate sulla bacheca per ricevere i voti. Questo viene fatto fino a quando non viene raggiunto l'ordine finale con l'accordo di tutte le parti interessate.
# 4) Il sistema di benna
- È una buona tecnica quando un grande no. degli articoli sono da stimare con grandi n. dei partecipanti. È più veloce e più ragionevole di Planning Poker.
- Vengono creati diversi bucket con valori: 0,1,2,3,4,5,8,13,20,30,50,100, 200 che possono essere estesi se necessario. Questi secchi non sono altro che carte che rappresentano valori disposti in sequenza su un tavolo.
- Le storie devono essere collocate all'interno di queste dove lo stimatore le trova adatte. Tutti gli elementi da stimare sono scritti sulle carte.
- Scegli un oggetto a caso e mettilo nel secchio 8. Questo è usato solo come riferimento. Scegli un'altra storia a caso, discuti tutte le sue caratteristiche e requisiti con il gruppo e, previo consenso, inseriscila nel secchio appropriato. Allo stesso modo, il terzo articolo viene prelevato e posizionato in un secchio appropriato.
- La sequenza del bucket può anche essere modificata, nel caso in cui il gruppo ritenga che il primo elemento scelto, dovrebbe appartenere al bucket 1 anziché al bucket 8.
- Viene seguito l'approccio Divide and Conquer. Tutti gli elementi rimanenti vengono suddivisi tra tutti i partecipanti. Tutti i partecipanti possono posizionare l'elemento senza l'approvazione degli altri partecipanti.
- Gli articoli devono essere posizionati correttamente. Nessun articolo può essere posizionato tra i secchi.
- Se un partecipante non comprende l'elemento del backlog del prodotto o se gli altri partecipanti hanno terminato di posizionare le proprie User story, le User story possono essere trasferite agli altri partecipanti.
- Infine il controllo di Sanità viene eseguito da tutti i partecipanti. Se un partecipante trova un bucket sbagliato assegnato a un elemento, può portarlo a conoscenza degli altri partecipanti e discutere con loro. Questo viene fatto fino a quando non si raggiunge un consenso per l'intero portafoglio prodotti.
- Il facilitatore dovrebbe controllare che nessuno sposti gli oggetti a meno che non venga effettuato un controllo di integrità.
- Questo viene fatto anche per ottenere l'ordine di priorità degli elementi del backlog del prodotto.
# 5) Grande / Incerto / Piccolo
- Questa è una versione approssimativa ed è la semplificazione del sistema di benna in cui ci sono solo tre dimensioni: Grande, Piccola e Incerta.
- I partecipanti o stimatori sono invitati a collocare gli elementi in una delle categorie. Innanzitutto, le semplici storie degli utenti vengono scelte e collocate nelle categorie grandi e piccole. Quindi vengono ripresi gli elementi complessi.
- È una buona tecnica quando sono presenti elementi comparabili nel Product Backlog.
# 6) Mappatura delle affinità
- Una buona tecnica quando la squadra è piccola e no. degli elementi in arretrato è inferiore.
- Il primo passo è il dimensionamento relativo silenzioso: Su un muro, una carta con la scritta 'Più piccolo' è posizionata sul lato più a sinistra e la carta con la scritta 'Più grande' è posizionata sul lato più a destra. Il proprietario del prodotto fornisce un sottoinsieme di elementi a tutti i partecipanti. A tutti i partecipanti viene chiesto di dimensionare ogni articolo in relazione alle dimensioni sulle carte sul muro, considerando lo sforzo richiesto per implementarle. È la decisione in solitaria del partecipante senza alcuna discussione con gli altri membri del team. Il Product Owner o lo stakeholder è presente per chiarire i dubbi del partecipante. Gli elementi del Product Backlog che sono troppo ambigui per essere compresi dai membri del team per la stima vengono inseriti separatamente. Ci vogliono 5-20 minuti.
- Modifica del muro: I membri del team possono cambiare la posizione degli oggetti sul muro. Possono discutere i requisiti di progettazione e implementazione con gli altri membri del team. Questa attività può essere chiusa quando si verificano piccoli cambiamenti sul muro. Ci vogliono circa 20-60 minuti .
- Posizionamento degli articoli nelle posizioni corrette: Dopo le discussioni, il team colloca gli elementi del product backlog nelle loro posizioni relative e appropriate. Possiamo usare la taglia della maglietta, la serie di Fibonacci ecc. Qui per stimare relativamente la dimensione degli articoli.
- Sfida del proprietario del prodotto: Il Product Owner potrebbe riscontrare qualche discrepanza nelle stime fatte dal team e la necessità di discutere più caratteristiche o requisiti per un articolo con il team. Dopo le discussioni, vengono effettuate le stime finali.
- Esporta in Project Backlog Management Tool: Per assicurarti che le informazioni sulle stime finali non vadano perse, esportale in uno strumento di gestione del backlog del prodotto.
# 7) Metodo di ordinazione
- Una buona tecnica quando grande no. di articoli e piccolo n. di persone ci sono.
- Fornisce dimensioni relative accurate per gli elementi del backlog del prodotto.
- Viene preparata una scala che va dal basso all'alto. Tutti gli oggetti vengono posizionati casualmente su di esso. A ogni partecipante viene chiesto di spostare un elemento qualsiasi sulla bilancia, in una sola volta. Il movimento può essere uno su, uno giù o passare il turno a un altro membro.
- Questo continua fino a quando tutti i partecipanti sono soddisfatti e non vogliono spostare alcun elemento sulla bilancia.
- Questo fornisce anche l'ordine di priorità degli elementi del Product Backlog.
Calcolo del budget in Agile
Il calcolo dei budget gioca un ruolo importante nei progetti Agile. Questo viene fatto per assicurarci qual è il budget effettivo fornito, quale budget è richiesto e come divideremo il budget per i diversi elementi del backlog di prodotto.
Utilizza i dati raccolti dai progetti precedenti e utilizza la formula matematica per ottenere il budget stimato per il progetto corrente.
Di seguito la sequenza dei passaggi, per calcolare il budget in un progetto Agile:
# 1) Elenca tutti i requisiti del progetto e fai il stime per loro che utilizzano Planning Poker, Bucket System, serie Fibonacci ecc. Tutti i membri del team dovrebbero concordare le stime fatte per i requisiti elencati dopo una chiara analisi e comprensione delle storie degli utenti. Le stime vengono effettuate in base alle funzionalità da implementare in una user story.
#Due) Determina la durata delle iterazioni chiamate Sprint e gli elementi del backlog di prodotto ad essa assegnati. Di solito dura da 2 a 3 settimane. Le user story vengono selezionate in una sequenza che inizia con la user story con la massima priorità, passando alla user story con la priorità minore e con la user story con la priorità minore alla fine. Questo aiuta a decidere quali storie degli utenti devono essere raccolte nel primo Sprint e quali storie possono essere riprese in seguito.
# 3) Preparare un grafico bruciato per fornire un quadro chiaro di quanto lavoro è rimasto da fare rispetto a quanto tempo è rimasto per l'implementazione. Fondamentalmente fornisce il tasso di progresso di una squadra agile. Fornisce un'immagine chiara di come si sta comportando la squadra e di come dovrebbe comportarsi.
Il progresso del team viene misurato in termini di attività completate, sforzo rimanente, burndown ideale e attività rimanenti come mostrato di seguito:
# 4) Aggiungi costi aggiuntivi come acquisto di apparecchiature, strumenti, supporto dell'infrastruttura, acquisizione di licenze per gli strumenti software da utilizzare, strumenti di gestione dei progetti, installazione e aggiornamenti di antivirus.
# 5) Aggiungi budget pre e post iterazione. Tutti i membri agili dovrebbero essere interfunzionali ma ci sono dei limiti. Qualsiasi cosa fatta da un membro del team al di fuori della sua esperienza è considerata come lavoro di pre-iterazione o lavoro di post-iterazione. Questi lavori di pre e post iterazione richiedono un budget aggiuntivo per l'implementazione.
# 6) Tenere d'occhio i rischi nascosti. I rischi nel progetto Agile includono: rischio che il progetto vada oltre il budget, assenza di membri del team, i membri non hanno una conoscenza chiara o completa, i membri non hanno le competenze richieste, le scadenze sono state superate, ecc.
Modelli di stima nel progetto di sviluppo agile
Esistono molti modelli di stima preparati a diversi livelli nel progetto di sviluppo Agile. L'unico scopo è quello di indicare chiaramente le stime necessarie per implementare un requisito o un elemento e monitorarne lo stato di avanzamento.
I modelli principali sono i seguenti:
1) Modello di piano di progetto Agile:
Offre una visione di alto livello di quanto tempo è necessario per fornire le caratteristiche dei requisiti e qual è il loro stato. Menziona anche la persona responsabile di un compito specifico.
(Nota: fare clic su qualsiasi immagine per ingrandirla)
2) Modello di piano di rilascio agile:
Fornisce i dettagli di rilascio delle attività corrispondenti ai requisiti, insieme al loro stato e allo Sprint in cui devono essere eseguite.
3) Modello Agile Product Backlog:
Descrive il backlog completo del prodotto definito per il progetto. Fornisce dettagli sulle attività degli Sprint insieme a stato, priorità, punti della storia e se sono assegnati a uno Sprint o se ci sono attività aggiuntive come difetti ecc.
4) Modello Agile Sprint Backlog:
Fornisce una descrizione delle storie degli utenti menzionate nel backlog di un particolare Sprint. Fornisce i punti storia totali assegnati a una storia utente e il modo in cui questi sono suddivisi in attività diverse. Fornisce inoltre lo stato delle attività corrispondenti e qual è il lavoro svolto quotidianamente per le attività corrispondenti.
come aggiungere valori a un array java
5) Modello del piano di test Agile:
Suddividi l'intero scenario di test in sotto-scenari. Fornisce i dettagli dei sotto-scenari come la data di implementazione, il risultato previsto, il risultato effettivo, lo stato ecc.
Inoltre menziona il nome del progetto, il browser compatibile, la versione dell'applicazione sotto test, l'ID del test case per uno scenario selezionato, scritto da, testato da, descrizione, ecc.
6) Modello di User Story Agile:
Fornisce dettagli specifici per l'analisi della user story come Quali sono i ruoli richiesti per testare una funzionalità specifica, qual è il prerequisito (configurazione dell'ambiente e collegamenti abilitati) e qual è il risultato atteso?
7) Modello di mappa stradale agile:
Dà una direzione al progetto in azienda, a breve e lungo termine. Aiuta a definire le aspettative all'interno dell'azienda. E la panoramica di dove sta andando il progetto.
Fasi della stima nel progetto Agile
In un progetto Agile, le stime vengono effettuate a 3 livelli come indicato di seguito:
- Livello progetto / proposta: La dimensione funzionale totale dell'intera applicazione viene stimata utilizzando il metodo QFPA (Quick Function Point Analysis) quando sono disponibili solo requisiti di alto livello.
- Livello di rilascio: I punti della storia vengono assegnati alle storie degli utenti che aiutano a determinare il n. di rilasci previsti all'interno di un progetto e il n. di user story da prendere in un rilascio e sprint.
- Livello Sprint: Le ore stimate vengono assegnate alle attività delle storie utente all'interno di uno sprint. Questo viene fatto per garantire l'impegno dello sviluppo per la fornitura di storie utente con uno sprint.
S1, S2, S3, S4, S5, S6 sono sprint.
# 1) Stima a livello di proposta o progetto
È una stima di alto livello per il progetto. Si concentra sul numero totale di requisiti nella voce del Product Backlog. I punti funzione vengono utilizzati per stimare la dimensione del software / progetto prima di documentare una descrizione dettagliata dei requisiti funzionali.
I punti funzione sono il modo universalmente accettato per calcolare le dimensioni del software. Si concentra sulle funzionalità trovate nei progetti software. Un punto funzione è una metrica che converte i requisiti o le storie degli utenti in un numero.
Durante le fasi iniziali del progetto, si consiglia di adottare il metodo QFPA (Quick Function Point Analysis).
Il metodo Quick Function Point Analysis è un approccio unico per la stima del FP quando sono disponibili solo requisiti di alto livello.
Come calcolare la dimensione funzionale totale?
- Comprendi tutte le funzionalità di un'applicazione con l'aiuto di esperti di dominio.
- Identifica ed elenca tutte le possibili funzionalità di un'applicazione.
- Le funzioni di memorizzazione dei dati sono classificate in File logici interni (dati memorizzati internamente all'interno dell'applicazione) e File di interfaccia esterna (dati utilizzati solo a scopo di riferimento).
- Le funzioni di transazione sono classificate in Input esterni (dati provenienti da fonti esterne all'applicazione), Output esterni (i dati derivati vanno dall'applicazione all'esterno) e Richieste esterne (dati recuperati da uno o più input esterni e output esterni).
- Calcola la dimensione del FP per ciascuna funzione calcolandone la complessità media.
- Sommare la dimensione FP di tutte le funzioni, per ottenere la dimensione funzionale totale dell'applicazione.
- Almeno due persone con esperienza nell'analisi FP, dovrebbero calcolare in modo indipendente, abbinare i risultati e risolvere le differenze.
Esempio di stima a livello di progetto:
Di seguito è riportato l'elenco dei requisiti per un progetto, come nel Product Backlog:
- Un utente dovrebbe essere in grado di accedere al sito Web fornendo il nome utente e la password.
- Dopo aver effettuato l'accesso con successo, un utente dovrebbe essere portato alla pagina principale con i riquadri destro e sinistro definiti.
- Un utente dovrebbe avere un'opzione per disconnettersi dall'applicazione.
- Un utente valido ha la possibilità di modificare la password fornendo le credenziali correnti.
Il team utilizza una stima rapida del FP per stimare la dimensione del progetto.
Di seguito è riportata l'analisi:
- La funzione di archiviazione dei dati qui sta memorizzando le credenziali utente per accedere e modificare la password.
- Poiché le credenziali sono archiviate entro i limiti dell'applicazione, vengono archiviate in ILF (file logici interni).
- Le funzioni di transazione includono:
- Login utente e visualizzazione della pagina principale.
- Logout dell'utente e visualizzazione della schermata di logout.
- Possibilità di cambiare la password.
Di seguito sono riportati i passaggi eseguiti per stimare le dimensioni del progetto utilizzando Quick Function Point Analysis:
PASSO # 1: elenca tutte le funzioni dati
Funzione dati | genere | UFP | |||||
---|---|---|---|---|---|---|---|
US-02 | TAS-07 | Test di accettazione da parte del cliente interno | Test di accettazione | Team QA in loco | 8 | Non iniziato | 6 |
Informazioni sulle credenziali dell'utente | ILF | 10 |
UFP (Unadjusted Function Point) è tratto dalla tabella Caper Jones.
PASSO # 2: elenca tutte le funzioni di transazione
Funzione di transazione | genere | UFP |
---|---|---|
Accedi e visualizza la pagina principale | EQ | 4 |
Logout e visualizzazione della schermata di logout | EQ | 4 |
Cambiare la password | NO | 4 |
UFP (Unadjusted Function Point) è tratto dalla tabella Caper Jones.
FASE # 3: derivare la dimensione stimata del progetto in punti funzione
UFP = Dati FP + Transazione FP
UFP = 10 + 12 = 22 UFP
FP = UFP * VFP = 22 * 1 = 22 FP (supponendo VFP (Fattore di regolazione del valore = 1)
Produttività = 16 FP / mese (standard normale)
Sforzo = FP / Produttività = 22/16 persone al mese = 1,37 persona al mese
# 2) Stima del livello di rilascio
Le stime del livello di rilascio vengono eseguite durante la pianificazione del rilascio. È l'attività successiva dopo la stima a livello di progetto. I requisiti prioritari sono presi dal Product Backlog che è sotto forma di User Story.
Le storie degli utenti sono stimate in termini di story point durante la pianificazione del rilascio che si concentra sulla stima delle dimensioni del software da fornire per quella versione. In questo modo, viene pianificato il numero di uscite e il numero totale di story point in ogni versione.
Un punto della storia rappresenta fondamentalmente lo sforzo relativo richiesto per implementare una caratteristica o la funzionalità, rispetto alle altre caratteristiche. È fondamentalmente per dimensionare gli elementi del Product Backlog.
La stima del punto della storia viene effettuata sulla base di:
- La complessità della funzionalità da implementare.
- Esperienza e capacità tecniche di tutti i membri.
S1, S2, S3, S4, S5 sono sprint.
Passaggi per l'assegnazione di story point a una user story:
- Tutti i membri del team si riuniscono attorno a un tavolo esaminando le user story presenti nello Sprint Backlog.
- Viene deciso il significato di un punto della storia e lo sforzo corrispondente.
- Uno dei membri del team legge una user story e poi chiede ai membri del team di assegnare i relativi story point.
- Se c'è una differenza significativa tra gli story point assegnati dai membri del team, allora forniscono una spiegazione per gli story point che hanno assegnato, raggiungendo così un consenso alla fine.
- Il processo viene ripetuto 3-4 volte fino a quando non vi è alcuna differenza sostanziale tra le stime fornite dai membri del team.
- Il dimensionamento delle storie aiuta a determinare quante storie saranno prese durante uno sprint e un rilascio.
Esempio di stima del livello di rilascio:
Ciò comporta la creazione di un elenco prioritario di User Story chiamato Product Backlog. Il Product Owner crea il Product Backlog e fornisce valore aziendale per ciascuno degli elementi elencati in esso.
ID storia utente | Storia dell'utente | Criteri di accettazione |
---|---|---|
US-01 | Come utente, desidero avere una schermata di accesso in cui posso accedere all'applicazione utilizzando le mie credenziali: nome utente e password | • Un utente valido dovrebbe essere in grado di vedere la schermata di accesso e fornire le credenziali. • Dopo l'accesso, è necessario verificare l'autenticità delle credenziali dell'utente. |
US-02 | Come utente, dopo aver effettuato correttamente l'accesso, voglio vedere la pagina principale con intestazione, riquadri sinistro, destro e opzione di disconnessione. | • Un utente valido dovrebbe essere in grado di vedere la schermata Home dopo aver effettuato correttamente l'accesso. • L'utente dovrebbe essere in grado di vedere l'intestazione, i riquadri sinistro e destro insieme all'opzione di disconnessione. |
US-03 | Come utente, dovrei essere in grado di disconnettermi con successo facendo clic sull'opzione di disconnessione e dopo il logout, dovrei vedere la schermata di logout. | • Nella pagina principale, l'utente dovrebbe essere in grado di fare clic sul pulsante 'logout'. • L'utente dovrebbe essere disconnesso con successo facendo clic su 'logout'. • L'utente dovrebbe vedere la schermata di logout dopo il logout. • L'utente dovrebbe essere in grado di accedere nuovamente dopo il logout. |
Possiamo utilizzare i seguenti metodi per le stime dei punti della storia:
- Dimensionamento numerico: Da 1 a 10
- Dimensioni della maglietta: Ogni requisito è classificato come Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
- Serie Fibonacci: Stima effettuata tramite la sequenza di Fibonacci (1,2,3,5,8,13,21,34,….)
Stima delle storie degli utenti di cui sopra attraverso la sequenza di Fibonacci:
ID USA | Punti della storia stimati |
---|---|
US-01 | 8 |
US-02 | 3 |
US-03 | 4 |
# 3) Stima del livello di sprint
Le stime del livello di Sprint vengono effettuate durante lo Sprint Planning. Gli elementi del backlog del prodotto con la priorità più alta vengono presi e suddivisi in diverse attività come dettagli, progettazione, analisi, sviluppo, creazione di casi di test, esecuzione di casi di test, test di accettazione degli utenti ecc.
Le attività sono stimate in termini di ore stimate, ovvero il tempo necessario per completare tale attività per una corrispondente user story. L'approccio bottom-up viene utilizzato per le stime delle attività in cui i requisiti aziendali sono suddivisi in attività di basso livello e ad ogni attività vengono assegnate ore stimate.
Lo scopo delle stime è sapere quante storie utente il team di sviluppo può impegnare in uno Sprint. Lo sviluppo deve essere a proprio agio con l'impegno e i Product Owner devono essere sicuri che il team manterrà l'impegno.
S tep per l'assegnazione delle ore stimate alle attività:
- I membri del team raccolgono le user story, quindi viene chiesto loro di stimare lo sforzo effettivo, in termini di ore o giorni, per le attività corrispondenti alla user story.
- Se c'è un disaccordo in queste stime tra i membri del team, ne discutono e giungono a un consenso.
- Se un'attività dura più di sei ore, viene suddivisa in attività più piccole.
- Se sono presenti due o più attività con ore stimate inferiori a due, vengono combinate per formare una nuova attività.
Esempio per la stima del livello di sprint:
Ci sono due parti dello Sprint Planning meeting:
- Prima parte: L'obiettivo è chiarire i requisiti per le User Story, selezionate dal Product Backlog.
- Seconda parte: L'attenzione si concentra sulla suddivisione dei requisiti in attività e sulla stima delle ore necessarie per completarle. Dovrebbero essere incluse tutte le attività necessarie per rendere consegnabile l'elemento del Product Backlog. I compiti dovrebbero essere piccoli. Idealmente, lo sforzo di un'attività non dovrebbe essere superiore a sei ore.
ID USA | ID attività | Descrizione del compito | Attività attività | Assegnato a | Priorità (da 1 = bassa a 9 = massima) | Stato | Ore di lavoro stimate |
---|---|---|---|---|---|---|---|
US-01 | TAS-01 | Progettazione della pagina di accesso | Sistema di design | Amit | 9 | Completato | 3 |
US-01 | TAS-02 | Piano di test unitario e piano di test di sistema | Piano di test del sistema | Offerta | 8 | Completato | 4 |
US-01 | TAS-03 | Sviluppa la pagina di accesso | Costruire | Team di sviluppo | 7 | Completato | 5 |
US-01 | TAS-04 | Convalida utente della pagina di accesso | Costruire | Team di sviluppo | 6 | In corso | 6 |
US-02 | TAS-05 | Scenari di successo e fallimento del test di sistema della pagina di accesso | Test di sistema | Team QA Offshore | 5 | Non iniziato | 4 |
US-02 | TAS-06 | Test di integrazione della pagina di accesso | Test d'integrazione | Team QA Offshore | 4 | Non iniziato | 3 |
Conclusione
Le stime nel progetto Agile svolgono un ruolo importante per garantire una corretta direzione, pianificazione e gestione. Fornisce passaggi su come intraprendere il progetto in futuro.
Le tecniche per stimare i punti della storia come Planning poker, Bucket System ecc. Fanno uso di carte o punti con valori o numeri stampati su di essi e quindi assegnano questi numeri. alle storie degli utenti per la stima delle dimensioni relative.
L'unico scopo è impostare gli articoli in un ordine di priorità dalla priorità massima alla priorità minima. Le dimensioni relative stimate per gli elementi del backlog di prodotto aiutano a stimare o calcolare il budget richiesto per il progetto.
Spero che tu possa avere una visione approfondita delle stime dei progetti Agile. Sentiti libero di esprimere i tuoi pensieri su questo tutorial nella sezione commenti qui sotto.
Lettura consigliata
- Come rendere facile il processo di stima agile con Planning Poker
- Agile vs Waterfall: qual è la migliore metodologia per il tuo progetto?
- Tecniche di stima del test del software (Guida completa alla stima dello sforzo del test)
- Esercitazione VersionOne: Guida allo strumento di gestione dei progetti agile all-in-one
- Tutorial Jira Portfolio: plug-in Agile Project Portfolio Management per JIRA (recensione)
- I 10 migliori strumenti di gestione dei progetti agili nel 2021
- Base per un viaggio agile di successo: come scegliere il metodo, gli strumenti e le tecniche giusti
- 4 passaggi verso lo sviluppo della mentalità di test agile per una transizione di successo al processo agile