Quando è un agile iterazione considerato completo?[chiuso]

Question

Sto lavorando su una squadra che sta esplorando la possibilità di adottare agile pratiche di sviluppo.

Una domanda che noi siamo contro la decisione di quando un'iterazione (sprint) deve essere completato.

Diciamo che abbiamo definito la nostra funzione di backlog, e prodotta storia-punto di stime per loro, e abbiamo deciso che i primi 30 giorni di sprint includerà le caratteristiche A, B, D, e, F.Cosa si deve fare se si sta raggiungendo la fine della sprint e hai completato A, D, e, F - ma B è a soli 80% di completamento.Si dovrebbe:

1. Completa la sprint in tempo, ma escludere la funzione B (rimandando il lavoro rimanente per un futuro sprint)

2. Estendere la sprint dal tempo necessario per completare la funzione di B, ma non avviare il prossimo sprint.

3. Estendere la sprint dal tempo necessario per completare la funzione di B e iniziare a lavorare sul prossimo sprint.

4. Fallire l'intero sprint, e il raggruppamento di tutti i lavori da parte di una versione futura.

Il problema che vedo con l'opzione 1 è che la squadra non è la consegna di quello che si era impegnata per.In alcuni casi, potrebbe non essere in grado di escludere la funzione di B, senza rendere l'intera release inutile (o almeno sostanzialmente meno prezioso).Ciò può rendere difficile per guidare la direzione del prossimo sprint senza funzione di B.

Il problema con l'opzione 2 è che alcuni membri del team possono essere inattivo per un periodo di tempo significativo - che va ad intaccare la produttività complessiva.Si può essere in grado di aggiungere ulteriori test di unità, o polacco caratteristiche, ma non aggiunge valore proporzionale.È anche politicamente difficile spiegare gestione perché la maggior parte del vostro team è inattivo.

Opzione 3 sembra essere contro lo spirito di agile - si sta mettendo lo sprint successivo a rischio, non permettendo i risultati di quella precedente per guidare la prossima iterazione di sviluppo.

Opzione 4 sembra grave e ha la maggior parte degli stessi problemi dell'Opzione 1 e 3.Prima di tutto, sei completamente mancanti di un impegno.Secondo, accorpamento di più funzioni in una release successiva rende più difficile il test e verificare con i clienti - e di nuovo preclude la possibilità, per la futura iterazione in base al feedback da prima quelli.

Answer 1

L'opzione 1, naturalmente. Il tuo velocità per l'iterazione successiva sta per essere meno, in quanto si basa su di ieri tempo , in modo che la prossima iterazione si ha una migliore possibilità di essere completo.

In mischia sei tempo-boxing . E si esprime solo le caratteristiche che funzionano.

pianificazione sprint voi hanno fatto una stima di quello che si potrebbe fornire. Il cliente deve accettare un certo livello di incertezza nella stima, o essere pronti ad avere troppe risorse sulla squadra.

Se si perde di nuovo la prossima iterazione, passare ad una lunghezza di iterazione più corta, e assicurarsi che la dimensione delle singole funzioni è più piccolo.

Answer 2

Si farebbe normalmente opzione 1 - finitura sprint.Utilizzare il lavoro completato, lasciare il lavoro incompiuto ottenere riscontro nel progetto di velocità, così in futuro la pianificazione tiene conto delle difficoltà che avete sperimentato.

Sì, l'opzione 1 significa che non abbiamo finire quello che ci siamo impegnati a - ma se è quello che è successo allora è meglio ammetterlo e imparare a gestire meglio la prossima volta di nascondere. Cose brutte capitano a tutti - la cosa fondamentale è: come possiamo migliorare dal punto in cui siamo.

Si potrebbe fare l'opzione 2 - continuare a finire il lavoro eccezionale estendendo la sprint.Fate questo solo se il lavoro è super-alta priorità per il cliente e scegliere esplicitamente di farlo. Estendere la lunghezza di scatti li rende più difficili da confrontare con l'altro, perché sono di lunghezza diversa.

Assolutamente mai e poi MAI lasciare che uno sprint unione nel prossimo sia che si sta estendendo il vecchio sprint, o si sta iniziando una completamente nuova.Se si lascia che i due sprint fondono l'uno nell'altro, allora non sei veramente fare uno sprint di più e di pianificazione si rompe...

