Sono nuovo a scrum e lo sto usando su un progetto. Facciamo 3 settimane di iterazioni, stimiamo all'inizio e poi raccogliamo i punti alla fine.
Abbiamo un log del prodotto (probabilmente non completo).
Se fai delle stime dell'intero backlog all'inizio non sono quelle che valutano solo 'ipotesi da culo selvaggio'
Quindi quando valuti il back log e come determini una data di rilascio?
ep
If you do estimates of the entire back log at the beginning aren't those estimate just 'wild ass guesses'?
Una corretta.
So when do you estimate the back log and how do you determine a release date?
Hai degli sprint di rilascio periodici tra gli sprint di build.
Non aspettare.
Metti il software nelle mani degli utenti il più presto e spesso possibile.
In linea di principio, ogni sprint porta a qualcosa che potrebbe essere rilasciato agli utenti.
Se i tuoi sprint non sono rilasciabili, li stai pianificando male.
Dovresti considerare che ogni sprint è idoneo per i test di dimostrazione o accettazione. E dovresti rilasciarlo più spesso di una volta alla fine.
A un certo punto, avrai una versione che gli utenti apprezzano e il backlog è diverso da zero, ma un valore così basso che il proprietario del prodotto decide che non sono necessari sprint di sviluppo più attivi.
In un certo senso, hai finito. Gli utenti sono felici.
In un altro senso, non hai finito. Il backlog non è vuoto.
Questo punto è molto, molto difficile da prevedere, ma è la parte più importante dei metodi Agile. Hai creato abbastanza valore ed evitato di perdere tempo in elementi di basso valore della visione originale.
Il nostro approccio è che tendiamo a indovinare il tempo richiesto approssimativamente nella riunione di pianificazione. Questo dà al proprietario del prodotto un'idea di quanto costerebbe un PBI . Assegna quindi la priorità agli elementi in base a questo e definisce alcune pietre miliari . Penso che quelle pietre miliari siano uscite.
Ad esempio, lavoriamo per 3 sprint, e mentre consegniamo prodotti funzionanti alla fine di ogni sprint, solo dopo 3 sprint pubblichiamo il nostro prodotto agli utenti finali. Quindi dopo altri 4 sprint consegniamo la seconda parte del prodotto.
Penso che dipenda dall'utente e dal meccanismo di consegna. Ad esempio, se il tuo prodotto è simile a Microsoft Office, dovresti consegnare le applicazioni complete (Word, Excel, Access, PowerPoint, ecc.) In un pacchetto agli utenti finali. Ciò significa che la data di rilascio dovrebbe essere la data in cui tutte le applicazioni sono pronte. Tuttavia, puoi rilasciare Word separatamente da Excel, allo stakeholder o a un utente interno . Ciò significa che la data di rilascio per te è quando si consegna Word, ma la data di rilascio per il responsabile delle vendite sarebbe quando lui / lei può vendere il prodotto sul mercato.
Secondo la guida di Scrum,
Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog... Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team... Grooming usually consumes no more than 10% of the capacity of the Development Team.
Quindi dovresti lavorare con il Product Owner per aggiungere dettagli e stime agli articoli del Product Backlog in Sprint, non solo durante Sprint Planning, che dovrebbe concentrarsi maggiormente sulla pianificazione del tuo obiettivo per lo Sprint corrente. Le stime per gli articoli fuzzy dovrebbero essere grandi, a causa dell'incertezza implicata. Quando ricevi più feedback dai clienti, discussioni con il Product Owner, ecc., Puoi migliorare le tue stime.
At the end of a Sprint, the new Increment must be "Done,"... It must be in usable condition regardless of whether the Product Owner decides to actually release it.
Quindi, spetta al Product Owner quando viene rilasciato. Potrebbe decidere di voler aspettare fino a quando un determinato insieme di funzioni ad alta priorità è stato incluso nell'incremento, o potrebbe avere una data di rilascio fissa a quel punto qualsiasi cosa venga rilasciata. In ogni caso, tutto ciò che il Team consegna alla fine di uno Sprint dovrebbe essere pronto per essere spedito ai clienti, in modo che il Product Owner sia libero di prendere quella decisione.
Poiché il Product Backlog è ordinato, il Product Owner può anche usare la velocità del Team per fare una stima di quali elementi del Product Backlog saranno eseguiti entro la fine di uno Sprint. Potrebbe quindi pianificare una data di rilascio molto prima del tempo in base a quando sentirà che il suo set di funzionalità ad alta priorità sarà fatto, o potrà ordinare caratteristiche in modo tale che tutto ciò che è necessario per una data release sarà fatto entro il tempo la data di rilascio si avvicina.
Si noti che all'inizio di un progetto, la velocità di una squadra sarà probabilmente dappertutto, quando fissano la loro definizione di "Fatto" ed eventualmente estinguono un debito tecnico di progetto iniziale, quindi è difficile fare questo tipo di proiezioni . Se è necessario determinare le date di rilascio in una fase precoce, è probabilmente meglio impostare le milestone di release fisse, o semplicemente attendere che il risultato di uno Sprint venga ritenuto contenere un valore sufficiente per essere rilasciato.
In teoria ogni sprint dovrebbe comportare un incremento del prodotto che può essere rilasciato. La domanda è: cosa significa liberazione in questo caso? Significa sicuramente che l'incremento rilasciato dovrebbe essere disponibile per alcuni gruppi di utenti per utilizzarlo e ottenere feedback, ma non deve significare che devi fare una grande release di produzione ogni due o tre settimane.
Esempio:
Supponiamo che tu stia costruendo un'applicazione più grande che dovrebbe essere disponibile pubblicamente. Il proprietario del prodotto ha un'idea del set di funzionalità minimo necessario per rendere l'applicazione disponibile pubblicamente - senza queste funzionalità gli utenti non apprezzeranno l'applicazione e danneggeranno la reputazione dell'azienda. Quindi la prima versione pubblica è basata sulla disponibilità di queste funzionalità obbligatorie. Durante lo sviluppo di questo primo team di rilascio pubblico è ancora possibile rilasciare ogni sprint, ma quelle versioni incrementali saranno disponibili solo internamente all'interno dell'azienda e i dipendenti dell'azienda utilizzeranno l'applicazione in ogni momento durante lo sviluppo.
Anche la data di rilascio pubblica può essere definita. I progressi e la velocità del team mostreranno se il team è in grado di fornire le funzionalità necessarie a quella data di rilascio nella fase iniziale di sviluppo. Ciò consentirà al proprietario e alla gestione del prodotto di reagire abbastanza presto se sarà ovvio che il set di funzionalità richieste è molto più ampio del set di funzionalità disponibili.
Leggi altre domande sui tag scrum