tutti oggi parleremo di
campionamento casuale ma prima di tutto
come se dovessi ricordarti di impegnarti e
varia e valuta questa decisione e così via
qual è qual è il qual è lo scopo
di parlare di progetti di previsione
dimensione del progetto, quindi quando iniziamo il software
sviluppo almeno nella mia esperienza
le due domande che sento tutte
il tempo è quanto tempo e quanto tempo
ci vorrà e quanto costerà
noi per consegnare un pezzo di software e in
Per essere in grado di rispondere a quelli
domande abbiamo bisogno di sapere quanto
il software sarà disponibile quando
dobbiamo avere un modo per quantificarlo
quanto e in genere ciò che chiamiamo
è come ridimensionare così dimensionamento in questo
la presentazione in questo contesto è come
per noi essere in grado di quantificare il
dimensione del progetto un pezzo di consegna
e non concentrare lo sforzo necessario per
offrendo così questi sono due diversi
cosa perché le cose perché di solito
quando diciamo ridimensionamento di solito pensiamo che lo sia
a è su quanto tempo ha fatto bene
alcuni sfortunati direi e e
è quello che voglio sottolineare su questo
la dimensione stima la probabile dimensione di
pezzo di software durante lo sforzo
la stima stima lo sforzo necessario
per costruirlo parlerà
dimensionando qui in agile in un gel noi abbiamo
di solito usa t-shirt dimensionamento e storia
punta O’Doyle inizialmente indietro nel
secolo precedente quando
hanno iniziato con lo sviluppo del software
stavano usando linee di codice scritte
e poi è stata l’analisi del punto di funzione
che in realtà ce l’ha fatta
codificato in diversi standard ISO ma
di nuovo in agile stiamo usando le t-shirt
il punto della trama dell’inchiostro è un bacio troppo piccolo
è molto facile iniziare con come
soprattutto per le squadre immature
cosa con con cadetti dimensionamento t-shirt
non è additivo come prontamente additivo
possiamo aggiungerlo sostituendo le dimensioni
con i numeri ma in breve è
difficile dire che il nostro progetto è grande
come due M’s 3 e qualcosa di simile
questo è il motivo per cui la maggior parte delle volte
le persone che stiamo usando queste persone sono
usando punti storia e storia
i punti qui sono presentati dal mio cono per
istanza afferma che i punti della storia sono
riguardo allo sforzo per il tempo sul nostro nuovo
in questa presentazione useremo
come i sospiri nella storia, indica solo una tomba
tomba in complessità in alcun modo alcuni
complessità giusta ma non riguardo al cavallo
quindi quando dico punti storia vuol dire
dimensione relativa e sforzo non relativo
ok, questo è solo nel contesto, anche se
Conosco persone che lo sostengono in realtà
la mia definizione di coni non è corretta in
tutto e ma è dipende dall’accensione
la squadra così per noi piace perché
il software credo sia diverso da
stima dei guasti del software quando parlo
dimensioni e punti storia significherà di più
o meno complessità nelle persone con vincoli di reddito
ciò che le persone stanno facendo i loro parenti di dimensionamento
contando solo il numero di storie
per esempio alcune persone li usano
conta il numero di compiti ma in generale
qualunque cosa contiamo è il modo in cui il
il modo in cui dovrebbe essere fatto è il
come se dovessimo identificare tutti come noi
avere un prodotto o un pezzo di software
che dobbiamo consegnare dobbiamo rompere
giù in epopee o in pezzi più grandi e
allora dobbiamo abbattere ogni epoca
e il ragazzo della storia sono state storie e poi
dobbiamo analizzare ciascuna di quelle storie
in punti storia e poi riassumiamo e
finiamo con la dimensione totale del
progetto che richiede tempo ma non
solo il tempo che consuma è davvero la maggior parte di
il tempo non ha senso perché
i requisiti cambiano il contesto cambiano
e leggerà che non funzionerà il
sforzo giusto per analizzare un gruppo di
incertezze giuste e soprattutto quando
dobbiamo fare un livello di portafoglio
decisioni ad esempio a quali progetti
lavorare su accettare di impegnarsi ao a
fare quotazioni ai nostri clienti come
spendendo un tale sforzo sono le persone
non farlo letteralmente ed è per questo che io
stava cercando un modo per accelerare questo
l’attività di dimensionamento e ho avuto grazie a Dio I.
trovato come una tecnica da cui proviene
originato da estranei orticoli
non è sicuro del perché si sta muovendo, ma io sono io
devo spostarlo indietro per tutto il tempo
scorre così questo signore è il codice
Red Raymond Jason e negli anni ’50 e
In effetti negli anni ’50 ha stabilito un metodo
per
una tecnica efficace per
stimare il numero totale di frutti
trovato nel baldacchino di un albero mentre
contando per selezionare parte della chioma così
è ancora un metodo in essere
usare oggi in orticoltura anche se loro
non usarlo per alberi di arancio come
originariamente lo usano per lo più in
stimare la biomassa totale degli alberi
incluso come tutto non solo il
frutta ma è ancora in gran parte utilizzata
in Europa direi come lo sono le persone
interessato alla biomassa o qualcosa di simile
ma in ogni caso è molto utile è un problema
è un multistadio uguale
campionamento probabilistico quale vorrei
preferire nel contesto di questo
presentazione non mi concentrerò sul tappeto
Mi concentrerò sulle applicazioni del tappeto
sarai in grado di leggere se lo sei
interessato al giorno è un articolo in se
puoi mostrarti 2 lo mostrerò a
la fine e tutto il tappeto è lì giusto
quindi qui concentrati solo sulle applicazioni
non sono sicuro di cosa sia la maggior parte del tempo
la gente non gli piace Matt comunque così tanto
qual è l’idea quindi l’idea è che noi
presentiamo un backlog di prodotto come a
sistema di ramificazione quindi questo è un a
prodotto fittizio quindi abbiamo un po ‘di bici
blocca in cui l’abbiamo suddiviso
tre epoche a B e C e a PK ne ha due
storie che un maiale abbia altre due storie
un folletto ecco un CL ecco altri tre
la storia quindi è un prodotto fittizio
arretrato ed è una ramificazione
struttura e perché è una ramificazione
struttura possiamo effettivamente applicare il nostro
birre a questa struttura questo è il tappeto
si chiama stimatore di Horvitz Thompson
e funziona davvero funziona
calcolando la selezione incondizionata
probabilità per quattro
Termina sparare terminare che significa
che se iniziamo dal se iniziamo
dal tronco che nel nostro caso è
arretrato di prodotti e selezioniamo solo una parte
all’interno della struttura ramificata
dentro l’ albero e ne calcoliamo alcuni
probabilità per un tiro terminato
dove si trovano i frutti che è insomma
giusto ed è come sembra è così noi
avere questo travestimento di una struttura che
abbiamo il prodotto è il tronco e
poi scelgono, diciamo, sono i nostri
rami e poi i tiri terminali
sono dove sono le storie degli utenti e il
i frutti nel nostro caso potrebbero essere punti storia
Compiti qualunque cosa tu pensi di averne
che cosa fa in realtà è a
espande la dimensione della storia x il
dimensione delle epoche per scoprirlo
attraverso la dimensione totale di questo rettangolo
ma di nuovo non concentriamoci sul tappeto
qui ciò che è importante in questo era il
Jenner la domanda principale quando effettivamente
ha iniziato a giocare con i dati usando l’auto
base perché rbs funziona per il dimensionamento del software
progetti di sviluppo quindi questa domanda
si alza perché quando lo applicano
orticoltura stimano qualcosa
che è lì giusto vai ad un albero
e il numero di frutti sull’albero in
il baldacchino dell’albero ha un qui è un
valore oggettivo in astratto sottratto
dal suo valore oggettivo di interpretazione
numero bene ci sarà la contabilità
errore giusto se contiamo tutto il frutto
ma più o meno è lo stesso numero
giusto quando applichiamo le nostre api al nostro
arretrato prodotto non c’è niente lì
proprio non c’è niente
questa dimensione è chiamata per il proxy
tutte le funzionalità e capacità
che alla fine consegneremo
qualche punto futuro vedo il
difficoltà qui su come applicare così così
la domanda è da che universo noi
stiamo campionando non c’è niente lì
giusto e poi quando poi lo applico
come ho usato i dati reali e lo dimostrano
in realtà è applicabile ed e
ecco la mia mia spiegazione giusta così
assumere il presupposto dietro il
l’assunzione dietro di te pensa alle nostre birre
per lo sviluppo del software è che il
la dimensione del progetto dipende dal contesto in
il contesto è un concetto molto ampio ma
include il cliente le persone
lo sviluppo del prodotto nel
metodologia che useranno quando
abbattere il prodotto in I pick
storie qualunque cosa facciano e se c’è
una tale metodologia e la applicano
coerentemente e la metodologia stessa
è di nuovo coesivo che è molto
importante è coeso quindi in qualche modo e
siamo abituati a vedere i dati più tardi
in qualche modo siamo in grado di trovare qualcosa
tangibile nel futuro perché le persone
stanno applicando coerentemente un coeso
metodologia per abbattere un’idea
in pezzi quindi questo è il
difficoltà qui se hai solo un’idea
e non hai dati per dimostrarlo correttamente
non è niente, voglio dire, è solo
una finzione e te ne mostrerò un po ‘
le applicazioni quindi le più importanti
applicazione non sicura di quello che sta facendo
questa ma l’applicazione più importante
almeno quelli che quello che io
trovarlo più nel più importante è farlo
per verificare se il nostro team sta applicando il
metodologia coerente quindi se seguiamo
questa idea che stiamo effettivamente controllando
un’applicazione di una metodologia nel
la metodologia non importa quale sia il
la metodologia potrebbe essere
progettando il poker potrebbe essere un comportamento
sviluppo guidato potrebbe essere descritto
sviluppo guidato potrebbe essere pari
probabilmente l’analisi del punto di funzione è corretta
se c’è una metodologia e vedi
con i dati che possiamo effettivamente richiedere e
controlla se le metodologie erano state
applicato coerentemente così il primo
l’applicazione è che se ne abbiamo
dati storici per il nostro team o team
con le taglie diciamo che stanno dimensionando
ogni sprint e vogliamo
controlla se i membri del team sono effettivamente
non generando numeri casuali per dell
per le dimensioni ma stanno facendo qualcosa
possiamo pensare e dimensionare correttamente
usa la nostra BS per verificare che possiamo usare il nostro
birre per vedere l’effetto di un allenatore per
istanza se noi se noi assumiamo un allenatore
per insegnare alla nostra squadra in un poker di pianificazione
possiamo confrontare prima e dopo perché
stiamo confrontando stiamo campionando
da un’applicazione di metodologia
qui dentro potrei entrare in qualcosa come a
un po ‘come una fiaba ma vedrai il
i dati in seguito, quindi questo è molto
applicazione importante e cosa ho fatto
l’anno scorso ho chiesto come una mischia frenetica
fare la mischia è uno strumento per gestire la mischia
progetto
progetto incumbent con la maggior parte scrum
progetti Cranbourne progetto in questi giorni
e ho chiesto loro di fornirmi un po ‘
dati casuali così bene che ne hanno in abbondanza
ci sono un sacco di squadre in abbondanza
progetti e loro sono stati in grado di
raggiungere un accordo con alcuni membri del team
in modo che possiamo usare i dati a destra di
Certo che è sotto il mio diritto anonimo
ma così abbiamo effettivamente ottenuto 13 reali
progetti da 13 squadre diverse e io sono
non sono sicuro di quello che stanno facendo davvero
non so cosa stanno facendo, ma cosa
è comune per questo progetto è così vecchio
tutti i progetti hanno hanno epico
interruzioni di attività della storia che hanno
storia di successo e loro loro
sono squadre stabili quindi lavorano a lungo
molto tempo insieme e loro hanno un
mischia attiva per allenatore o supervisore
questo è molto importante perché ricorda
stiamo discutendo qui l’applicazione di a
metodologia di dimensionamento giusto così hanno
Qualcosa di qualcuno che in realtà
sta guidando la squadra e in realtà
controllando questo sono commerciali
progetti e hanno come minimo
dimensione di 12 epiche in modo tale che siano
non così piccolo, quindi vedi che questi sono 13
progetti scelti a caso e ciò che ho fatto
Ho preso i dati in modo che abbiano le loro dimensioni
per le uscite a sprint e ho deciso
facciamo funzionare RBS sui loro dati reali
e confrontare la stima della previsione
con i reali solo per vedere se in realtà
giorni c’è qualcosa nella nostra base
giusto così che ti sei perso , quindi vedi qui
è questo che dispiace, mhm questo è
storie di storie gay non sono sicure del perché
lo sta facendo così ecco qui quello che abbiamo
sull’asse x abbiamo stimato
siti di progetto in punti storia per quelli
13 proiettare l’asse y abbiamo il
effettivi così ancora quello che ho fatto ho preso il
effettivi ho campionato che significa che ho scelto
utilizzando la base di auto di solo un piccolo sottoinsieme di
tutte le storie degli utenti di quelle squadre dimensionate
l’anno scorso ho avuto una taglia per ciascuno dei
progetto e ho confrontato il preventivo
dimensione con la dimensione reale e io qui oh
beh, è folle comunque, ma puoi
vedi questo R laggiù come se fosse
a si chiama coefficiente di correlazione
e se è se è vicino a 1 significa
una forte correlazione così qui
avere 0.6 97 che mostra un molto forte
correlazione quasi impossibile se
mi piace è una correlazione molto forte
di nuovo queste sono 13 squadre diverse 13
progetti diversi che davvero non conosco
quello che stanno facendo e lo dimostra tutto
13 team hanno un’ottima applicazione di
una certa metodologia per quando sospirò
i loro progetti non so davvero cosa
stanno usando Non ho lavorato perché
gli altri dati sono anonimi ma non posso
vai e chiedi a destra ma non è il
punto il punto qui è quello perché
di nuovo se tu se tu se torniamo qui
quindi questi sono sistemi stabili
sicuramente applicare alcune metodologie
avere un allenatore per guidarli così loro
sono stabili e fanno qualcosa
scopo non è numeri casuali
sicuramente questi non sono numeri casuali
quindi ancora una volta questa è una delle applicazioni
quindi se hai se hai squadre o a
collaborare con una certa versione storica
la storia molto facilmente si può effettivamente
controlla se stanno applicando qualcosa o
sono uguali a quelli che assumiamo sempre
che le persone stanno facendo del loro meglio
e non stanno imbrogliando giusto ma io sono
quando io quando dico un’applicazione coerente
di una metodologia potresti non applicarla
coerente perché non stai bene
addestrato giusto tu non lo fai
sapere cosa fare in modo che non stiamo parlando
tradendo qui stiamo solo confrontando cosa
le persone stanno facendo e se se quello che loro
stanno facendo è coerente qualunque essi
lo stanno facendo se hai squadre con
cronologia di rilascio puoi controllare se tu
avere squadre e la loro storia di rilascio
diciamo che non è come la correlazione
non è così forte e potresti pensare
riguardo al loro drenaggio puoi controllare dopo
la formazione qual è l’effetto adesso
perché queste squadre in realtà loro loro
Avevano anche loro loro hanno usato compiti
e questa è la correlazione quando noi quando
abbiamo stimato il numero di compiti con
il numero effettivo di compiti e vedi
il coefficiente di correlazione qui non lo è
che bevuto è solo 0,7 luci su 93
diciamo di nuovo che è molto forte
correlazione
e la prima cosa è come il numero
di storie perché di nuovo in alcune squadre
come incumbent contiamo solo il numero
di storie e eseguo RBS per vedere se il
il numero effettivo di storie corrisponderà a volontà
correlare con il numero stimato di
storie e ancora molto molto forte
correlazione quindi cosa significa questo
utilizzando la base dell’auto con un semplice campionamento
possiamo molto prevedere la dimensione di a
progetto consegnare e di nuovo qui e io
avere dati per mostrare che non si tratta solo di
progetti che possono essere applicati anche se tu
qui per il rilascio no, immagino di tutto
diciamo cento storie di utenti e ha funzionato
allo stesso modo perché è di nuovo a
struttura ramificata abbiamo una versione
rilascia il trunk e tutto l’utente
le storie sono le riprese del terminale giusto
e in realtà ho usato i dati di AC Esper per
questo perché è così così questo è uno
delle applicazioni giuste, quindi queste sono
le conclusioni della mischia fanno comdata
prima di tutto tutte e 13 le squadre in modo coerente
applicare la metodologia per affettare il
requisiti nei negozi e dimensionamento
usando i punti storia e le attività che sono
la conclusione quindi molto buona per quelle a
tutti quelli 30 poi il tranquillo
importante conclusione è che loro
in qualche modo gestito l’emergente e io
cambiare i requisiti di rischio sai quando
iniziamo un progetto di solito
cresce e alcune persone lo chiamano come scope
creep altre persone lo chiamano come l’apprendimento
ora, ma in ogni caso l’ambito di solito ottiene
più grande quindi in qualche modo sono riusciti e quello
il terzo e il più importante
la conclusione è che l’esecuzione è
più importante della pianificazione perché
qui con le nostre api non parliamo
non parliamo di come pianificare su a
base giornaliera usiamo le nostre birre solo per
diciamo un livello alto o un livello di budget
pianificazione giusta per fare un
decisione a livello di portafoglio ancora
quotazioni per verificare se le squadre sono
applicare coerentemente e impegnarsi a schivare
e cose del genere non usiamo RBS
quando effettivamente iniziamo ad eseguire il
progetto ma la squadra se siamo se il
la squadra è davvero agile e in realtà loro
non hanno iniziato con un arretrato completo
o sembriamo un sacco di lavori giusti
è che sia la squadra che avrà
applicare continuamente e coerentemente
la stessa metodologia di dimensionamento e questo è
perché l’esecuzione è più importante di
pianificare questo è solo una pianificazione qui
giusto così qui non pensarlo
è come se fosse il Santo Graal o
qualcosa del genere è solo un molto
strumento utile per avviare una consegna del software
o per confrontare nuovamente le diverse dimensioni se
vengono dalla stessa squadra, ma
è come hai detto a questo livello
è molto alto e poi tocca al
squadra per consegnare bene e poi, naturalmente
la prossima applicazione è per il dimensionamento nuovo
progetti e possiamo dimensionare per esempio noi
può stimare il numero totale di utenti
storie in un progetto così di uso comune
davvero questo è ciò a cui siamo interessati
siamo interessati al numero di
storie che possiamo quindi applicare al meglio
stimando i punti totali della storia come me
ha mostrato e quindi possiamo applicare RBS per
stimare il numero di compiti e possiamo
stimare il numero di scenari BDD in
il progetto è quello che sto usando
perché quando sono di solito le mie squadre con
usano scenari che è quasi il
stesso
Voglio dire che è la stessa idea che possiamo
apply to I non ho dati per la funzione
punti ma sono abbastanza sicuro che lo farà
essere applicabile anche lì se qualcuno
sta usando i punti funzione che conosco le persone
lo stanno usando almeno negli Stati Uniti
Gli stati e il progetto GOG sono obbligatori per
usare per usare i punti funzione e qui come
un po ‘di Matt giusto per mostrarlo
ho 30 minuti quindi ne abbiamo un sacco
ora così ancora qui vogliamo stimare
come il numero di storie nel nostro progetto
e abbiamo un prodotto e poi accadiamo
lo scomporremo in epopee e
poi ogni epoca la scomporremo
nella user story e questa è la nostra ramificazione
struttura ed è come solo per il
la chiarezza è la stessa cosa
struttura giusta quindi abbiamo un melo
e abbiamo il baule e poi lo abbiamo
filiali e ciò a cui siamo interessati
sono i tiri terminali che sono i
piccoli rami con il frutto su di loro
questa è la mappatura quindi il prodotto è quello
è il tronco epico è il ramo e
storie degli utenti di sparare sul terminale e qui
è la formula giusta non ce n’è bisogno
ricorda di nuovo la formula c’è un
articolo nel cazzo te e te lo mostrerò
alcune cose eccelle ma quindi è molto
formula semplice per valutare
il numero di storie utente in realtà
noi seguiamo questo particolare algoritmo
e perché si sta muovendo ok così prima il primo noi
dividere l’ambito del progetto in epici così
è obbligatorio quindi se abbiamo un prodotto
o un progetto che ascolterà 4000 epici
dobbiamo sapere che ce ne saranno mille
epopea giusto se abbiamo questa struttura
che è storie epiche di backlog del prodotto
giusto quindi dobbiamo trovare il numero
di epopee è solo il numero
senza analisi solo il numero
poi campioniamo a caso uno dei poemi epici
il che significa davvero a caso quindi la chiave
la parola qui è casuale, quindi non possiamo
assaggiare il più rischioso o il più facile
o qualunque cosa vogliamo che sia
casuale in modo casuale significa a caso e
poi analizziamo quante storie ci sono
questo epico significa che dobbiamo
abbattere questo particolare scelgo
le storie si rompono e poi
usando le formule che ho mostrato a noi
calcolato la stima delle storie così
questo è per storie e poi ripetiamo
i punti da 24 7 tra sette e
Di solito, 11 volte è un sette
e quindi possiamo stimare lo stesso
rbs.l applicato per stimare la storia totale
indica di nuovo in un progetto questo è il nostro
questa è la nostra struttura di ramificazione e qui
quello che abbiamo è come se avessimo il progetto
ed epico poi le storie degli utenti e poi
abbiamo il frutto in fondo che
sono i punti della storia e poi di nuovo lo è
per chiarezza quindi la mappatura che è
ubriaco è il prodotto della ramificazione del
i rami sono epiche sono le storie degli utenti
tiri al terminale e punti storia per
storia il numero di frutta sullo scatto
è così che in realtà questi sono i
algoritmi utilizzati per la mischia di dati
lo stesso oh e ti mostrerò dopo così
come si può fare questo è il tappeto e
questo è questo è l’algoritmo quindi noi
prima di tutto dividi il progetto in
epoche che è un passaggio obbligato e molte
la gente dice bene se se se ci sarà
un migliaio di epici quindi è molto lavoro
sì, è un sacco di lavoro, ma ce n’è uno
In un altro modo intendo se si passa alla storia
la storia dovrai romperla in un
foto comunque
quindi se hai un progetto di migliaia
l’epica è molto ma lo farà comunque
risparmiare un sacco di tempo, poi di nuovo noi
campionare a caso una delle loro foto allora
analizziamo quante storie ci sono in questo
epico e scriverò semplicemente il numero
di storie e poi abbiamo speronato un esempio
una delle storie solo una delle
storie per questa particolare epica e
quindi stimiamo i punti della storia per
storia morta solo per questo particolare
storia che dobbiamo analizzare dobbiamo sapere
punti storia e quindi usiamo la formula
calcoliamo i siti del progetto per questo
epico particolare, quindi lo facciamo tra
ancora sette e undici volte e lo farò
mostra adesso in Excel quindi qual è il
Una specie di conclusione quindi RBS’s è a
tecniche di dimensionamento per la previsione
tecniche per dimensionare i progetti software
senza previa identificazione preventiva e
tutta l’assistenza di Isaac di ogni singolo
la dimensione del progetto delle storie degli utenti potrebbe essere
misurato in punti storia numero di compiti
essere dedotto da qualsiasi altra funzione
punta qualunque cosa fintanto che c’è un
la metodologia applicata può essere utilizzata
abbiamo trovato come eseguendo la macchina basata su a
dati storici abbiamo scoperto che esiste un
correlazione molto forte tra il
previsione e attrice davvero forti
correlazione e, naturalmente, utilizzando carb
giorni possiamo possiamo chiedere di rispondere al
domanda quanta software avremo bisogno
per consegnare un punto così qui è il
ecco l’articolo e ci andrò
e ci andrò solo perché tu possa vederlo
ecco l’ articolo in cui puoi andare e
leggi tutta la matematica è un sacco di fango tutto
la formula è qui calcoli di esempio
e poi guarda come la mischia fa i dati
e poi quello che è importante è qui al
in fondo è
Ti mostrerò i dati della mischia e
è in fondo quando fai clic su Mi piace
clicca il link e poi vai
il fondo di questo articolo è da
il loro sito giusto perché è loro
dati alla fine dice i risultati e
va a google doc spreadsheet così tutto
questi 13 progetti se vuoi controllare
come è fatto di nuovo è come se fosse un non
mi così X come 234 come si può andare avanti
e per ogni singolo progetto così qui
è qui i dati sono qui i dati
quindi il calcolo stesso per ciascuno di
il progetto quale dei progetti e
poi andiamo fino alla fine no todo al
prima slide in cui i riepiloghi
i risultati sono anche che il rosso qui sono
i risultati di nuovo sull’asse x che abbiamo
la dimensione stimata sul filo sul
asse y abbiamo questa scelta, quindi ce l’abbiamo
viene da questi strumenti di Doug e
stimare è che non sono la stessa cosa
vedere la dimensione effettiva non è la stessa con
la dimensione stimata e potrebbe essere a
delusione a qualcuno ma ancora
è una stima è una previsione e
ancora durante l’esecuzione del progetto lì
molto probabilmente erano nuovi requisiti e
cambiando 0 requisiti ma comunque
ciò che è importante è questa la correlazione
è una correlazione molto forte quindi se tu
diciamo 13 uscite per a
squadra puoi puoi usare questo lo stesso
Documento di Google Documenti e puoi
In realtà mandami domande se ne hai
come il mio preferisco
la messaggistica diretta arriva su Twitter perché
il mio indirizzo mail è molto lungo quindi il mio nome
è Damita bugger Jeff è come se fosse
è impossibile comunicare così
Twitter due cose meglio e puoi
vediamo come vediamo qual è la differenza
come l’attuale è 5733 e il punto cinque
i punti storia stimati sono 500 297
254 qui c’è una grande differenza
è una grande differenza per cui è come
un progetto molto piccolo è quasi no
la differenza vede ma non sono la stessa cosa
e non ci aspettiamo che i numeri
sii lo stesso si
questo punto intendi bene è fatto
automaticamente erano i suoi debiti
il punto 3040 qualcosa 9000 sì
questo è il punto sì lo ho in Excel
anche nella stessa correlazione intendo
che è quello che non sono sicuro di cosa ma
è la stessa correlazione intendo questo
arriva la tabella che questo diagramma viene
da qui e puoi controllarlo da solo
di nuovo vai all’articolo e poi vai giù
quindi clicca sul doppio link scrum e
poi vai a vedere i dati ci sei tu
puoi controllarlo tu stesso se c’è un bug
in google foglio poi c’è la
lo stesso bug in excel si posso mostrare
anche in XO, così siamo di nuovo qui
cercando la correlazione giusto non lo facciamo
si aspettano gli stessi numeri che saranno
assolutamente impossibile se i numeri
erano gli stessi sarei il primo
per dirlo è una truffa, giusto è
impossibile essere lo stesso solo a causa di
il fatto che siano emergenti
requisiti è impossibile avere il
stessi numeri ma siamo molto vicini e
ancora una volta non è per una pianificazione dettagliata
scommettere la tua casa su questo è per
pianificazione di alto livello, perché se tu
fai venire un nuovo progetto e lo sei
non è sicuro lo puoi inserire nel tuo
portfolio e puoi farlo
calcolo per 10 minuti letteralmente e
ancora stime di budget di bilancio in base
a pm i settanta per cento esatto è
è più dell’ottantacinque per cento
la precisione di nuovo per me è utile allora
cosa ti mostrerò dopo, sì, ecco qui
di un file excel che Martinez Braley
preparato in base all’articolo qualsiasi e
ti mostrerò come deve essere fatto
qui probabilmente lo sta usando nella sua
i propri progetti comunque così abbiamo il
numero di API in questo questi sono
numeri assolutamente casuali proprio giusto
per l’illustrazione rispetto al metodo, quindi noi
avere cento epock e lo saremo
stimare in negozio
indica quello che stiamo facendo qui vedi
la formula che aggiungiamo aggiungiamo il picking a
casuale un numero epico quindi abbiamo 1 2 3
4 5 200 e stiamo selezionando un asse
raccogliere uno 11 volte, quindi questi sono i
epiche selezioniamo a caso quale effettivamente
significa che dobbiamo avere questo cento
epock almeno con i loro nomi in
Davanti a noi, dobbiamo avere una lista
di epiche che è un passaggio obbligato e
allora perché il modo in cui Excel sta facendo se
qualunque sia il cambiamento, li faccio
i numeri casuali cambieranno a destra quindi cosa
stiamo facendo veniamo qui che siamo
copiando questa cosa qui e paghiamo il fetore
solo i valori lo sono comunque se io sono
incollalo incolliamo solo i valori e
poi andiamo lì e il prossimo passo è
abbattere ciascuna delle epoche campione
nelle storie e per ciascun campione
epiche che stiamo abbattendo loro scelgono
nelle storie, quindi stiamo facendo prima di tutto
tutto ciò che facciamo è tale che pensiamo da un
prospettiva dello sforzo quindi dobbiamo prima
rompere il prodotto in un centinaio di grembiuli
che probabilmente dovrà farlo
ovunque tu dopo, ma è uno sforzo
giusto e poi 4 11 di quei cento
epock dobbiamo scomporlo in
le storie degli utenti vanno semplicemente giù e poi
questa è la stima del numero totale
di user story nel progetto mille
682 quindi se dobbiamo abbattere il
l’intero progetto è appena arrivato al numero
di storie solo dovremo venire
come alla fine dovremo avere un
elenco di un dubbio quindici milleseicento
storie degli utenti ora con esso come un molto
sforzo molto limitato arriviamo al
stesso
ancora una volta è una previsione e giusta
è un’esecuzione prevista di più
importante di più importante di
pianificazione giusta così ora abbiamo questo il
numero di storie utente poi a caso
assaggiare una storia per ogni epoca e
di nuovo è fatto in profondità Excel, proprio noi
ne assaggiamo solo un numero dell’utente
storie come uno due tre o cinque e
qui il numero degli indici del
storie degli utenti e noi copia e incolla solo
il valore in modo che il texel non piacerà
generare nuovi numeri tutto il tempo che è
come funziona e poi andiamo e per ogni
del polso per ciascuno dei casuali
la storia campionata noi solo per quello
storia particolare faremo qualsiasi tipo di
analisi o dimensionamento correggendo solo 4 11
storie in totale ne faremmo qualsiasi
tipo di dimensionamento fino ad ora siamo solo
abbattere a destra non stiamo dimensionando noi
non sono Anna come se ci fossimo appena lasciati
è ancora una volta è un processo in esso
dovrebbe essere una piega metodologica per questo
ma ancora non è analogo non lo è
dimensionamento e poi alla fine quello è il
numero totale in questo caso è quasi
11.000 utenti turismo
di nuovo sono numeri fittizi
solo per illustrare il metodo se io
metti i numeri reali che sarà per davvero
il progetto va bene, quindi pensa a come
solo per venire con questo numero cosa
non sarebbe mai quanti giorni ho davvero
non so che non l’ho mai fatto così io
davvero non so come stimare così
molte epiche comunque e che afferma il
penso che possiamo farlo lo stesso se non lo facciamo
avere epopee se non abbiamo letteralmente no
chiave di Epic quindi basta usare lo stesso file
quindi questa volta questo è in realtà questo è
sì / uno dei progetti iceberg e it
colpisci 92 storie di qualcosa che io non conosco
registriamo e ancora campioniamo questa volta
solo sette a destra ho deciso di essere come
più piccolo numero sette di questo 92
epopee effettivamente ha fatto essi non sono suggerimento è
sono solo storie o pezzi di
funzionalità giusta ma perché lo sono
usando lo stesso file XO è proprio ora
sono epopee ma sono solo pezzi di lavoro
e poi per ogni epoca lo diciamo
ogni epoca di storia sl1 che significa
che non hanno storie e noi abbiamo
quindi questo è il numero stimato di
storie che in realtà sono le stesse di
il numero che abbiamo iniziato con quale è
aspettato giusto ma non è il nostro obiettivo noi
voglio sapere la dimensione di questa cosa e
di nuovo a caso ne scegliamo uno
che è contro sette storie noi
stimiamo analizziamo quelle sette storie
solo sette su sette su 92 e basta
il numero di punti storia così per quello
progetto particolare il numero effettivo era
774
Neanche io so nulla del progetto
il progetto, né che tu possa sapere
niente quindi c’è una differenza cinque
differenza percentuale tra effettivo a breve
previsioni bene è quello che è giusto noi
non può essere come sul posto ma è cinque
per cento piuttosto bene, direi così così
qui abbiamo quattro minuti 44 domande che mi
Credo che posso rispondere alle domande
qui per più minuti, giusto
perché quando uso i dati lo sforzo
insieme con le dimensioni per qualsiasi tipo di
progetti non ho trovato alcuna correlazione tra
il numero di storie utente o il numero
di punti storia in particolare tra il
numero di punti storia e lo sforzo o
il tempo di consegna se il tuo progetto se si
quando lo fai è una cosa molto facile da fare
basta tracciare le storie degli utenti per il
progetto come per ogni storia e poi il
tempo necessario per la consegna e se
c’è una correlazione che puoi usare
lo stesso metodo per la previsione del
sforzo se non c’è alcuna correlazione
Scommetto che non ci sarà alcuna correlazione
a meno che tu non abbia una squadra molto piccola con a
coefficiente di efficienza del flusso molto alto
che è come come mai sa cosa
molte persone speriamo che non ci sarà
nessuna correlazione, quindi cerco sempre di essere
rigoroso e se non ci sono prove
che in realtà può essere applicato allo sforzo
stimando allora, lo dirò io
non può applicarsi se puoi farlo tu hai
più che benvenuto sarà a
sforzo pionieristico o evento come ma
anche la dimensione in quanto tale è molto è molto
importante ed è probabilmente quello
la risposta a questa domanda
quindi avrò una previsione
workshop a Parigi il secondo di novembre
a lincoln bang france quindi se lo sei
interessato a vedere come possiamo usare il
dimensionare e quindi stimare lo sforzo e
il tempo di consegna è un it’s a
storia diversa ma può essere fatta bene
può essere fatto ma non è per oggi
e ci sono altri modi come te come io
eseguo simulazioni di monte carlo
in base a dati storici sulla consegna
tempi giusti che è adatto per RB
non è adatto per RBS piace solo
come se fosse il contrario così e
direbbero che è una grande domanda
ho vissuto personalmente come vado a
una squadra e dire dammi i tuoi dati e
Gestirò RBI e ti dirò se tu
sono coerenti non forniscono mai il
dati giusti perché questo otto di Darby è
come uno specchio piace e lo farà
rispecchiare la realtà se non c’è
correlazione che significa che lo sono
in realtà seguendo non cadono nemici
per schivare il diritto e la realtà sarà
brutti e gente noi come esseri umani noi no
come cose brutte non facciamo così il mago
il principale ostacolo a voi di voi pensa
matrice in generale il mio punto è quello
la gente non vuole vedere la verità così
rispondi alla domanda non è quella nostra
la base è mostrata da arpie adatte
stai seguendo qualcosa o sei giusto
sta generando punti storia casuali
perché qualcuno ti chiede di farlo
diritto o attività o qualsiasi altra cosa tu faccia
io
beh, ho alcune persone come me lo so
stanno lavorando a Connor come 200 milioni
progetti per il Dipartimento della Difesa e
loro rivendicano l’agile e loro sono e
loro non c’è modo di restringere 200
milioni in due milioni giusto così se
la realtà è grande se hai grandi progetti
è così che hai un grande progetto e tu
può essere ancora agile perché mi piace
la dimensione è il modo in cui ci avviciniamo al
problema giusto non riguarda l’oggetto
parla di come ci avviciniamo, okay
grazie
campionamento casuale ma prima di tutto
come se dovessi ricordarti di impegnarti e
varia e valuta questa decisione e così via
qual è qual è il qual è lo scopo
di parlare di progetti di previsione
dimensione del progetto, quindi quando iniziamo il software
sviluppo almeno nella mia esperienza
le due domande che sento tutte
il tempo è quanto tempo e quanto tempo
ci vorrà e quanto costerà
noi per consegnare un pezzo di software e in
Per essere in grado di rispondere a quelli
domande abbiamo bisogno di sapere quanto
il software sarà disponibile quando
dobbiamo avere un modo per quantificarlo
quanto e in genere ciò che chiamiamo
è come ridimensionare così dimensionamento in questo
la presentazione in questo contesto è come
per noi essere in grado di quantificare il
dimensione del progetto un pezzo di consegna
e non concentrare lo sforzo necessario per
offrendo così questi sono due diversi
cosa perché le cose perché di solito
quando diciamo ridimensionamento di solito pensiamo che lo sia
a è su quanto tempo ha fatto bene
alcuni sfortunati direi e e
è quello che voglio sottolineare su questo
la dimensione stima la probabile dimensione di
pezzo di software durante lo sforzo
la stima stima lo sforzo necessario
per costruirlo parlerà
dimensionando qui in agile in un gel noi abbiamo
di solito usa t-shirt dimensionamento e storia
punta O’Doyle inizialmente indietro nel
secolo precedente quando
hanno iniziato con lo sviluppo del software
stavano usando linee di codice scritte
e poi è stata l’analisi del punto di funzione
che in realtà ce l’ha fatta
codificato in diversi standard ISO ma
di nuovo in agile stiamo usando le t-shirt
il punto della trama dell’inchiostro è un bacio troppo piccolo
è molto facile iniziare con come
soprattutto per le squadre immature
cosa con con cadetti dimensionamento t-shirt
non è additivo come prontamente additivo
possiamo aggiungerlo sostituendo le dimensioni
con i numeri ma in breve è
difficile dire che il nostro progetto è grande
come due M’s 3 e qualcosa di simile
questo è il motivo per cui la maggior parte delle volte
le persone che stiamo usando queste persone sono
usando punti storia e storia
i punti qui sono presentati dal mio cono per
istanza afferma che i punti della storia sono
riguardo allo sforzo per il tempo sul nostro nuovo
in questa presentazione useremo
come i sospiri nella storia, indica solo una tomba
tomba in complessità in alcun modo alcuni
complessità giusta ma non riguardo al cavallo
quindi quando dico punti storia vuol dire
dimensione relativa e sforzo non relativo
ok, questo è solo nel contesto, anche se
Conosco persone che lo sostengono in realtà
la mia definizione di coni non è corretta in
tutto e ma è dipende dall’accensione
la squadra così per noi piace perché
il software credo sia diverso da
stima dei guasti del software quando parlo
dimensioni e punti storia significherà di più
o meno complessità nelle persone con vincoli di reddito
ciò che le persone stanno facendo i loro parenti di dimensionamento
contando solo il numero di storie
per esempio alcune persone li usano
conta il numero di compiti ma in generale
qualunque cosa contiamo è il modo in cui il
il modo in cui dovrebbe essere fatto è il
come se dovessimo identificare tutti come noi
avere un prodotto o un pezzo di software
che dobbiamo consegnare dobbiamo rompere
giù in epopee o in pezzi più grandi e
allora dobbiamo abbattere ogni epoca
e il ragazzo della storia sono state storie e poi
dobbiamo analizzare ciascuna di quelle storie
in punti storia e poi riassumiamo e
finiamo con la dimensione totale del
progetto che richiede tempo ma non
solo il tempo che consuma è davvero la maggior parte di
il tempo non ha senso perché
i requisiti cambiano il contesto cambiano
e leggerà che non funzionerà il
sforzo giusto per analizzare un gruppo di
incertezze giuste e soprattutto quando
dobbiamo fare un livello di portafoglio
decisioni ad esempio a quali progetti
lavorare su accettare di impegnarsi ao a
fare quotazioni ai nostri clienti come
spendendo un tale sforzo sono le persone
non farlo letteralmente ed è per questo che io
stava cercando un modo per accelerare questo
l’attività di dimensionamento e ho avuto grazie a Dio I.
trovato come una tecnica da cui proviene
originato da estranei orticoli
non è sicuro del perché si sta muovendo, ma io sono io
devo spostarlo indietro per tutto il tempo
scorre così questo signore è il codice
Red Raymond Jason e negli anni ’50 e
In effetti negli anni ’50 ha stabilito un metodo
per
una tecnica efficace per
stimare il numero totale di frutti
trovato nel baldacchino di un albero mentre
contando per selezionare parte della chioma così
è ancora un metodo in essere
usare oggi in orticoltura anche se loro
non usarlo per alberi di arancio come
originariamente lo usano per lo più in
stimare la biomassa totale degli alberi
incluso come tutto non solo il
frutta ma è ancora in gran parte utilizzata
in Europa direi come lo sono le persone
interessato alla biomassa o qualcosa di simile
ma in ogni caso è molto utile è un problema
è un multistadio uguale
campionamento probabilistico quale vorrei
preferire nel contesto di questo
presentazione non mi concentrerò sul tappeto
Mi concentrerò sulle applicazioni del tappeto
sarai in grado di leggere se lo sei
interessato al giorno è un articolo in se
puoi mostrarti 2 lo mostrerò a
la fine e tutto il tappeto è lì giusto
quindi qui concentrati solo sulle applicazioni
non sono sicuro di cosa sia la maggior parte del tempo
la gente non gli piace Matt comunque così tanto
qual è l’idea quindi l’idea è che noi
presentiamo un backlog di prodotto come a
sistema di ramificazione quindi questo è un a
prodotto fittizio quindi abbiamo un po ‘di bici
blocca in cui l’abbiamo suddiviso
tre epoche a B e C e a PK ne ha due
storie che un maiale abbia altre due storie
un folletto ecco un CL ecco altri tre
la storia quindi è un prodotto fittizio
arretrato ed è una ramificazione
struttura e perché è una ramificazione
struttura possiamo effettivamente applicare il nostro
birre a questa struttura questo è il tappeto
si chiama stimatore di Horvitz Thompson
e funziona davvero funziona
calcolando la selezione incondizionata
probabilità per quattro
Termina sparare terminare che significa
che se iniziamo dal se iniziamo
dal tronco che nel nostro caso è
arretrato di prodotti e selezioniamo solo una parte
all’interno della struttura ramificata
dentro l’ albero e ne calcoliamo alcuni
probabilità per un tiro terminato
dove si trovano i frutti che è insomma
giusto ed è come sembra è così noi
avere questo travestimento di una struttura che
abbiamo il prodotto è il tronco e
poi scelgono, diciamo, sono i nostri
rami e poi i tiri terminali
sono dove sono le storie degli utenti e il
i frutti nel nostro caso potrebbero essere punti storia
Compiti qualunque cosa tu pensi di averne
che cosa fa in realtà è a
espande la dimensione della storia x il
dimensione delle epoche per scoprirlo
attraverso la dimensione totale di questo rettangolo
ma di nuovo non concentriamoci sul tappeto
qui ciò che è importante in questo era il
Jenner la domanda principale quando effettivamente
ha iniziato a giocare con i dati usando l’auto
base perché rbs funziona per il dimensionamento del software
progetti di sviluppo quindi questa domanda
si alza perché quando lo applicano
orticoltura stimano qualcosa
che è lì giusto vai ad un albero
e il numero di frutti sull’albero in
il baldacchino dell’albero ha un qui è un
valore oggettivo in astratto sottratto
dal suo valore oggettivo di interpretazione
numero bene ci sarà la contabilità
errore giusto se contiamo tutto il frutto
ma più o meno è lo stesso numero
giusto quando applichiamo le nostre api al nostro
arretrato prodotto non c’è niente lì
proprio non c’è niente
questa dimensione è chiamata per il proxy
tutte le funzionalità e capacità
che alla fine consegneremo
qualche punto futuro vedo il
difficoltà qui su come applicare così così
la domanda è da che universo noi
stiamo campionando non c’è niente lì
giusto e poi quando poi lo applico
come ho usato i dati reali e lo dimostrano
in realtà è applicabile ed e
ecco la mia mia spiegazione giusta così
assumere il presupposto dietro il
l’assunzione dietro di te pensa alle nostre birre
per lo sviluppo del software è che il
la dimensione del progetto dipende dal contesto in
il contesto è un concetto molto ampio ma
include il cliente le persone
lo sviluppo del prodotto nel
metodologia che useranno quando
abbattere il prodotto in I pick
storie qualunque cosa facciano e se c’è
una tale metodologia e la applicano
coerentemente e la metodologia stessa
è di nuovo coesivo che è molto
importante è coeso quindi in qualche modo e
siamo abituati a vedere i dati più tardi
in qualche modo siamo in grado di trovare qualcosa
tangibile nel futuro perché le persone
stanno applicando coerentemente un coeso
metodologia per abbattere un’idea
in pezzi quindi questo è il
difficoltà qui se hai solo un’idea
e non hai dati per dimostrarlo correttamente
non è niente, voglio dire, è solo
una finzione e te ne mostrerò un po ‘
le applicazioni quindi le più importanti
applicazione non sicura di quello che sta facendo
questa ma l’applicazione più importante
almeno quelli che quello che io
trovarlo più nel più importante è farlo
per verificare se il nostro team sta applicando il
metodologia coerente quindi se seguiamo
questa idea che stiamo effettivamente controllando
un’applicazione di una metodologia nel
la metodologia non importa quale sia il
la metodologia potrebbe essere
progettando il poker potrebbe essere un comportamento
sviluppo guidato potrebbe essere descritto
sviluppo guidato potrebbe essere pari
probabilmente l’analisi del punto di funzione è corretta
se c’è una metodologia e vedi
con i dati che possiamo effettivamente richiedere e
controlla se le metodologie erano state
applicato coerentemente così il primo
l’applicazione è che se ne abbiamo
dati storici per il nostro team o team
con le taglie diciamo che stanno dimensionando
ogni sprint e vogliamo
controlla se i membri del team sono effettivamente
non generando numeri casuali per dell
per le dimensioni ma stanno facendo qualcosa
possiamo pensare e dimensionare correttamente
usa la nostra BS per verificare che possiamo usare il nostro
birre per vedere l’effetto di un allenatore per
istanza se noi se noi assumiamo un allenatore
per insegnare alla nostra squadra in un poker di pianificazione
possiamo confrontare prima e dopo perché
stiamo confrontando stiamo campionando
da un’applicazione di metodologia
qui dentro potrei entrare in qualcosa come a
un po ‘come una fiaba ma vedrai il
i dati in seguito, quindi questo è molto
applicazione importante e cosa ho fatto
l’anno scorso ho chiesto come una mischia frenetica
fare la mischia è uno strumento per gestire la mischia
progetto
progetto incumbent con la maggior parte scrum
progetti Cranbourne progetto in questi giorni
e ho chiesto loro di fornirmi un po ‘
dati casuali così bene che ne hanno in abbondanza
ci sono un sacco di squadre in abbondanza
progetti e loro sono stati in grado di
raggiungere un accordo con alcuni membri del team
in modo che possiamo usare i dati a destra di
Certo che è sotto il mio diritto anonimo
ma così abbiamo effettivamente ottenuto 13 reali
progetti da 13 squadre diverse e io sono
non sono sicuro di quello che stanno facendo davvero
non so cosa stanno facendo, ma cosa
è comune per questo progetto è così vecchio
tutti i progetti hanno hanno epico
interruzioni di attività della storia che hanno
storia di successo e loro loro
sono squadre stabili quindi lavorano a lungo
molto tempo insieme e loro hanno un
mischia attiva per allenatore o supervisore
questo è molto importante perché ricorda
stiamo discutendo qui l’applicazione di a
metodologia di dimensionamento giusto così hanno
Qualcosa di qualcuno che in realtà
sta guidando la squadra e in realtà
controllando questo sono commerciali
progetti e hanno come minimo
dimensione di 12 epiche in modo tale che siano
non così piccolo, quindi vedi che questi sono 13
progetti scelti a caso e ciò che ho fatto
Ho preso i dati in modo che abbiano le loro dimensioni
per le uscite a sprint e ho deciso
facciamo funzionare RBS sui loro dati reali
e confrontare la stima della previsione
con i reali solo per vedere se in realtà
giorni c’è qualcosa nella nostra base
giusto così che ti sei perso , quindi vedi qui
è questo che dispiace, mhm questo è
storie di storie gay non sono sicure del perché
lo sta facendo così ecco qui quello che abbiamo
sull’asse x abbiamo stimato
siti di progetto in punti storia per quelli
13 proiettare l’asse y abbiamo il
effettivi così ancora quello che ho fatto ho preso il
effettivi ho campionato che significa che ho scelto
utilizzando la base di auto di solo un piccolo sottoinsieme di
tutte le storie degli utenti di quelle squadre dimensionate
l’anno scorso ho avuto una taglia per ciascuno dei
progetto e ho confrontato il preventivo
dimensione con la dimensione reale e io qui oh
beh, è folle comunque, ma puoi
vedi questo R laggiù come se fosse
a si chiama coefficiente di correlazione
e se è se è vicino a 1 significa
una forte correlazione così qui
avere 0.6 97 che mostra un molto forte
correlazione quasi impossibile se
mi piace è una correlazione molto forte
di nuovo queste sono 13 squadre diverse 13
progetti diversi che davvero non conosco
quello che stanno facendo e lo dimostra tutto
13 team hanno un’ottima applicazione di
una certa metodologia per quando sospirò
i loro progetti non so davvero cosa
stanno usando Non ho lavorato perché
gli altri dati sono anonimi ma non posso
vai e chiedi a destra ma non è il
punto il punto qui è quello perché
di nuovo se tu se tu se torniamo qui
quindi questi sono sistemi stabili
sicuramente applicare alcune metodologie
avere un allenatore per guidarli così loro
sono stabili e fanno qualcosa
scopo non è numeri casuali
sicuramente questi non sono numeri casuali
quindi ancora una volta questa è una delle applicazioni
quindi se hai se hai squadre o a
collaborare con una certa versione storica
la storia molto facilmente si può effettivamente
controlla se stanno applicando qualcosa o
sono uguali a quelli che assumiamo sempre
che le persone stanno facendo del loro meglio
e non stanno imbrogliando giusto ma io sono
quando io quando dico un’applicazione coerente
di una metodologia potresti non applicarla
coerente perché non stai bene
addestrato giusto tu non lo fai
sapere cosa fare in modo che non stiamo parlando
tradendo qui stiamo solo confrontando cosa
le persone stanno facendo e se se quello che loro
stanno facendo è coerente qualunque essi
lo stanno facendo se hai squadre con
cronologia di rilascio puoi controllare se tu
avere squadre e la loro storia di rilascio
diciamo che non è come la correlazione
non è così forte e potresti pensare
riguardo al loro drenaggio puoi controllare dopo
la formazione qual è l’effetto adesso
perché queste squadre in realtà loro loro
Avevano anche loro loro hanno usato compiti
e questa è la correlazione quando noi quando
abbiamo stimato il numero di compiti con
il numero effettivo di compiti e vedi
il coefficiente di correlazione qui non lo è
che bevuto è solo 0,7 luci su 93
diciamo di nuovo che è molto forte
correlazione
e la prima cosa è come il numero
di storie perché di nuovo in alcune squadre
come incumbent contiamo solo il numero
di storie e eseguo RBS per vedere se il
il numero effettivo di storie corrisponderà a volontà
correlare con il numero stimato di
storie e ancora molto molto forte
correlazione quindi cosa significa questo
utilizzando la base dell’auto con un semplice campionamento
possiamo molto prevedere la dimensione di a
progetto consegnare e di nuovo qui e io
avere dati per mostrare che non si tratta solo di
progetti che possono essere applicati anche se tu
qui per il rilascio no, immagino di tutto
diciamo cento storie di utenti e ha funzionato
allo stesso modo perché è di nuovo a
struttura ramificata abbiamo una versione
rilascia il trunk e tutto l’utente
le storie sono le riprese del terminale giusto
e in realtà ho usato i dati di AC Esper per
questo perché è così così questo è uno
delle applicazioni giuste, quindi queste sono
le conclusioni della mischia fanno comdata
prima di tutto tutte e 13 le squadre in modo coerente
applicare la metodologia per affettare il
requisiti nei negozi e dimensionamento
usando i punti storia e le attività che sono
la conclusione quindi molto buona per quelle a
tutti quelli 30 poi il tranquillo
importante conclusione è che loro
in qualche modo gestito l’emergente e io
cambiare i requisiti di rischio sai quando
iniziamo un progetto di solito
cresce e alcune persone lo chiamano come scope
creep altre persone lo chiamano come l’apprendimento
ora, ma in ogni caso l’ambito di solito ottiene
più grande quindi in qualche modo sono riusciti e quello
il terzo e il più importante
la conclusione è che l’esecuzione è
più importante della pianificazione perché
qui con le nostre api non parliamo
non parliamo di come pianificare su a
base giornaliera usiamo le nostre birre solo per
diciamo un livello alto o un livello di budget
pianificazione giusta per fare un
decisione a livello di portafoglio ancora
quotazioni per verificare se le squadre sono
applicare coerentemente e impegnarsi a schivare
e cose del genere non usiamo RBS
quando effettivamente iniziamo ad eseguire il
progetto ma la squadra se siamo se il
la squadra è davvero agile e in realtà loro
non hanno iniziato con un arretrato completo
o sembriamo un sacco di lavori giusti
è che sia la squadra che avrà
applicare continuamente e coerentemente
la stessa metodologia di dimensionamento e questo è
perché l’esecuzione è più importante di
pianificare questo è solo una pianificazione qui
giusto così qui non pensarlo
è come se fosse il Santo Graal o
qualcosa del genere è solo un molto
strumento utile per avviare una consegna del software
o per confrontare nuovamente le diverse dimensioni se
vengono dalla stessa squadra, ma
è come hai detto a questo livello
è molto alto e poi tocca al
squadra per consegnare bene e poi, naturalmente
la prossima applicazione è per il dimensionamento nuovo
progetti e possiamo dimensionare per esempio noi
può stimare il numero totale di utenti
storie in un progetto così di uso comune
davvero questo è ciò a cui siamo interessati
siamo interessati al numero di
storie che possiamo quindi applicare al meglio
stimando i punti totali della storia come me
ha mostrato e quindi possiamo applicare RBS per
stimare il numero di compiti e possiamo
stimare il numero di scenari BDD in
il progetto è quello che sto usando
perché quando sono di solito le mie squadre con
usano scenari che è quasi il
stesso
Voglio dire che è la stessa idea che possiamo
apply to I non ho dati per la funzione
punti ma sono abbastanza sicuro che lo farà
essere applicabile anche lì se qualcuno
sta usando i punti funzione che conosco le persone
lo stanno usando almeno negli Stati Uniti
Gli stati e il progetto GOG sono obbligatori per
usare per usare i punti funzione e qui come
un po ‘di Matt giusto per mostrarlo
ho 30 minuti quindi ne abbiamo un sacco
ora così ancora qui vogliamo stimare
come il numero di storie nel nostro progetto
e abbiamo un prodotto e poi accadiamo
lo scomporremo in epopee e
poi ogni epoca la scomporremo
nella user story e questa è la nostra ramificazione
struttura ed è come solo per il
la chiarezza è la stessa cosa
struttura giusta quindi abbiamo un melo
e abbiamo il baule e poi lo abbiamo
filiali e ciò a cui siamo interessati
sono i tiri terminali che sono i
piccoli rami con il frutto su di loro
questa è la mappatura quindi il prodotto è quello
è il tronco epico è il ramo e
storie degli utenti di sparare sul terminale e qui
è la formula giusta non ce n’è bisogno
ricorda di nuovo la formula c’è un
articolo nel cazzo te e te lo mostrerò
alcune cose eccelle ma quindi è molto
formula semplice per valutare
il numero di storie utente in realtà
noi seguiamo questo particolare algoritmo
e perché si sta muovendo ok così prima il primo noi
dividere l’ambito del progetto in epici così
è obbligatorio quindi se abbiamo un prodotto
o un progetto che ascolterà 4000 epici
dobbiamo sapere che ce ne saranno mille
epopea giusto se abbiamo questa struttura
che è storie epiche di backlog del prodotto
giusto quindi dobbiamo trovare il numero
di epopee è solo il numero
senza analisi solo il numero
poi campioniamo a caso uno dei poemi epici
il che significa davvero a caso quindi la chiave
la parola qui è casuale, quindi non possiamo
assaggiare il più rischioso o il più facile
o qualunque cosa vogliamo che sia
casuale in modo casuale significa a caso e
poi analizziamo quante storie ci sono
questo epico significa che dobbiamo
abbattere questo particolare scelgo
le storie si rompono e poi
usando le formule che ho mostrato a noi
calcolato la stima delle storie così
questo è per storie e poi ripetiamo
i punti da 24 7 tra sette e
Di solito, 11 volte è un sette
e quindi possiamo stimare lo stesso
rbs.l applicato per stimare la storia totale
indica di nuovo in un progetto questo è il nostro
questa è la nostra struttura di ramificazione e qui
quello che abbiamo è come se avessimo il progetto
ed epico poi le storie degli utenti e poi
abbiamo il frutto in fondo che
sono i punti della storia e poi di nuovo lo è
per chiarezza quindi la mappatura che è
ubriaco è il prodotto della ramificazione del
i rami sono epiche sono le storie degli utenti
tiri al terminale e punti storia per
storia il numero di frutta sullo scatto
è così che in realtà questi sono i
algoritmi utilizzati per la mischia di dati
lo stesso oh e ti mostrerò dopo così
come si può fare questo è il tappeto e
questo è questo è l’algoritmo quindi noi
prima di tutto dividi il progetto in
epoche che è un passaggio obbligato e molte
la gente dice bene se se se ci sarà
un migliaio di epici quindi è molto lavoro
sì, è un sacco di lavoro, ma ce n’è uno
In un altro modo intendo se si passa alla storia
la storia dovrai romperla in un
foto comunque
quindi se hai un progetto di migliaia
l’epica è molto ma lo farà comunque
risparmiare un sacco di tempo, poi di nuovo noi
campionare a caso una delle loro foto allora
analizziamo quante storie ci sono in questo
epico e scriverò semplicemente il numero
di storie e poi abbiamo speronato un esempio
una delle storie solo una delle
storie per questa particolare epica e
quindi stimiamo i punti della storia per
storia morta solo per questo particolare
storia che dobbiamo analizzare dobbiamo sapere
punti storia e quindi usiamo la formula
calcoliamo i siti del progetto per questo
epico particolare, quindi lo facciamo tra
ancora sette e undici volte e lo farò
mostra adesso in Excel quindi qual è il
Una specie di conclusione quindi RBS’s è a
tecniche di dimensionamento per la previsione
tecniche per dimensionare i progetti software
senza previa identificazione preventiva e
tutta l’assistenza di Isaac di ogni singolo
la dimensione del progetto delle storie degli utenti potrebbe essere
misurato in punti storia numero di compiti
essere dedotto da qualsiasi altra funzione
punta qualunque cosa fintanto che c’è un
la metodologia applicata può essere utilizzata
abbiamo trovato come eseguendo la macchina basata su a
dati storici abbiamo scoperto che esiste un
correlazione molto forte tra il
previsione e attrice davvero forti
correlazione e, naturalmente, utilizzando carb
giorni possiamo possiamo chiedere di rispondere al
domanda quanta software avremo bisogno
per consegnare un punto così qui è il
ecco l’articolo e ci andrò
e ci andrò solo perché tu possa vederlo
ecco l’ articolo in cui puoi andare e
leggi tutta la matematica è un sacco di fango tutto
la formula è qui calcoli di esempio
e poi guarda come la mischia fa i dati
e poi quello che è importante è qui al
in fondo è
Ti mostrerò i dati della mischia e
è in fondo quando fai clic su Mi piace
clicca il link e poi vai
il fondo di questo articolo è da
il loro sito giusto perché è loro
dati alla fine dice i risultati e
va a google doc spreadsheet così tutto
questi 13 progetti se vuoi controllare
come è fatto di nuovo è come se fosse un non
mi così X come 234 come si può andare avanti
e per ogni singolo progetto così qui
è qui i dati sono qui i dati
quindi il calcolo stesso per ciascuno di
il progetto quale dei progetti e
poi andiamo fino alla fine no todo al
prima slide in cui i riepiloghi
i risultati sono anche che il rosso qui sono
i risultati di nuovo sull’asse x che abbiamo
la dimensione stimata sul filo sul
asse y abbiamo questa scelta, quindi ce l’abbiamo
viene da questi strumenti di Doug e
stimare è che non sono la stessa cosa
vedere la dimensione effettiva non è la stessa con
la dimensione stimata e potrebbe essere a
delusione a qualcuno ma ancora
è una stima è una previsione e
ancora durante l’esecuzione del progetto lì
molto probabilmente erano nuovi requisiti e
cambiando 0 requisiti ma comunque
ciò che è importante è questa la correlazione
è una correlazione molto forte quindi se tu
diciamo 13 uscite per a
squadra puoi puoi usare questo lo stesso
Documento di Google Documenti e puoi
In realtà mandami domande se ne hai
come il mio preferisco
la messaggistica diretta arriva su Twitter perché
il mio indirizzo mail è molto lungo quindi il mio nome
è Damita bugger Jeff è come se fosse
è impossibile comunicare così
Twitter due cose meglio e puoi
vediamo come vediamo qual è la differenza
come l’attuale è 5733 e il punto cinque
i punti storia stimati sono 500 297
254 qui c’è una grande differenza
è una grande differenza per cui è come
un progetto molto piccolo è quasi no
la differenza vede ma non sono la stessa cosa
e non ci aspettiamo che i numeri
sii lo stesso si
questo punto intendi bene è fatto
automaticamente erano i suoi debiti
il punto 3040 qualcosa 9000 sì
questo è il punto sì lo ho in Excel
anche nella stessa correlazione intendo
che è quello che non sono sicuro di cosa ma
è la stessa correlazione intendo questo
arriva la tabella che questo diagramma viene
da qui e puoi controllarlo da solo
di nuovo vai all’articolo e poi vai giù
quindi clicca sul doppio link scrum e
poi vai a vedere i dati ci sei tu
puoi controllarlo tu stesso se c’è un bug
in google foglio poi c’è la
lo stesso bug in excel si posso mostrare
anche in XO, così siamo di nuovo qui
cercando la correlazione giusto non lo facciamo
si aspettano gli stessi numeri che saranno
assolutamente impossibile se i numeri
erano gli stessi sarei il primo
per dirlo è una truffa, giusto è
impossibile essere lo stesso solo a causa di
il fatto che siano emergenti
requisiti è impossibile avere il
stessi numeri ma siamo molto vicini e
ancora una volta non è per una pianificazione dettagliata
scommettere la tua casa su questo è per
pianificazione di alto livello, perché se tu
fai venire un nuovo progetto e lo sei
non è sicuro lo puoi inserire nel tuo
portfolio e puoi farlo
calcolo per 10 minuti letteralmente e
ancora stime di budget di bilancio in base
a pm i settanta per cento esatto è
è più dell’ottantacinque per cento
la precisione di nuovo per me è utile allora
cosa ti mostrerò dopo, sì, ecco qui
di un file excel che Martinez Braley
preparato in base all’articolo qualsiasi e
ti mostrerò come deve essere fatto
qui probabilmente lo sta usando nella sua
i propri progetti comunque così abbiamo il
numero di API in questo questi sono
numeri assolutamente casuali proprio giusto
per l’illustrazione rispetto al metodo, quindi noi
avere cento epock e lo saremo
stimare in negozio
indica quello che stiamo facendo qui vedi
la formula che aggiungiamo aggiungiamo il picking a
casuale un numero epico quindi abbiamo 1 2 3
4 5 200 e stiamo selezionando un asse
raccogliere uno 11 volte, quindi questi sono i
epiche selezioniamo a caso quale effettivamente
significa che dobbiamo avere questo cento
epock almeno con i loro nomi in
Davanti a noi, dobbiamo avere una lista
di epiche che è un passaggio obbligato e
allora perché il modo in cui Excel sta facendo se
qualunque sia il cambiamento, li faccio
i numeri casuali cambieranno a destra quindi cosa
stiamo facendo veniamo qui che siamo
copiando questa cosa qui e paghiamo il fetore
solo i valori lo sono comunque se io sono
incollalo incolliamo solo i valori e
poi andiamo lì e il prossimo passo è
abbattere ciascuna delle epoche campione
nelle storie e per ciascun campione
epiche che stiamo abbattendo loro scelgono
nelle storie, quindi stiamo facendo prima di tutto
tutto ciò che facciamo è tale che pensiamo da un
prospettiva dello sforzo quindi dobbiamo prima
rompere il prodotto in un centinaio di grembiuli
che probabilmente dovrà farlo
ovunque tu dopo, ma è uno sforzo
giusto e poi 4 11 di quei cento
epock dobbiamo scomporlo in
le storie degli utenti vanno semplicemente giù e poi
questa è la stima del numero totale
di user story nel progetto mille
682 quindi se dobbiamo abbattere il
l’intero progetto è appena arrivato al numero
di storie solo dovremo venire
come alla fine dovremo avere un
elenco di un dubbio quindici milleseicento
storie degli utenti ora con esso come un molto
sforzo molto limitato arriviamo al
stesso
ancora una volta è una previsione e giusta
è un’esecuzione prevista di più
importante di più importante di
pianificazione giusta così ora abbiamo questo il
numero di storie utente poi a caso
assaggiare una storia per ogni epoca e
di nuovo è fatto in profondità Excel, proprio noi
ne assaggiamo solo un numero dell’utente
storie come uno due tre o cinque e
qui il numero degli indici del
storie degli utenti e noi copia e incolla solo
il valore in modo che il texel non piacerà
generare nuovi numeri tutto il tempo che è
come funziona e poi andiamo e per ogni
del polso per ciascuno dei casuali
la storia campionata noi solo per quello
storia particolare faremo qualsiasi tipo di
analisi o dimensionamento correggendo solo 4 11
storie in totale ne faremmo qualsiasi
tipo di dimensionamento fino ad ora siamo solo
abbattere a destra non stiamo dimensionando noi
non sono Anna come se ci fossimo appena lasciati
è ancora una volta è un processo in esso
dovrebbe essere una piega metodologica per questo
ma ancora non è analogo non lo è
dimensionamento e poi alla fine quello è il
numero totale in questo caso è quasi
11.000 utenti turismo
di nuovo sono numeri fittizi
solo per illustrare il metodo se io
metti i numeri reali che sarà per davvero
il progetto va bene, quindi pensa a come
solo per venire con questo numero cosa
non sarebbe mai quanti giorni ho davvero
non so che non l’ho mai fatto così io
davvero non so come stimare così
molte epiche comunque e che afferma il
penso che possiamo farlo lo stesso se non lo facciamo
avere epopee se non abbiamo letteralmente no
chiave di Epic quindi basta usare lo stesso file
quindi questa volta questo è in realtà questo è
sì / uno dei progetti iceberg e it
colpisci 92 storie di qualcosa che io non conosco
registriamo e ancora campioniamo questa volta
solo sette a destra ho deciso di essere come
più piccolo numero sette di questo 92
epopee effettivamente ha fatto essi non sono suggerimento è
sono solo storie o pezzi di
funzionalità giusta ma perché lo sono
usando lo stesso file XO è proprio ora
sono epopee ma sono solo pezzi di lavoro
e poi per ogni epoca lo diciamo
ogni epoca di storia sl1 che significa
che non hanno storie e noi abbiamo
quindi questo è il numero stimato di
storie che in realtà sono le stesse di
il numero che abbiamo iniziato con quale è
aspettato giusto ma non è il nostro obiettivo noi
voglio sapere la dimensione di questa cosa e
di nuovo a caso ne scegliamo uno
che è contro sette storie noi
stimiamo analizziamo quelle sette storie
solo sette su sette su 92 e basta
il numero di punti storia così per quello
progetto particolare il numero effettivo era
774
Neanche io so nulla del progetto
il progetto, né che tu possa sapere
niente quindi c’è una differenza cinque
differenza percentuale tra effettivo a breve
previsioni bene è quello che è giusto noi
non può essere come sul posto ma è cinque
per cento piuttosto bene, direi così così
qui abbiamo quattro minuti 44 domande che mi
Credo che posso rispondere alle domande
qui per più minuti, giusto
perché quando uso i dati lo sforzo
insieme con le dimensioni per qualsiasi tipo di
progetti non ho trovato alcuna correlazione tra
il numero di storie utente o il numero
di punti storia in particolare tra il
numero di punti storia e lo sforzo o
il tempo di consegna se il tuo progetto se si
quando lo fai è una cosa molto facile da fare
basta tracciare le storie degli utenti per il
progetto come per ogni storia e poi il
tempo necessario per la consegna e se
c’è una correlazione che puoi usare
lo stesso metodo per la previsione del
sforzo se non c’è alcuna correlazione
Scommetto che non ci sarà alcuna correlazione
a meno che tu non abbia una squadra molto piccola con a
coefficiente di efficienza del flusso molto alto
che è come come mai sa cosa
molte persone speriamo che non ci sarà
nessuna correlazione, quindi cerco sempre di essere
rigoroso e se non ci sono prove
che in realtà può essere applicato allo sforzo
stimando allora, lo dirò io
non può applicarsi se puoi farlo tu hai
più che benvenuto sarà a
sforzo pionieristico o evento come ma
anche la dimensione in quanto tale è molto è molto
importante ed è probabilmente quello
la risposta a questa domanda
quindi avrò una previsione
workshop a Parigi il secondo di novembre
a lincoln bang france quindi se lo sei
interessato a vedere come possiamo usare il
dimensionare e quindi stimare lo sforzo e
il tempo di consegna è un it’s a
storia diversa ma può essere fatta bene
può essere fatto ma non è per oggi
e ci sono altri modi come te come io
eseguo simulazioni di monte carlo
in base a dati storici sulla consegna
tempi giusti che è adatto per RB
non è adatto per RBS piace solo
come se fosse il contrario così e
direbbero che è una grande domanda
ho vissuto personalmente come vado a
una squadra e dire dammi i tuoi dati e
Gestirò RBI e ti dirò se tu
sono coerenti non forniscono mai il
dati giusti perché questo otto di Darby è
come uno specchio piace e lo farà
rispecchiare la realtà se non c’è
correlazione che significa che lo sono
in realtà seguendo non cadono nemici
per schivare il diritto e la realtà sarà
brutti e gente noi come esseri umani noi no
come cose brutte non facciamo così il mago
il principale ostacolo a voi di voi pensa
matrice in generale il mio punto è quello
la gente non vuole vedere la verità così
rispondi alla domanda non è quella nostra
la base è mostrata da arpie adatte
stai seguendo qualcosa o sei giusto
sta generando punti storia casuali
perché qualcuno ti chiede di farlo
diritto o attività o qualsiasi altra cosa tu faccia
io
beh, ho alcune persone come me lo so
stanno lavorando a Connor come 200 milioni
progetti per il Dipartimento della Difesa e
loro rivendicano l’agile e loro sono e
loro non c’è modo di restringere 200
milioni in due milioni giusto così se
la realtà è grande se hai grandi progetti
è così che hai un grande progetto e tu
può essere ancora agile perché mi piace
la dimensione è il modo in cui ci avviciniamo al
problema giusto non riguarda l’oggetto
parla di come ci avviciniamo, okay
grazie
Please follow and like us: