Un arretrato di attività "di dimensioni ridotte" in parallelo all'arretrato di funzionalità "principale"?

Dopo oltre due anni di lavoro in una struttura del dipartimento di sviluppo "lupo solitario" altamente silente, stiamo adottando Agile SCRUM. Grande. Mi piace Agile; come sviluppatore ti mantiene concentrato, impegnato e produttivo senza avere una miriade di parti interessate che spingono il progetto dopo il progetto in gola con l'aspettativa che siano state fatte ieri.

Vi è, tuttavia, un aspetto del passaggio a SCRUM rispetto al nostro attuale "modello", che penso che le persone al di fuori dello sviluppo non apprezzeranno minimamente. Questa è la loro attuale capacità di farci fare piccoli cambiamenti "mentre aspetti". Gran parte del nostro sviluppo è destinata esclusivamente al consumo interno e siamo quasi tutti nello stesso edificio. Quindi, è pratica comune da anni che un responsabile di reparto o un manager altrove venga dal "proprietario della base di codice" di una particolare applicazione e chieda piccole cose (a volte non così piccole, ma siamo abbastanza bravi a non accettare tre- progetti settimanali basati su questi "drive-by"). Perfino il nostro capo a volte inoltra cose che gli sono state fatte in questo modo. Molto spesso, se stiamo lavorando nella base di codice in questione al momento, possiamo semplicemente far apparire il file sorgente,

Con una metodologia SCRUM Agile di base, queste modifiche verrebbero registrate come difetti (non abbiamo soddisfatto un requisito specificato in una storia precedentemente consumata) o nuove piccole storie (abbiamo soddisfatto tutti i requisiti dichiarati, ma tali requisiti erano incompleti, vaghi o errati o sono cambiati dopo la consegna dopo che gli utenti hanno visto le nuove funzionalità). In entrambi i casi, la stragrande maggioranza sarebbe uno puntatori a maggior parte se non zeri, e relativamente bassa priorità (il sistema è utilizzabile nel suo stato attuale, ma sarebbe così molto più fresco se ...), rendendoli difficilmente essere portato in uno sprint quando si lavora il backlog dall'alto verso il basso.

Questa possibilità è stata sollevata in una riunione degli sviluppatori come fonte di opposizione attiva al nostro processo Agile da parte di altri dipartimenti, che lo vedrebbero meno "agile" della nostra attuale capacità di apportare piccole modifiche su richiesta. È una preoccupazione valida dell'IMO; gli stakeholder dietro l'OP non sono sempre d'accordo su quali siano le cose più importanti, perché non hanno tutti lo stesso punto di vista, tuttavia in genere sono solo i manager che prendono la decisione finale, e quindi il loro pregiudizio è quello che viene visualizzato nel backlog del prodotto.

Fu quindi proposta una soluzione, che fu provvisoriamente chiamata "barattolo di caramelle" (un altro termine buttato fuori era la "salsiera"). Piccole modifiche richieste dai "ragazzini" nei vari reparti, che non sono difetti in una storia esistente, che sono stimati per consenso o acclamazione all'interno del team a richiedere meno della metà di una giornata di sviluppo e che avrebbero un impatto immediato, significativo, positivo sull'esperienza dell'utente secondo l'opinione dell'utente finale, viene inserito in un elenco parallelamente al backlog primario. Sarebbero identificati come "storie", ma sarebbero tenuti separati dal principale arretrato di "grandi" storie soggette a priorità. Se, in qualsiasi momento durante il normale progresso di uno sprint, stiamo lavorando in un'area del sistema in cui è possibile effettuare una di queste modifiche, rendendo il tweak banale, possiamo portare il tweak nello sprint e codificarlo insieme alla storia più grande. Facendo questonon deve mettere a repentaglio il completamento della trama più grande o di qualsiasi altra opera impegnata. L'OP avrebbe anche accesso a questo elenco e se stessero lavorando su una storia utente in arrivo toccando la funzionalità di base che coinvolge la modifica, potrebbero inserirla nella storia come requisito e quindi soddisferemmo il requisito come faremmo altro. Questo, si pensava, avrebbe reso più probabile la modifica delle modifiche prima o poi.

Ciò ha innescato la reazione tra quelli di noi con l'addestramento ScrumMaster di "uh-uh". C'è un arretrato. Due arretrati introducono la domanda su quale oggetto numero 1 sia davvero il più importante, quali elementi dell'elenco determinino la velocità reale e in quale dei due arretrati una storia appartenga effettivamente (qualsiasi demarcazione di dimensioni / complessità avrà alcuni casi che ricadono relativamente arbitrariamente da una parte o dall'altra). "Lascia che il processo funzioni", abbiamo detto; se il cambiamento è davvero significativo per gli utenti finali, faranno abbastanza rumore da convincere i responsabili del reparto a prendere decisioni in termini di tempo / denaro, e si imbatteranno nella coscienza del team di sviluppo verso la parte superiore dell'arretrato.

