In buona Scrum, quando e come dovrebbe avvenire l'ideazione e la scrittura di storie? [chiuso]

3

Sembra che la maggior parte degli articoli e dei libri Scrum che ho letto oltre alle conferenze che ho ascoltato abbiano ben poco da dire sul processo di creazione degli articoli nel backlog. In che modo una squadra su un progetto medio o grande (vale a dire più di alcuni membri del team) può creare e dettagliare gli articoli nel backlog? Quando e come dovrebbe avvenire l'ideazione e la stesura della storia? Chi dovrebbe essere coinvolto e quando? Quando i membri del team (a parte il proprietario del prodotto, ovviamente) devono aderire al processo? Quanto della squadra è necessaria?

Nota che non sto chiedendo come un piccolo gruppo possa creare una user story o un altro backlog item da idee. Sto chiedendo di più su quando e come dovrebbe avvenire questa ideazione e la storiografia e chi dovrebbe essere coinvolto. Come possiamo essere più agili negli stadi di ideatore / story story?

    
posta Patrick Szalapski 08.02.2013 - 17:14
fonte

1 risposta

4

La creazione del backlog è definita come un input da scrum. Alcune cose sono dette su come dovrebbe essere, ma non su come arrivarci. Il modo più agile è davvero quello di capire cosa funziona per la tua azienda.

La nostra azienda inizia con un elenco prioritario gigante creato dalla gestione del prodotto con l'input dei proprietari del prodotto. Questo elenco è ad un livello estremamente alto, come un intero nuovo prodotto o una caratteristica principale, alcune dozzine di storie di utenti vale la pena di lavoro distribuite su due o tre gruppi di mischia. Mettono in ordine di priorità quelle caratteristiche in base a ciò che ci farà guadagnare più denaro il prima possibile, o ci impediranno di perdere denaro.

Di tanto in tanto chiedono ai team di mischia una stima molto approssimativa, con una risoluzione di decine di settimane, su quanto ci vorrà. Se tale stima è ampia, ridurrà l'ambito fino a quando non soddisferà le esigenze del cliente o deciderà prima di fare qualcos'altro.

Una volta ogni dieci settimane, assegnano le epop di priorità più alta ai gruppi di mischia. I team li riducono al livello della user story, assegnano punti storia, coordinano le dipendenze da altri team e mettono in ordine le storie. A quel punto abbiamo un "vero" arretrato per squadra. La direzione rivede quell'arretrato per assicurarsi che le pietre miliari più piccole siano appropriate, che soddisfiamo le esigenze aziendali e che le stime funzionano con il loro piano più ampio. Di solito accettano il giudizio delle singole squadre in quel momento. A volte, la creazione dettagliata del backlog rivela problemi che la direzione deve ripensare ai livelli più alti.

Nel nostro arretrato ci sono anche articoli non di grandi dimensioni che i team di mischia creano se stessi basandosi solo sulla guida generale in corso da parte della direzione. Sono cose come bug o problemi di supporto che emergono, strumenti che pensiamo possano contribuire a migliorare la produttività o il refactoring. La regola sul nostro team di scrum è che chiunque può creare una User story per qualsiasi motivo in qualsiasi momento, ma il proprietario del prodotto decide quando è sufficientemente alta la priorità per essere coinvolto in uno sprint.

Abbiamo basato il nostro approccio su Scaling Software Agility di Dean Leffingwell: best practice per le grandi imprese . In realtà è venuto nella nostra azienda e ci ha addestrato quando abbiamo iniziato a lavorare agilmente, ma in una forma veramente agile, abbiamo evoluto i nostri processi per funzionare meglio per la nostra azienda e continuiamo a farlo.

    
risposta data 08.02.2013 - 18:05
fonte

Leggi altre domande sui tag