Stima punto Story - Basato su componenti

Question

Stima punto Story - Basato su componenti

#1 da (1 voti)

1

Ho letto che la stima del punto della storia non è intesa per legare effettivamente con il numero di ore, ma è usata per identificare la capacità relativa. Ho un'applicazione java che ha un livello adattatore, un livello di implementazione del servizio, un livello DAO e un livello di servizio connettore esterno. Se mi viene dato un requisito di alto livello, è una buona pratica una classificazione dei punti storia per ogni livello - ad esempio:

Adattatore: piccolo: 1 SP, medio 3 SP, grande: 5 SP, extra large: 8 SP Impl: piccolo: 3 SP, medio 5 SP, grande: 8 SP, extra large: 11 SP DAO: small: 1 SP, medium 3 SP, Large: 5 SP, Extra Large: 8 SP

È un buon modo di stima? O dovremmo sempre stimare guardando come applicazione intera per ogni cambiamento? Ad esempio, se ho 2 storie di utenti, dovrei stimare la dimensione della storia utente nel suo complesso, ad esempio 1 US prende 5 SP e altri richiede 13 SP? La rottura dei componenti ha senso per la stima del punto della storia?

requirements estimation user-story

posta Punter Vicky 12.10.2013 - 08:50

fonte

1 risposta

Leggi altre domande sui tag requirements estimation user-story

Il modo migliore per gestire un infograph dinamico con javascript? Il controllo di un record è dovuto in base al campo 'occuring'

score 1 · Answer 1

Nei metodi agili, ci sono solitamente due livelli in cui vengono effettuate le stime: il livello di un'intera User Story e il livello dei compiti necessari per realizzare una User Story.

Se stai valutando a livello User Story, dovresti stimare la User Story nel suo complesso, per due motivi:

Se si interrompe la storia in livelli / componenti, ciò implica che qualcuno (presumibilmente il proprietario del prodotto) ha già preso decisioni di progettazione su come implementare la storia. Ma questo non dovrebbe essere parte di una User Story. Una User story dà a chi ha bisogno di cosa e perché hanno bisogno di esso, ma il come è riservato al team di sviluppo questo deve realizzarlo Questa è una differenza molto importante con le formulazioni dei requisiti tradizionali che spesso tendono ad entrare nell'asimmetria.
Nella tua proposta, una "parte di storia" media nel livello dell'adattatore è 3 SP, ma nel livello di servizio è 5 SP. Questa differenza di dimensionamento tra gli strati causerà alla fine confusione. Il team dovrà tenere in mente tre o quattro riferimenti per quanto impegno corrisponde a dire 3 SP per tenere conto delle diverse scale utilizzate nei diversi livelli.

Usare scale diverse all'interno di una stima dovrebbe essere evitato il più possibile (direi, a tutti i costi), quindi anche quando il team sta valutando i singoli compiti della storia. Le unità utilizzate per la stima delle attività non devono corrispondere a quelle per la stima della storia (è possibile utilizzare anche le ore per la stima delle attività, perché un tipico compito dovrebbe essere tra 2 e 8 ore), ma all'interno di una stima si dovrebbero usare le stesse unità .

Supponiamo che siano state utilizzate le stime del punto di nodo per le singole attività, con le unità per livello come indicato nella domanda e che venga visualizzata un'attività che potrebbe essere implementata nell'adattatore o nei livelli di servizio. Solo sapere che è un compito di media complessità o che è un task di 5 SP non ti dice nulla, perché devi ancora sapere quale livello è stato previsto per implementarlo quando si fornisce il preventivo.