Ridurre i lavori in corso: qualcuno dovrebbe davvero scegliere un'attività?

2

Sono in un ambiente di Scrum e riceviamo feedback dall'OP che tutte le storie dovrebbero essere chiuse attualmente in corso prima di inserire più storie. L'obiettivo è ridurre il WIP e far accettare le storie, il che è un buon obiettivo. Ma sarebbe davvero saggio avere, ad esempio, un DBA che esegua uno script di test manuale per chiudere una storia particolare, quando il part timer che fa varie attività "grunt" sarà disponibile domani? Sembra che questa sia la direzione che il nostro PO vuole dirigere, ma mi sembra inefficiente. Quello che succede è che domani il part time è disponibile, ma non ci sono compiti per loro, gli unici in circolazione "al di sopra del loro livello di retribuzione".

Quindi sembra una tensione tra la riduzione del WIP e il fatto che la gente lavori su cose che "hanno senso". Trovi che sia meglio per il team far lavorare qualcuno su qualsiasi compito? O continui a lavorare più a lungo per far sì che certe persone facciano ciò che sanno fare meglio?

    
posta Andy Wiesendanger 23.03.2011 - 16:26
fonte

3 risposte

3

Il motivo per limitare il WIP è aiutare il flusso di lavoro attraverso il sistema più rapidamente. Ciò ti consente di ottenere feedback sul fatto che il lavoro che stai facendo sia prezioso. L'apprendimento potrebbe venire dal metterlo in mostra, dal metterlo in opera, dalla distribuzione, ecc. Questo apprendimento potrebbe giocare anche in altri lavori imminenti.

Il lavoro più lungo si blocca senza ottenere questo feedback, più possibilità avrai di creare un lavoro che dovrai annullare, più tardi.

Questo è il motivo per cui il DBA dovrebbe riprendere il compito dello script, non solo perché vogliamo chiudere la storia, ma perché vogliamo ricevere rapidamente un feedback, piuttosto che aspettare e iniziare qualcos'altro che potrebbe essere inutile. Il tuo part-timer può quindi accoppiarsi con altri sviluppatori esperti il giorno successivo, il che lo aiuterà a migliorare le sue capacità (e il suo livello retributivo) in modo che possa aiutare il team in modo più efficace in futuro.

    
risposta data 23.03.2011 - 20:57
fonte
2

È molto più facile dire "sì, chiunque dovrebbe riprendere il prossimo compito" quando hai a che fare con un gruppo di generalisti. Non appena porti uno specialista (e un DBA è sicuramente uno specialista) diventa più una questione di ciò che funziona per la tua situazione e il tuo team.

Se il DBA è più simile a un DBA / programmatore di quanto probabilmente dovrebbe raccogliere qualcosa. Tuttavia, avrei anche altre schede DBA pickup (non DBA). Ciò consente a più di una sola persona di acquisire esperienza in una particolare area. Vorrei anche che la persona che lavora sulla carta si assicuri di comunicare / consultare il DBA (o chiunque sia l'esperto del dominio) per qualsiasi carta che prelevano.

    
risposta data 23.03.2011 - 17:27
fonte
0

Ho provato la scheda di progetto AgileZen.com . È possibile impostare un limite su diverse fasi. Per il mio progetto personale, ho limitato il livello "In corso" a solo 2 piani (durata limitata dell'attenzione). Una storia potrebbe essere "In corso" e poi tornare a "On Deck" se è necessario spostare un'altra storia nella fase "In corso", ma non si può semplicemente fare qualsiasi tipo di lavoro a metà tra spostalo su 'Completato'. Seriamente, vuoi ridurre il WIP senza fare lavori di qualità? Può essere difficile fare entrambe le cose e qualcuno dovrebbe spingere per il progresso, ma non ci dovrebbero essere molti incentivi per sacrificare la qualità o sprecare tempo.

Suppongo che se il DBA nel tuo caso non ha altro da fare che scherzare con uno script di test manuale, perché no? Consideralo un'esperienza di apprendimento. La cosa peggiore che può succedere è che il part-timer arriva domani e guadagna tutto.

    
risposta data 23.03.2011 - 17:30
fonte

Leggi altre domande sui tag