Un backlog di attività "morso di dimensioni" in parallelo al backlog di funzionalità "principale"?

Parlerò di alcuni punti che, si spera, ti aiuteranno a trovare la tua strada:

1. " SCRUM " significa essere agili. È necessario il buon senso. Se il cambiamento è di pochi minuti, non penso che sia necessario un backlog per questo. Se sono più di 2 ore, penso che dovresti pensarci due volte. Non tutto ciò che è un "facile vincere" dovrebbe essere fatto. In SCRUM lavori per priorità. Penso che l'OP debba ottenere le informazioni su ciò che guadagni dall'addizione e dallo sforzo necessario. Solo allora l'OP può decidere se è importante o meno. Passare a SCRUM, a volte viene fornito con un sacco di domande e gli sviluppatori diranno spesso "ma, ci vorranno solo poche ore". E allora? Poche ore sono il tempo, non tutto ciò che è breve deve essere incluso.
2. Una volta ho lavorato a un progetto in cui avevamo "backlog di progettazione" . Questo arretrato conteneva elementi suggeriti dagli sviluppatori per migliorare il prodotto. Questi elementi non avevano un valore utente esplicito (ma avevano un valore utente implicito). Ad esempio: refactoring di un componente nel codice. Avevamo descritto il cambiamento, lo sforzo e il guadagno (in questo caso non è possibile presentare nulla all'utente, ma se tale refactoring provoca lo sviluppo di nuove funzionalità più rapidamente, allora è sicuramente un guadagno per l'utente). La nostra OP ha deciso che durante la versione dovremmo investire il 10% di ogni sprint (in media) su tali articoli. Prima di ogni sprint, quando l'OP decideva sull'arretrato dello sprint, si assicurava di avere il 10% di elementi arretrati. Quindi 2 versione backlog - > 1 sprint arretrato.
3. Buffer - Quando si inizia a lavorare in SCRUM, le persone dimenticano spesso che, come ingegneri del software, ci lasciamo in un mondo di incertezze. Va bene contare 1 giorno di lavoro come 6 ore invece di 8. Diciamo che hai uno sprint di 15 giorni, questo significa che hai 30 ore in più che vanno alle riunioni, alle cose che hanno richiesto troppo tempo e sì - anche per quelle piccole cose che sono troppo piccole per ricordare, ma fanno parte del nostro lavoro quotidiano di 2 giorni.
4. Rimani concentrato - Ultimo ma non meno importante, in SCRUM è importante rimanere concentrati. Decidi quanto del tuo sforzo totale, e qual è la priorità, di investire in tali compiti e ricorda di investire questo tempo e amp; sforzo. Non andare alla deriva a lavorare su "piccole cose" solo perché sono piccole. Hai un PO per aiutarti a decidere e hai il buon senso.
5. Stay Agile - E, alla fine, non dimenticare di provare metodi diversi per affrontare il problema, chiediti se è davvero il modo migliore. Migliora la strada.

Buona fortuna:)

I framework di programmazione come Agile e SCRUM sono progettati per applicare disciplina e struttura allo sviluppo. Tuttavia, la disciplina e la struttura sembrano essere i contrari del divertimento e della creatività. In genere, è necessario lavorare di più per stabilire e mantenere la disciplina. È molto difficile trovare un equilibrio tra questi concetti opposti. Pertanto, i framework tendono ad evitare l'argomento.

Nel mio ultimo progetto, abbiamo osservato che gli sviluppatori avevano bisogno di un po 'di tempo ogni giorno per rinfrescare o chiarire la testa, ecc. Avevano un tempo di budget (.5 ore / giorno o 2.5 ore / settimana) in cui potevano fare qualsiasi cosa, all'interno della ragione (con la possibilità di essere applicata a qualcosa sul posto di lavoro). Per mantenere le cose disciplinate, è stato chiesto loro di documentare le loro attività in modo che potessero ottenere credito per qualsiasi risultato, ecc. Avere un budget specifico per "il barattolo di caramelle" si adattava alle nostre scadenze e impediva che le cose sfuggissero.

Btw, abbiamo definito il nostro "coolness del progetto" e si è rivelato essere la fonte di molte buone idee e miglioramenti in quell'azienda.

Devi mantenere le piccole storie nel backlog principale.

