Quali sono le categorie più comuni per le schede Kanban e Scrum JIRA? [chiuso]

6

Un sistema minimale tipo Kanban ha tre posizioni per le carte: "Da fare", "In corso", "Fatto". Come ho visto Scrum e Kanban sul web, sono forse cinque o sei categorie.

Quali sono alcune delle opzioni più comuni per le categorie per le schede Kanban e Scrum JIRA?

    
posta JonathanHayward 24.09.2013 - 05:19
fonte

1 risposta

7

Supponendo Kanban (poiché penso che la risposta sia meno rilevante per un processo Scrum), le corsie che dovresti usare dipendono da preoccupazioni organizzative e forse dalla tua definizione di fatto. Probabilmente inizierai a vedere un ovvio bisogno di cose mentre inizi a lavorare su questioni organizzative o aziendali che vanno oltre i semplici problemi di sviluppo.

Nella mia attuale organizzazione, ci sono "Ready for Acceptance", "Ready for Release" (aka Accepted) e "Released", perché consideriamo il Product Owner l'accettazione di una storia come un gate importante, e non sempre una cosa istantanea a seconda degli altri obblighi del PO con il business. Non disponiamo ancora di un meccanismo di distribuzione continuo, quindi abbiamo anche una corsia per le cose che devono essere parte di un evento di rilascio e potrebbe esserci un po 'di lavoro da parte nostra associato a questo. Quindi abbiamo "Rilasciato", soprattutto per il vantaggio di riconoscere i progressi.

In un'altra organizzazione, Kanban non era il nostro processo principale, ma avevamo bisogno di gestire molte parti mobili che lavoravano attraverso più porte organizzative, dato che stavamo servendo un business biotech altamente regolamentato. Alcuni articoli erano "In corso", intendendo nelle mani dello sviluppatore, ma dovevano essere passati attraverso una "revisione di uno scrittore tecnologico", uno sforzo di "test" da parte di un team di test del software tradizionale e di Quality Assurance. (La distinzione era una questione di standard di settore: nella produzione tradizionale, il controllo qualità assicura che i processi funzionino come documentato, mentre il "test" è una questione di controllo di qualità, il nostro software doveva passare attraverso un processo di controllo qualità perché avevamo l'approvazione della FDA che abbiamo seguito le nostre documentate Good Manufacturing Practices come originariamente documentato alla FDA anni fa). In altre parole, anche se l'organizzazione del software praticava meccanismi di abilitazione per lo sviluppo agile come l'integrazione continua, i test automatici di unità e integrazione, e così via, vari vincoli commerciali dovevano destreggiarsi tra preoccupazioni organizzative esterne che ricordavano più il progetto in stile legacy gestione. Quando il nostro team di sviluppo stava cercando di destreggiarsi tra più prodotti di lavoro (nuove funzionalità, rilascio di vecchie funzionalità, problemi organizzativi e tecnici che a volte riguardavano più iterazioni Scrum), abbiamo essenzialmente abbandonato Scrum in modo da poter dare visibilità a ciò che stavamo facendo non era lo sviluppo, e assicurarsi che tutto è stato fatto. Quando il nostro lavoro era meno dipendente dagli interessi esterni, abbiamo usato di nuovo la gestione del progetto Scrum in stile più tradizionale.

Se fossi in una piccola squadra e avessi pochi stakeholder esterni, probabilmente manterrei la mia board piuttosto semplice. "Ready to pull", "In progress", "Release to Production" si sentirebbero proprio bene, ma non mi sorprenderebbe se il proprietario del prodotto avesse bisogno di una corsia per rivedere il lavoro prima di rilasciarlo alla produzione. E in alcune organizzazioni, dove una nuova funzione non è disponibile per tutti finché non sono stati raccolti alcuni dati su come i clienti reagiscono o su come si adatta alla produzione, non mi sorprenderebbe vedere una corsia come "In A / B testing "o" Rilasciato al 10% degli utenti "seguito da" Rilasciato a tutti i clienti ".

Abbiamo anche alcuni elementi di corsia non di spedizione come "debito tecnico", e a volte riconosciamo che una storia contiene criteri di accettazione inadeguati, contraddice altri criteri esistenti per caratteristiche precedenti, o ha alcune conseguenze impreviste che richiedono ulteriori discussioni o revisioni prima cowboying e scrivere codice potenzialmente irrilevante. In questi casi, abbiamo una scatola che, se le cose funzionano bene, verrà visitata solo brevemente, con l'etichetta "In attesa".

Quindi la lezione è semplice: scopri di cosa ha realmente bisogno la tua squadra e traccia le corsie.

    
risposta data 24.09.2013 - 06:36
fonte

Leggi altre domande sui tag