Ho pensato di porre la domanda a terra: secondo te, un elenco parallelo di storie di "dimensioni ridotte" avrebbe valore nell'ottenere più rapidamente piccoli cambiamenti utili, ma a bassa priorità, o nel complesso è una decisione migliore piegarli nel backlog principale e lasciare che il processo di base gestisca la loro inclusione in uno sprint?

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 è un cambiamento di pochi minuti, non credo che tu abbia bisogno di un backlog per questo. Se sono trascorse più di 2 ore, penso che dovresti ripensarci. Non tutto ciò che è "facile da vincere" dovrebbe essere fatto. In SCRUM lavori per priorità. Penso che l'OP debba ottenere le informazioni su ciò che si guadagna dall'aggiunta e dallo sforzo necessario. Solo allora l'OP può decidere se è importante o meno. Passando a SCRUM, a volte arrivano molte domande e gli sviluppatori spesso dicono "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 un "arretrato tecnico" . Questo arretrato conteneva elementi suggeriti dagli sviluppatori per migliorare il prodotto. Tali 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). Il nostro PO ha deciso che durante la versione dovremmo investire il 10% di ogni sprint (in media) in tali articoli. Prima di ogni sprint, quando l'OP ha deciso in merito al backlog dello sprint in arrivo, si è assicurato che avessimo il 10% degli elementi di backlog di enginerring. Quindi 2 backlog versione -> 1 backlog sprint.
3. Buffer - Quando iniziano a lavorare in SCRUM le persone spesso dimenticano che, in quanto ingegneri del software, lasciamo un mondo di incertezza. Va bene contare 1 giorno di lavoro come 6 ore anziché 8. Supponiamo che tu abbia uno sprint di 15 giorni, ciò significa che hai 30 ore extra che vanno alle riunioni, a cose che hanno richiesto troppo tempo e sì - anche per quei piccoli cose che sono troppo piccole da ricordare ma che fanno parte del nostro lavoro di 2 giorni.
4. Rimanere concentrati - Ultimo ma non meno importante, in SCRUM è importante rimanere concentrati. Decidi quanta parte del tuo sforzo totale, e qual è la priorità, investi in tali compiti e ricorda di investire questo tempo e fatica. Non andare a lavorare su "piccole cose" solo perché sono piccole. Hai un PO per aiutarti a decidere e hai il tuo buon senso.
5. Resta agile - E, alla fine, non dimenticare di provare diversi metodi per affrontare il problema, chiediti se è davvero il modo migliore. Migliora sulla strada.

In bocca al lupo :)

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 schiarirsi le idee, ecc. Gli è stato concesso un tempo di budget (0,5 ore al giorno o 2,5 ore / settimana) in cui potevano fare qualsiasi cosa, entro ragione (con possibilità di essere applicato a qualcosa al lavoro). Per mantenere le cose disciplinate, è stato chiesto loro di documentare le loro attività in modo da ottenere credito per qualsiasi risultato, ecc. Avere un budget specifico per "il barattolo di caramelle" rientra nelle nostre tempistiche e ha impedito alle cose di sfuggire di mano.

A proposito, abbiamo chiamato il nostro "progetto cool" e finì per essere la fonte di molte buone idee e miglioramenti in quella società.

Dovresti tenere le piccole storie nel backlog principale.

Devo affrontare problemi simili a quello che stai descrivendo, anche se non utilizzo Scrum. Vedo che devi affrontare sfide di prioritizzazione ed efficienza .

Sembra che, secondo il tuo "vecchio stile", chiunque fosse implicitamente autorizzato a fare del proprio compito l'attuale "massima priorità" se visitasse l'ufficio di uno sviluppatore. Questo ha alcuni vantaggi. Il richiedente ha la sensazione di ricevere una risposta e sia il richiedente che lo sviluppatore ottengono una "vincita rapida".

L'aspetto negativo è che l'inserimento frequente di queste attività tende a rallentare o far deragliare le attività prioritarie concordate con il proprietario del prodotto. (Nota a margine, spesso tutti sottovalutano il tempo necessario per queste soluzioni "rapide".)

La mia esperienza è che il tentativo di stringere in un'attività a bassa priorità mina i vantaggi della definizione delle priorità. Come sviluppatore, l'assegnazione delle priorità mi conferma che sto lavorando su ciò su cui il proprietario del prodotto vuole che io lavori. Il proprietario del prodotto dovrebbe decidere se desidera intraprendere il lavoro extra e il rischio (per quanto lieve) di piegare in una richiesta "piacevole da avere".

Spesso, quando chiedo alle parti interessate di stabilire le priorità, mi viene chiesto "Puoi limitarci a inserirle?". Il desiderio implicito è che io completi magicamente il nuovo compito senza influenzare l'attuale massima priorità.