Affronto problemi simili a quello che stai descrivendo, anche se non sto usando la mischia. Vedo che affronti sfide di prioritizzazione e efficienza .

Sembra che sotto il tuo "vecchio modo", chiunque fosse implicitamente autorizzato a rendere il loro compito l'attuale "massima priorità" se visitava l'ufficio di uno sviluppatore. Questo ha alcuni vantaggi. Il richiedente ritiene di ricevere una risposta, e sia il richiedente che lo sviluppatore ottengono una "vittoria rapida".

Il lato negativo è che l'inserimento frequente di queste attività tende a rallentare o far deragliare le attività prioritarie che erano state concordate con il proprietario del prodotto. (Nota a margine, spesso tutti sottostimano la quantità di tempo necessaria per queste "correzioni".)

La mia esperienza è che il tentativo di spremere un compito a bassa priorità mina i vantaggi della definizione delle priorità. Come sviluppatore, la definizione delle priorità mi convince che sto lavorando a ciò su cui il product owner vuole che io lavori. Il proprietario del prodotto deve decidere se intende svolgere il lavoro extra e rischiare (anche se in modo lieve) di piegare una richiesta "carina da avere".

Spesso quando chiedo alle parti interessate di dare la priorità, mi viene chiesto "Puoi semplicemente spremere questo?". Il desiderio implicito è per me di completare magicamente il nuovo compito senza influire sulla priorità più alta attuale.

Ciò che spesso mi succede è che le parti interessate richiedono LargeImportantProject e SmallLessImportantTask. Il dilemma è, dovrebbe SmallLessImportantTask attendere che LargeImportantProject finisca (o abbia un roadblock)? Ci sono dei compromessi e la mia esperienza è stata che il proprietario del prodotto deve decidere. (Se il proprietario del prodotto non decide, il team di sviluppo deve indovinare.)

Un obiettivo della mischia (e la gestione del progetto in generale) è di evitare i blocchi stradali per i compiti con priorità più alta. Man mano che diventi più efficiente, c'è meno spazio per spremere il lavoro extra "bello da avere".

L'efficienza può essere spaventosa, ma ho visto che i benefici superano il costo in due modi importanti.

1. Man mano che diventi più efficiente, aumenti la capacità del tuo team di completare un lavoro prezioso, che include richieste "belle da avere".
2. Se una richiesta è davvero un "bello da avere", è probabilmente perfettamente legittimo che la richiesta attenda che vengano prese in considerazione altre priorità aziendali importanti.

Secondo me; il tuo problema è il modo in cui le attività sono prioritarie nel backlog. Ad esempio, "priorità" potrebbe prendere in considerazione sia l'importanza che la rapidità con cui può essere completata. Qualcosa che non è così importante ma può essere completato in 10 minuti può avere una priorità più alta di qualcosa di più importante che richiederà diverse settimane per essere implementato.

Ho lavorato in agile per un po 'ora. Tutto quello che posso dire è questo: ci sono situazioni in cui insistere su una metodologia e tutto ciò che incorpora, è assolutamente sbagliato. Devi essere AGILE, e modificare una metodologia per situazioni specifiche è, IMO, un must.

Come Avi sopra detto - "SCRUM" significa essere agili. È necessario il buon senso. Se il cambiamento è di pochi minuti, non penso che sia necessario un backlog per questo.

Se il cambiamento richiede tempo, significa che non è tutto ciò che è "innocuo" e dovrebbe essere ben documentato.

In base alla tua domanda iniziale e ai successivi chiarimenti, questo è quello che ho percepito che i tuoi punti di dolore sono

• Requisiti che cambiano costantemente
• Impossibilità per gli sviluppatori di concentrarsi su altre aree dell'applicazione, es. siamo eroi su una parte dell'applicazione ma non desideroso di toccarne un altro.
• Diversi approcci all'architettura, soluzioni, strutture adottate
• Il processo di raccolta dei requisiti non sembra funzionare

Scrum, se inizialmente rispettato correttamente dovrebbe risolvere molti di questi problemi e, cosa ancora più importante, portare altri problemi in primo piano che dovrebbero essere risolti.

- Requisiti in continua evoluzione

