bilanciare i vecchi casi con pratiche agili

1

Il mio team sta appena iniziando ad integrare pratiche agili (abbiamo scelto kanban) nei nostri team di sviluppo, test e progettazione, ma abbiamo molti casi di bug e casi di funzionalità non scritti nelle storie degli utenti lasciati dal vecchio sistema e stiamo cercando di trovare un buon modo per prendersi cura dei bug ma mantenere comunque gli sviluppatori che hanno bisogno di rimanere concentrati a testa bassa. per ora abbiamo un nuovo sviluppatore assegnato alle correzioni di bug, quindi il resto può lavorare su nuove funzionalità, ma stiamo cercando il modo giusto per strutturare il team. Abbiamo 7 sviluppatori, 2 tester e 2 designer.

Grazie in anticipo per l'aiuto:)

    
posta Kev 07.05.2013 - 16:28
fonte

3 risposte

8

Posiziona gli elementi del bug sulla tua scheda Kanban come tutto il resto (in ordine di priorità ovviamente) e poi lascia che il team decida chi deve implementare il prossimo elemento in coda.

Credo che la squadra sappia come gestirlo meglio, piuttosto che avere qualcun altro che distribuisca gli articoli tra membri specifici del team. Almeno questo darà loro l'opportunità di auto-organizzarsi. Questo essere agile e tutto.

    
risposta data 07.05.2013 - 16:48
fonte
0

Completa i vecchi casi di bug e le richieste di funzionalità come al solito e inizia lentamente ad implementare il sistema kanban quando arrivano nuovi casi di bug e richieste di funzionalità.

o

Alcuni sviluppatori o altre persone in ufficio creano storie di utenti per i vecchi bug prima di progredire.

    
risposta data 07.05.2013 - 16:49
fonte
0

Ciò che ti manca è un backlog con priorità assoluta e limiti WIP appropriati (limiti di work in progress).

In primo luogo, supponendo che stiate iniziando a utilizzare 3 stati (Aperto / Backlog, In corso, Fatto), il team deve avere un modo per estrarre gli elementi dal backlog in base alle priorità stabilite dal proprietario del prodotto. Non importa se questi sono avanzi dal tempo pre-agile. Tutto deve essere prioritario rispetto a qualsiasi altra cosa, giusto? Quindi raggruppa il tuo arretrato, dando al team la possibilità di scegliere tra i primi del backlog. Inoltre, non importa se gli oggetti sono descrizioni di bug approssimativamente tratteggiate o storie completamente saltate, ciò che conta è che tu abbia una sorta di rappresentazione visiva dell'idea del proprietario del prodotto che il team può lavorare con esso. Passa a un modo più formale di definire questi desideri lungo il percorso (fino a quando alla fine ti ritroverai con solo bug e storie corrette). I bug sono un dato di fatto nello sviluppo del software, quindi considerali come storie quando si assegnano le priorità.

In secondo luogo, dire al team di presentare un numero massimo di elementi che vorrebbero avere in corso allo stesso tempo e lasciare che il team definisca questo come limite iniziale WIP. Questo valore può essere regolato nel tempo a seconda del modo in cui funziona per te.

Sembra anche che tu pensi di sapere meglio come il team dovrebbe organizzare il proprio lavoro (assegnare un nuovo sviluppatore ai bug, mantenere gli altri focalizzati). Ho visto questo tipo di comportamento prima e di solito è un segno di comportamento disfunzionale. La squadra dovrebbe sapere meglio come risolvono gli elementi sulla tavola Kanban, a condizione che agiscano e pensino come una squadra. In questo modo possono massimizzare il rendimento e utilizzare tutti al meglio delle sue capacità. Interferenze dall'esterno (microgestione e simili) possono danneggiare la squadra. Detto questo, ci sono sempre due lati della storia, poiché i team devono crescere e potrebbero aver bisogno di una guida adeguata per ottenere una certa qualità laddove le pratiche agili funzionano in modo efficace. Se hanno problemi a suddividere il lavoro, questo è qualcosa che può essere affrontato come parte di retrospettive / cicli di feedback che sono essenziali per migliorare cose come la distribuzione del lavoro, per esempio.

Ricorda che Kanban si basa sul fatto che il pull del team invece di spingere gli elementi nel team. Infine, in caso di fallimento dell'approccio di un unico grande team, tu e il tuo team potete sempre prendere in considerazione la suddivisione del team in diversi team più piccoli, ciascuno con propri processi e flussi di lavoro Kanban con schede individuali, adattati alle esigenze specifiche del team (ad esempio una squadra di bugfixing , team di funzionalità, team di tester). Alla fine, tu e il tuo team di sviluppo deve governare il processo, non il contrario .

    
risposta data 15.05.2013 - 22:42
fonte

Leggi altre domande sui tag