Quello che mi succede spesso è che le parti interessate richiedono LargeImportantProject e SmallLessImportantTask. Il dilemma è: SmallLessImportantTask dovrebbe attendere il completamento di LargeImportantProject (o avere 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 della gestione dei progetti in generale) è quello di evitare blocchi per le attività con la massima priorità. Man mano che diventi più efficiente, c'è meno spazio per spremere nel lavoro "bello avere" in più.

L'efficienza può essere spaventosa, ma ho visto i benefici che superano i costi 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 è veramente "piacevole da avere", è probabilmente perfettamente legittimo attendere che la richiesta venga affrontata con priorità aziendali più importanti.

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

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

Come ha detto Avi sopra, "SCRUM" riguarda l'essere agili. È necessario il buon senso. Se il cambiamento è un cambiamento di pochi minuti, non credo che tu abbia bisogno di un backlog per questo.

Se il cambiamento richiede tempo, significa che non è così "innocuo" e dovrebbe essere ben documentato.

Sulla base della tua domanda iniziale e dei successivi chiarimenti, questo è ciò che ho percepito che i tuoi punti di dolore sono

• Requisiti in costante cambiamento
• Incapacità per gli sviluppatori di concentrarsi su altre aree dell'applicazione, ad es. siamo eroi di una parte dell'applicazione ma non vogliamo toccarne un'altra.
• Diversi approcci all'architettura, soluzioni, quadri adottati
• Il processo di raccolta dei requisiti non sembra funzionare

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

- Requisiti in costante cambiamento

Avere un unico arretrato in cui tutto viene inserito e con la corretta definizione delle priorità dovrebbe significare che il team non dovrebbe sopportare il peso dei requisiti che cambiano durante lo sviluppo. Se si tratta di un ambiente molto dinamico, gli sprint più piccoli di 1 o 2 settimane dovrebbero garantire che le priorità cambianti possano ancora essere agevolate in un periodo di tempo relativamente breve.

- Impossibilità per gli sviluppatori di concentrarsi su altre aree dell'applicazione, ad es. siamo eroi di una parte dell'applicazione ma non vogliamo toccarne un'altra.

Un team di scrum che lavora bene insieme e si supporta a vicenda, 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 sia condivisa. Alcune pratiche come la programmazione di coppia possono aiutare le persone a superare la paura di lavorare su codice che non hanno familiarità con l'apprendimento e la condivisione di tali conoscenze. Questo può richiedere alcuni sprint prima che la conoscenza dell'applicazione sia distribuita tra i team e le persone si sentano a proprio agio a lavorare su qualsiasi area dell'applicazione. Inoltre, consentire alle persone di svolgere i compiti di un consiglio, vale a dire fare la propria scelta su ciò che vorrebbero lavorare, può incoraggiarlo.

- Adozione di approcci diversi all'architettura, alle soluzioni e ai quadri

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

- Processo di raccolta dei requisiti

Ancora una volta, se si rispettano rigorosamente le regole, se un requisito non viene specificato e pronto per la squadra per essere in grado di comprendere e stimare ciò che è necessario per soddisfare il requisito, non dovrebbe essere portato nello sprint. Prendi un altro requisito che è una priorità assoluta ed è stato ben definito ... perché allora sai che sarai in grado di soddisfarlo! Anche se potrebbe non risolvere immediatamente il processo di raccolta dei requisiti, imporrà la modifica necessaria per risolvere il processo.

Per rispondere alla tua prima domanda, no, non dovrebbero esserci due arretrati separati. In qualsiasi momento, è nell'interesse di tutti che gli sviluppatori e l'organizzazione stiano lavorando per primi sugli elementi con la massima priorità. Le priorità dovrebbero basarsi principalmente sul valore aziendale, ed è del tutto possibile che molte piccole modifiche e richieste aggiungano valore commerciale. Lascia che il proprietario del prodotto lo decida.

Sono stato uno Scrum Master per oltre 7 anni e ho aiutato con l'introduzione di Scrum in molti team e aziende diversi. Secondo la mia modesta opinione e dalle mie osservazioni, sento che se Scrum viene introdotto per la prima volta nella tua organizzazione, seguilo nel 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, porterà all'erosione di benefici e valori che comporta. Fai le basi, falle davvero bene. Diventa un esperto nel fare le nozioni di base e capire perché sono presenti, quindi cambia il processo per adattarlo meglio e guidare il miglioramento continuo all'interno della tua organizzazione.

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-organizzato che comprende il processo e discute i cambiamenti che potrebbero essere fatti per il processo, al contrario di una squadra che sta solo iniziando a percorrere il percorso di Agile o Scrum. È come provare a correre prima che tu sappia strisciare ...