Answer 3

Posso rispondere con "Dipende"? Inoltre, mi piacerebbe gettare in un "Definire completo".

Abbiamo avuto questa situazione un paio di volte e trattate in modo diverso a seconda delle circostanze.

Per quanto mi ricordo in due casi abbiamo lasciato la volata sicuro. E 'stato in realtà più di un demo-rigettato tipo di fallire. Le caratteristiche stesse sono state considerate completa da parte del team, ma c'erano troppe domande aperte, in sospeso e piccoli dettagli che sono saltate fuori durante la demo. Ci sarebbe voluto un paio di giorni per avvolgere tutto, così abbiamo lasciato la volata fallire e ha preso tutte le partite aperte nel prossimo sprint. Avevamo ancora una programmazione retrospettiva e sprint per le nuove storie di utenti, ma non c'era l'integrazione delle linee di codice e lo sprint è stato ufficialmente contrassegnato come non riuscito.

In un altro caso abbiamo avuto solo un paio di bug che si presentò all'ultimo minuto, più un paio di cose dalla storia dell'utente. Abbiamo stimato il lavoro totale per tre giorni top e appena ampliato la volata. Questo è stato sufficiente per noi per risolvere il bug, fare un paio di modifiche e facciamo un secondo sprint demo circa tre giorni più tardi.

Quindi, era o opzione 4 o l'opzione 2 per noi quando è stato chiamato per.

Ci sono alcune cose da considerare qui. Prima di tutto, (e sto parlando Scrum terminologia qui, perché sono abituato ad esso, quindi sentitevi liberi di sostituire con qualsiasi cosa si adatta meglio) ottenere lo ScrumMaster, Product Owner e la squadra insieme e discutere apertamente le opzioni. Non credo ci sia un modo per andare. Si può attaccare la metodologia pura, ma nella vita reale che non è sempre il modo migliore per andare. A volte piegare le regole un po 'aiuta molto e rende la vita più facile per tutti.

Se stai lavorando bene insieme si dovrebbe trovare un'opzione che funziona per tutti i soggetti coinvolti. (Se non è possibile si può avere problemi di fondo in ogni caso.) Non solo cadere qualcosa sulla squadra senza almeno parlarne o almeno spiegare le ragioni per le quali.

L'opzione 3 suona come il più disordinato a me, quindi mi piacerebbe escludere che fuori.

Un sacco di persone qui hanno sostenuto che l'opzione 2 va contro agile di base (o Scrum) le regole, ma mi piacerebbe essere in disaccordo. Scrum dice esplicitamente che è possibile estendere la volata, se richiesto, lo stesso che è possibile ridurre le storie o aggiungere risorse. Si consiglia di non farlo fino a quando assolutamente necessario, ma per quanto ne so non è strettamente contro il libro. Nella base quando abbiamo fatto, era la soluzione migliore per tutti, perché abbiamo ancora la volata fatto, solo tre giorni dopo, e tutti erano molto soddisfatti dei risultati. Se stessimo parlando di una settimana o più opzione 2 non sarebbe stato appropriato.

non mi piace molto l'opzione 1. Tenuto roba metà-fatto un'implementazione di lavoro può essere davvero disordinato. Si perde il contatto con il codice che è stato fatto e l'integrazione, francamente, può essere un dolore. Potrebbe essere diverso a seconda del modo di lavorare, ma dalla mia esperienza, prendendo il codice da una codeline non è qualcosa che si desidera fare.

Per quanto riguarda l'opzione 4, è abbastanza dura, ma poi di nuovo, quando sono comunicati in modo corretto dovrebbe essere a posto. Il team di solito sa quando è incasinato e non sarà in grado di fornire, in modo che non è come si sta rompendo tutte le notizie a loro.

Quindi, ci sono alcune cose da considerare.

• Quanto tempo avrà bisogno per avere fatto fare? Se si tratta di solo uno o due giorni, estendendo il vostro sprint potrebbe essere l'opzione migliore.
• Quanto impegno sarà di rimuovere il codice che è già lì? Se è disordinato e prende tempo, risolvere per l'opzione 2 o 4. Se è facile, forse l'opzione 1 è la strada da percorrere.
• Che cosa fa la squadra pensa? Che cosa fa il proprietario del prodotto pensate? Che cosa pensano gli altri? In mancanza di una molla potrebbe avere un impatto sul morale della squadra, ma non potrebbe.

