Come includere la stima e il suo effetto sulla prioritizzazione con Kanban?

2

Ho letto diverse fonti su Kanban. Utilizzando la descrizione di Atlassian come la mia principale fonte di informazioni su come funziona, mi chiedo come gli effetti delle stime sulla prioritizzazione dovrebbero essere incluso nel flusso.

La descrizione menzionata suggerisce una tavola Kanban con queste corsie:

  1. Da fare
  2. In corso
  3. Pronto per la revisione
  4. Fatto

Il proprietario del prodotto si assicura quindi che tutto nella corsia 1 abbia la priorità. Tuttavia, la priorità spesso dipende dallo sforzo stimato (qualcosa potrebbe ottenere un prio più elevato se è disponibile una soluzione rapida, respinta se risulta essere molto lavoro, ecc.) E la stima (a) prende il tempo e (b) è fatto meglio da quelli che faranno il lavoro.

Ho familiarità con Scrum, dove il team si siede per stimare i tempi stabiliti. Non esiste una cosa del genere con Kanban a quanto pare. Come funzionerebbe normalmente? Riesco a vedere diverse opzioni:

  • Il PO indovina e il team impara a fornire un feedback se le ipotesi sono disattivate;
  • Introduci uno "Lane 0" con "To Estimate";
  • Il PO si mescola stimando se stesso e interrompendo il lavoro di un membro del team per ottenere un preventivo;
  • Introduci momenti fissi per le stime (ad esempio 0900 e 1300 ore);

Ho cercato e ho trovato alcune opinioni come questo uno ("la stima è facoltativa"), ma Sono curioso di sapere se c'è qualche consiglio canonico?

    
posta Jeroen 22.10.2015 - 15:56
fonte

2 risposte

2

Una delle cose che Agile cerca di raggiungere è il concetto di "farlo battere parlando di farlo", stimare è una di queste cose in cui passi troppo tempo a preoccuparti di quanto tempo ti ci vorrà per fare qualcosa se alla fine sei andato avanti e l'hai fatto. E in generale, qualunque sia la tua stima, ti sbagli a prescindere!

Quindi stime di scarto.

Kanban può dirti il tempo di ciclo per le attività che hai eseguito, e puoi tracciarli su un grafico per ottenere una curva di distribuzione delle ore effettivamente prese (cioè da quando il biglietto è stato posizionato sulla scacchiera in corso a quando è stato rimosso).

Dennis Stevens suggerisce la t-shirt dimensionamento i tuoi compiti per capire se eseguire o meno, ma la t-shirt è un'attività di 10 secondi nella maggior parte dei casi - se ti chiedo quanto è grande un compito, sarai in grado di dire "banale", " sulla media "o" mhmhmhmhhh .. questo ti costerà g'vnor ". Sprecare tanto a lungo in questo tipo di processo, e poi continuare a lavorare su quelle attività. Non cercare di stimare ogni attività, solo quelle di cui ti preoccupi.

Con Kanban penso che la risposta canonica sia questa: non preoccuparti delle stime.

Per prioritizzazione, esiste un concetto in Kanban chiamato Classi di servizio che è possibile utilizzare per le attività che si desidera modificare per la priorità per - se qualcosa non è una priorità (un'attività che è lunga ma importante è ancora importante, un compito che è rapido ma non importante non è ancora importante dopo tutto) puoi metterlo come compito lento o intangibile che verrà eseguito dopo che tutte le attività con priorità più alta sono state completate e qualcuno ha tempo da dedicare all'attività .

    
risposta data 22.10.2015 - 16:28
fonte
1

La tua squadra dovrebbe fare regolarmente perfezionamento del backlog indipendentemente dal fatto che tu sia " stai facendo kanban o mischia. Ciò includerà la squadra che fornisce un certo livello di stima. Provare per un dimensionamento relativo (valori di Fibonacci) in un primo momento per fornire informazioni sufficienti per consentire al Product Owner di stabilire le priorità senza spendere troppo tempo nel preventivo.

Una volta che l'ordine di acquisto ha delle stime, dai un'occhiata a Ponderato il lavoro più breve prima per aiutare a stabilire le priorità. Questo metodo dovrebbe eliminare alcune delle ipotesi di risoluzione delle priorità.

    
risposta data 22.10.2015 - 16:36
fonte

Leggi altre domande sui tag