Lunghezza di sprint consigliata durante l'adozione di Agile?

3

Sono nuovo in una piccola società di sviluppo (una mezza dozzina di programmatori e alla fine dovrebbe diventare probabilmente una dozzina). Abbiamo anche alcuni collaboratori esterni che lavorano con noi (solo per aggiungere un po 'di complicazioni).

Vorrei iniziare lentamente ad adottare Agile o, soprattutto, brevi sprint. Ero curioso di sapere, dalle esperienze passate, cosa consiglieresti che la nostra lunghezza iniziale di sprint (in settimane) sia?

Forse posso persino chiedere fino a che punto è la lunghezza di sprint di un team Agile molto maturo ed esperto (più brevi [2 settimane] o più lunghi sprint [4 settimane])?

Il mio pensiero iniziale era di usare uno sprint più breve, diciamo 2 settimane e poi in tempo, una volta che abbiamo appreso le cose e tutto si è appianato, potremmo semplicemente raddoppiarlo a 4 settimane.

    
posta The.Agile.Manager.2013 12.08.2013 - 15:01
fonte

4 risposte

3

Utilizzare DEFINITEL Sprint più corti.

Due settimane sono molto comuni, ed è quello che ho usato prima.

L'intero punto di agilità è ottenere un feedback rapido e regolare la rotta mentre si procede: più lungo è lo sprint, più a lungo si passa tra le rettifiche di rotta. Soprattutto quando si è appena all'inizio, questo è problematico, perché si può finire per fare la cosa sbagliata per un mese prima di adattarsi.

    
risposta data 12.08.2013 - 15:36
fonte
2

Probabilmente sarebbe meglio iniziare con due o tre settimane. Ricorda, non ti stai impegnando per tutta la vita per l'uno o l'altro, quindi quello che scegli non è critico. Scegli qualcosa, qualsiasi cosa, e resta con lui per un po '. Parla di come funziona nelle tue retrospettive. Una volta che il team dispone di dati sufficienti per prendere una decisione, lascia che prendano questa decisione.

Alcune persone pensano che quattro o più settimane siano un po 'lunghe per uno sprint, anche se altri pensano che sia giusto. Tuttavia, poiché sei appena iniziato, avere sprint più brevi ti consente di dedicare un po 'più di tempo alla pianificazione di riunioni e retrospettive, il che è positivo perché la pratica renderà la tua squadra più strong.

    
risposta data 12.08.2013 - 16:20
fonte
1

Dipenderà dalla capacità del tuo team di adattarsi alla struttura e alla disciplina dello sprint, ma quando la nostra compagnia è passata, abbiamo scoperto che due settimane erano troppo brevi quando ci stavamo ancora adattando al framework. Considera che le prime volte che fai le stime, la pianificazione, le retrospettive, le alzate quotidiane, ecc., Probabilmente impiegheresti più tempo a fare queste cose e scoprirle inizialmente.

Prenderò in considerazione l'idea di iniziare con un'iterazione di 3 settimane e farlo 3 o 4 volte. Una volta che la tua squadra è più a suo agio, potresti essere in grado di ridurla a una iterazione di 2 settimane, oppure potresti scoprire che 3 settimane è la zona di comfort perfetta. I miei primi progetti sono stati eseguiti con iterazioni di 3 settimane, e ho scoperto che erano solo alcuni giorni troppo lunghi per i miei gusti, e di recente sono passati a un intervallo di tempo di 2 settimane e vanno alla grande.

Non raccomanderei di andare a sprint più lunghi dopo esserti sentito a tuo agio, a meno che tu non stia provando a fare diverse iterazioni di 1 settimana molto velocemente per far agitare tutti e poi rallentare fino a un intervallo di 2 settimane. Più spesso rilasci, più feedback ricevi e maggiore è la tua agilità nel cambiare direzione.

    
risposta data 12.08.2013 - 15:42
fonte
1

Avendo implementato Scrum in alcuni team, suggerirei di iniziare con uno sprint di due settimane. Questo perché ti offre molte riunioni retrospettive che ti permettono di identificare e discutere i miglioramenti del processo, in modo da poter affinare rapidamente i tuoi attuali processi Scrum.

Una volta che il team è a suo agio con Scrum e come funzionano le cose (forse 5 sprint) suggerirei alla squadra di provare una sprint di tre settimane, e poi vedere come va nella retrospettiva. Da qui la maggior parte delle squadre che ho visto optano per tenere gli sprint di tre settimane. Dopo alcuni potresti offrire il suggerimento di uno sprint di quattro settimane se ritieni che valga la pena, ma è fondamentale che sia la decisione del team. La maggior parte delle squadre con cui ho lavorato si è stabilita per tre settimane.

Ci sono molti vantaggi e svantaggi a diverse lunghezze:

  • Frequenza di retrospettive e recensioni. 2 settimane consente un feedback più frequente da parte di aziende e team, quindi le priorità della storia possono cambiare, così come i processi di sviluppo all'interno del processo Scrum. In una fase iniziale, le retrospettive regolari sono estremamente utili.

  • Pressione sulla squadra. Con sprint brevi, il rilascio è sempre dietro l'angolo e, a seconda degli individui del team, gli sprint di 2 settimane possono essere molto stressanti. D'altra parte 4 settimane (o più lunghe) possono portare a rilassarsi all'inizio. Questo è il motivo per cui personalmente preferisco 3 settimane di sprint una volta che la squadra è stata risolta.

  • Unforseen Complexity. Se un'attività è più grande del previsto, un breve sprint rende più difficile recuperare il tempo perduto. Questo può portare a non consegnare tutto ciò che è stato fatto e potenzialmente demoralizzare la squadra. Questo è più applicabile in piccoli team.

  • Il ritmo. Finché gli incontri sono ben eseguiti, gli sprint più brevi forniscono un buon ritmo alla squadra, mentre può essere più difficile entrare nel solco quando si ha solo un incontro di quattro settimane.

  • Achievement. Con sprint di 2 settimane, la fine dello sprint potrebbe non essere particolarmente speciale. Con sprint più lunghi, ottieni un vero senso del successo e una ragione per festeggiare. Trovo che le squadre si sentano ancora come se fosse una festa con uno sprint di 3 settimane.

risposta data 23.08.2013 - 17:07
fonte

Leggi altre domande sui tag