come possiamo avere una persona per assegnare e tenere traccia delle attività nello sviluppo agile

Affronta questo problema con le seguenti tecniche:

• Mischia giornaliera per esaminare i progressi. Se le persone non stanno facendo progressi a un ritmo ragionevole diventerà più ovvio per tutti i giorni.

• Se si sospetta un problema, il product manager o il line manager possono rivedere le storie recenti e i loro punti e vedere se c'è un problema che persiste nel tempo.

• Retrospettive continue per scoprire il problema più profondo e le dinamiche di squadra che ostacolano il progresso. Ci sono spesso problemi nascosti che rallentano il progresso.

• Metti un membro a basso rendimento in fase di revisione e se non è in grado di fornire quello che è considerato il minimo, dopo averlo esaminato diverse volte. Mai un'opzione piacevole ma dovrebbe essere considerata un'opzione in casi estremi.

L'adozione di Agile dovrebbe essere una decisione di squadra. Si basa in gran parte sui membri del team per fare stime best-effort sull'ambito / sforzo per un'attività. Se devi forzare ad assegnare compiti agli sviluppatori per ottenere risultati, questo tipo di sconfigge lo spirito dello sviluppo Agile.

Per rispondere direttamente alla tua domanda, puoi farlo con un insegnante di mischia o uno sviluppatore senior che detta questo, ma non dovrebbe.

Sembra che tu sia all'inizio di un viaggio agile. È compito dello Scrum Master far rispettare le regole di Scrum, che è esattamente ciò di cui hai bisogno in questa fase. Nel corso del tempo il team migliorerà nel discutere e distribuire le attività, ma avrà bisogno di alcuni incoraggiamenti per iniziare.

Come scrum master in questa situazione vorrei:

1. Garantisci che le storie siano suddivise in attività di meno di mezza giornata di lavoro per una persona e stimate in ore alla pianificazione dello sprint. Ciò significa che tutti possono vedere la progressione (o nessuna) rapidamente e chiaramente su base giornaliera.

2. Assicurarsi che durante lo stand up ogni membro del team si impegni a consegnare una quantità adeguata di lavoro. Se non lo fanno, chiedi loro perché non si impegneranno a fare di più, e non permettergli di evitarlo a meno che non ci sia una ragione valida. Questo è il punto cruciale del problema. Con una squadra con cui ho lavorato in passato, abbiamo persino contrassegnato le nostre attività giornaliere impegnate con un punto, in modo che potessimo vedere se venissero consegnati il giorno successivo.

3. In caso di stand-up il giorno successivo se le persone non hanno rispettato il loro impegno, convincili ad aggiornare la stima per quanto tempo pensano di rimanere. Chiedi perché non è stato completato e offri aiuto dagli altri, ma assicurati di farlo con preoccupazione, non con rabbia. Non trasferire i compiti ad altre persone, ma offri loro tutta l'assistenza di cui hanno bisogno da altri sviluppatori che potrebbero aiutarti.

4. Utilizza il grafico di burn-down come punto di discussione in stand-up e chiedi al team come possiamo (non loro) ottenere la storia con priorità assoluta (o l'obiettivo di sprint), ma non assegnare il lavoro a loro stessi. Non dovresti davvero ottenere grandi risultati se le stime sono ok e stai seguendo i passaggi precedenti, ma se lo fai è un punto di discussione per la retrospettiva. Sono distrazioni? Era troppo lavoro nello sprint? E 'stato un lavoro rischioso a cui non hai pensato abbastanza? Assenza? Impara da esso.

Non penso che dovresti assegnare compiti più formalmente di questo, ma nelle fasi iniziali è importante tenerne traccia. Spetta a te collegarlo alle persone (i nomi delle attività), ma preferisco non farlo in quanto incoraggia l'input del team in un'attività e una mentalità meno individuale, e riduce anche la sensazione di essere monitorato come sviluppatore.

Uno dei principi di un team agile è quello di estrarre attività, non assegnarle!

Scusa, ma IMHO non hai una squadra agile. Puoi buttare fuori dal team quelli che non lo vogliono o lasciarli cadere.

L'ultimo tentativo potrebbe essere quello di lasciare che decidano: vuoi che ti piaccia ritirare un'attività che ti si adatta meglio o dovrei assegnarti il compito peggiore che riesca a trovare?

Se non funziona, è finita.

Dovrebbe esserci qualcuno che istruisce e aiuta i programmatori del team a comprendere e aderire alle pratiche agili del team e quindi a renderli responsabili per questo.

Questo è l'unico modo per avere un vero team agile autosufficiente e autogestito.

Don't address the symptom, address the problem instead.