Avere un unico arretrato in cui tutto è inserito e ordinato in modo corretto dovrebbe significare che il team non dovrebbe sopportare il peso dei requisiti che cambiano mentre si è nel mezzo dello sviluppo. Se si tratta di un ambiente molto dinamico, gli sprint più piccoli di 1 o 2 settimane dovrebbero garantire che le mutevoli priorità possano ancora essere facilitate in un periodo di tempo relativamente breve.

- Impossibilità per gli sviluppatori di concentrarsi su altre aree dell'applicazione, es. siamo eroi in una parte dell'applicazione ma non desiderosi di toccarne altri.

Un team di mischia che lavora bene insieme e si sostiene l'un l'altro, con una spinta specifica verso la condivisione delle conoscenze all'interno del team e cercando la sfida di lavorare su altre parti dell'applicazione cercherà di garantire che la conoscenza dell'applicazione venga condivisa. Alcune pratiche come la paia di programmazione possono aiutare le persone a superare la loro paura di lavorare su un codice che non hanno familiarità con l'apprendimento e la condivisione di quella conoscenza. Questo potrebbe richiedere alcuni sprint prima che la conoscenza dell'applicazione venga distribuita tra i team e le persone si sentono a proprio agio lavorando su qualsiasi area dell'applicazione. Inoltre, consentire alle persone di svolgere compiti di un consiglio, cioè fare la propria scelta su ciò che vorrebbero lavorare, può incoraggiarlo.

- Diversi approcci all'architettura, soluzioni, strutture adottate

Scrum facilita una comunicazione migliore, facilita il lavoro di squadra e migliora il processo decisionale, oltre a fornire una maggiore visibilità su ciò che sta accadendo. Questo è il turno dovrebbe facilitare le decisioni organizzative sull'uso di framework, soluzioni architettoniche, ecc. E l'uso di un meccanismo Scrum of Scrums può aiutare a instillarlo in tutta l'organizzazione.

- Processo di raccolta dei requisiti

Anche in questo caso, se si rispettano rigorosamente le regole, se un requisito non è chiaro e pronto per consentire al team di comprendere e stimare ciò che è necessario per soddisfare il requisito, non dovrebbe essere portato nello sprint. Prendi un altro requisito che è una priorità elevata ed è stato ben definito ... perché poi sai che sarai in grado di consegnarlo! Anche se non è in grado di correggere immediatamente il processo di raccolta dei requisiti, imporrà la modifica necessaria per ottenere quel processo risolto.

Per rispondere alla tua prima domanda, no, non ci dovrebbero essere due backlog separati. In qualsiasi momento, è nell'interesse di tutti che gli sviluppatori e l'organizzazione stiano lavorando per primi agli elementi con la priorità più alta. Le priorità dovrebbero essere principalmente basate sul valore aziendale, ed è del tutto possibile che molte piccole modifiche e richieste aggiungano valore commerciale. Lascia che sia il proprietario del prodotto a decidere.

Sono stato uno Scrum Master per oltre 7 anni e ho contribuito all'introduzione di Scrum in diversi team e società. A mio modesto parere e dalle mie osservazioni, sento che se Scrum viene introdotto per la prima volta nella vostra organizzazione, seguitelo con il libro. Non deviare Scrum richiede disciplina per essere in grado di attenersi alle pratiche e ai processi. È troppo facile fare eccezioni per adattarsi a determinate circostanze e, se fatto troppo presto, condurrà all'erosione di benefici e valori che porta con sé. Fai le basi, fallo davvero bene. Diventa un esperto nel fare le basi e capire perché sono lì, e quindi cambiare il processo per adattarlo meglio e guidare il miglioramento continuo all'interno della tua organizzazione. La deviazione dai processi e dalle pratiche di base può essere un meccanismo per nascondere alcuni altri problemi oi problemi sottostanti esistenti nell'organizzazione [probabilmente il motivo principale per cui Scrum viene introdotto].

Ci sono casi molto validi per dire che questo è "Agile", quindi dobbiamo essere disposti a cambiare il processo, ma c'è una differenza significativa tra un team auto-diretto e auto-organizzante che comprende il processo e discute le modifiche che potrebbero essere fatto al processo, al contrario di una squadra che sta solo iniziando a percorrere il sentiero di Agile o Scrum. È come provare a correre prima che tu sappia eseguire la scansione ...