Answer 4

Per un progetto agile, è importante avere una Definizione di "fatto".Questa è una piccola lista di controllo delle cose che devono essere fatte in ordine di classe di qualcosa di così completo.Non è insolito avere livelli diversi di fatto:

• User Story - Questo può includere cose come tutte le attività associato con gli stati UNITI deve essere completa, Tutto il codice è controllato e costruire con successo con il passaggio di unit test, test di Accettazione è stato completato.

• Sprint - Questo può includere cose come tutte le storie per lo sprint che 'si fa' (vedi sopra, una retrospettiva si è tenuto, il proprietario del prodotto, ha visto una dimostrazione delle funzionalità etc.ecc.

• Versione sprint - lo sviluppo della precedente serie di scatti è stato integrato con successo e testata, la funzionalità è stata rilasciata in ambiente live.

In termini delle 4 opzioni è meno evidente.Molto si è detto e si è scritto su ciò che dovrebbe e non dovrebbe essere fatto tutto in mancanza di sprint, estendendo lo sprint e l'esclusione di alcune funzionalità o altro.Trovo che con i progetti agile un sacco di pragmatismo, soprattutto nei primi sprint.

La cosa importante è di non ottenere appeso su di esso.Solo di imparare, adattarsi e andare avanti.

Answer 5

mi piacerebbe prendere una variazione in opzione 1. Se la funzione B può essere suddiviso in ciò che viene completato e ciò che non è completata, questo dovrebbe portare a una nuova serie di compiti da completare per il prossimo sprint. Quello che è finito è consegnato, e mentre la consegna non è perfetto, l'idea dovrebbe essere quello di provare uno di migliori e quindi lavorare su ciò che è prossimo in base alla priorità.

L'estensione del sprint è una ricetta per il disastro alla mia mente. Fa completando la caratteristica significa risolvere tutti i bug su di esso, troppo? Mai visto un software che aveva a zero bug?

In mancanza di sprint introduce troppo perfezionismo nelle cose. È qualcosa che viene fatto inutile il 99%? Io non la penso così, ma ci sono alcune persone che hanno veramente elevati standard e possono essere piuttosto esigente.

EDIT: A volte una caratteristica inizialmente viene dato ai requisiti vaghi che vengono chiarite nel corso dello sprint. Ad esempio, una richiesta di funzione di "Come utente, vorrei effettuare un ordine," può sia essere suddiviso ulteriormente in una pianificazione sprint o durante lo sprint. In entrambi i casi, se sono fatte alcune storie che coinvolgono una caratteristica, questi possono e devono essere presentati presso la demo se si è fatto. Il punto è quello di essere in grado di dire: "Questo è dove siamo. Quanto di una priorità è lì sul finire questo?" come quello che avrebbe potuto essere urgente prima che non può essere così, alla fine dello sprint.

Answer 6

In primo luogo, la regola: iterazioni sono a lunghezza fissa di tempo-box e sono complete al termine del tempo-box. Quindi, questo elimina Opzione 2 e Opzione 3. Per quanto riguarda l'opzione 4, iterazione anomala può verificarsi in circostanze molto particolari (certezza che l'obiettivo non può essere raggiunto, evento esterno invalida l'obiettivo, ...), ma questo deve restare un evento eccezionale. E prima di abortire, ci sono in altre opzioni generali: 1. fare qualcosa di diverso / innovare 2. help Get / outsourcing 3. ridurre la portata. E questo ti lascia con l'opzione 1, la scelta più ovvia.

  

Il problema che vedo con l'opzione 1 è che la squadra non sta dando quello che impegna a. In alcuni casi, può non essere in grado di escludere caratteristica B senza rendere l'intera release inutile (o almeno sostanzialmente meno pregiati). Si può rendere difficile per guidare la direzione del prossimo sprint, senza funzione B.

Se questo è vero, allora o B era più importante di A, D e F e non ha funzionato sugli elementi più importanti in primo luogo, che è sbagliato, non dovrebbe accadere o ... A, D e F sono in realtà molto prezioso in questo caso la tua ipotesi non è effettivamente vero e rimandando B non è quindi un grosso problema. Quindi, basta farlo non appena si rende conto che non sarà fatto e vedere se è possibile sostituirlo con un elemento più piccolo.