Scrum / Agile: come pianifichi miglioramenti interni? [chiuso]

Question

Ora ho lavorato su due diversi team che utilizzano l'approccio Agile / Scrum negli ultimi due anni ed entrambi i team erano ansiosi di migliorare il modo in cui si avvicinano allo sviluppo del software. Nel primo team, potremmo facilmente convincere il nostro product owner a ottenere tempo per cose interne come il miglioramento del sistema di build, l'impostazione di migliori test di integrazione, una migliore strategia di rilascio ecc. In questo momento anche l'OP è disposta a darci tempo, ma sta spingendo più indietro, il che è ragionevole in quanto deve anche fare le sue cose.

Comunque la mia domanda ora è, come fanno gli altri team a gestirlo? Crei una storia di miglioramento e la metti sul tavolo durante la pianificazione o tieni un "secchio"? di tempo per cose del genere? Quanto è difficile nella tua esperienza convincere il proprietario del prodotto a trovare il tempo per migliorare? Dopo tutto questo tipo di miglioramenti andranno a beneficio del team, ma non direttamente o immediatamente il proprietario / azienda prodcut.

Answer 1

Ottima domanda. Penso che ci siano diversi gusti di "oggetti d'azione" da retrospettive che meritano approcci diversi.

1) compiti tecnici per affrontare aspetti come il debito tecnico o miglioramenti delle infrastrutture - come " Dovremmo assicurarci di non avere chiamate al database nel livello di visualizzazione della nostra applicazione, perché ci ha fatto perdere tempo in questa iterazione passata ... qualcuno dovrebbe fare una ricerca attraverso il codice per assicurarsi che non lo stiamo facendo altrove. "

2) miglioramenti del processo (ad es. " la gente non arriva in stand-up in tempo ... iniziamo un $ 1 per donazione di beneficenza ogni volta che qualcuno è in ritardo " ;.)

La prima categoria può essere un lavoro significativo o potrebbe essere semplice. L'esempio che ho mostrato è stato piuttosto semplice ... ma potrebbe generare altre attività che devono essere pianificate (ad esempio la rimozione delle chiamate al database nelle 5 posizioni in cui sono state scoperte).

La seconda categoria dovrebbe essere gestita / guidata dal responsabile dell'iterazione, dal project manager, dalla scrum manager, ecc. Io (come Scrum Master o Project Manager) di solito li elenco su un wiki di progetto e ne parlo in retrospettive, controllali spento quando vengono indirizzati e riferire al team sullo stato. Tengo acceso il fuoco.

Penso che l'errore nella prima categoria - compiti tecnici - sia che non definiamo i criteri di accettazione. I tuoi esempi includevano "migliorare il sistema di compilazione, impostare migliori test di integrazione, avere una migliore strategia di rilascio". Questi non sono deterministici e devono essere elencati in termini nitidi (usando picchi se necessario). Pertanto, il miglioramento del sistema di generazione potrebbe iniziare con un'attività tecnica o un picco per valutare le opzioni.

Dobbiamo anche suddividere e stabilire le priorità delle attività tecniche (ad esempio, forse "test di integrazione migliori" potrebbero iniziare con un compito tecnico di definizione dell'attuale copertura di integrazione o valutazione della percentuale di bug che potrebbero essere incolpati di errori di integrazione a costruire il caso per gli investimenti lì.

Dopo aver impostato le priorità, è possibile comunicare il valore degli articoli ad alta priorità e negoziare con il proprietario del prodotto il tempo da dedicare ad essi. Non sono un grande fan dei bucket predefiniti da spendere in qualsiasi cosa ... ma è fondamentale avere una conversazione con il proprietario del prodotto con requisiti precisi, ROI e criteri di accettazione.

Answer 2

I miglioramenti dovrebbero essere parte dello sprint allo stesso modo delle nuove funzionalità. Spetta al team dimostrare al Product Owner che tali miglioramenti sono necessari per lo sprint in arrivo. Ciò potrebbe rallentare la velocità con cui vengono prodotte nuove funzionalità, ma alla fine è utile per il prodotto.

D'altra parte, ho problemi con gli sprint che contengono solo miglioramenti. Ogni sprint dovrebbe produrre output che può essere dimostrato al Product Owner.

Answer 3

Metodi di cristallo ha il concetto di Reflection Workshop come mezzo per ottimizza il tuo processo di sviluppo. I team si incontrano periodicamente (meno frequentemente del ciclo di sviluppo, forse) per discutere dei miglioramenti e dello stato del processo. Vieni con 0-3 cose che abbiamo provato questa volta che ha funzionato e che terremo, 1-3 cose che non funzionano e 1-3 cose da provare la prossima volta. L'idea è quella di avere un miglioramento incrementale sia nel processo che nel prodotto.

Answer 4

L'anno scorso ho lavorato per uno dei primi utenti / consulenti / formatori Agile (xp). Penso che abbia avuto un buon approccio.

Ci siamo incontrati ogni venerdì e abbiamo appena discusso di cosa ha funzionato e cosa no. Li scriveremmo su due grandi pezzi di carta (era davvero nel cavalletto e non nella lavagna perché era più permanente e poteva essere riposizionato più facilmente).

Le cose che hanno funzionato potrebbero essere molto semplici: abbiamo interagito bene come una squadra, l'abbinamento è andato liscio, ecc.

Le cose che non funzionavano erano altrettanto semplici e casuali. Alcune persone potrebbero resistere all'abbattimento o addirittura "Il capo non ci ha portato sulla sua barca come promesso".

Ogni settimana verificheremmo anche di nuovo " non funzionava " e vedere se li abbiamo risolti - In tal caso, sarebbero sempre elencati in queste settimane "ha funzionato" colonna.

Anche se discuteremmo di soluzioni specifiche, solo evidenziare i problemi all'aperto tendeva ad avere un effetto molto positivo. Se sono rimasti su " Non ha funzionato " per 3 o 4 settimane, discuteremmo di soluzioni diverse / migliori e faremo un tentativo più deliberato di implementarle.

Dopo che un articolo ha trascorso una o due settimane in " Ha funzionato bene " colonna, lo lasceremmo poiché era più o meno previsto (a meno che non continuasse a migliorare).

Ha anche reso il venerdì pomeriggio un po 'più interessante poiché è stato un incontro abbastanza divertente a cui tutti potevano partecipare.

Answer 5

Userei un 'picco' per tali cose. Un miglioramento interno / di processo non potrebbe essere una user story ma farebbe un picco perfetto.

Answer 6

Non ho molto da aggiungere qui, tuttavia ritengo che si dovrebbe avere una risorsa dedicata a questi problemi relativi al miglioramento dell'ambiente e le attività non dovrebbero essere incluse nei grafici di burn-down. Se è necessario un hardware aggiuntivo per questo progetto, dovrebbe essere stato aggiunto e preventivato in anticipo. Quindi alla fine questi non dovrebbero influire sull'assegnazione delle ore alla mischia, tuttavia qualsiasi lavoro interessato a seguito di questi problemi dovrebbe essere giustificato.

Answer 7

No, non si deve non creare user story tecniche: teoricamente, e dal momento che generalmente non apportano alcun valore diretto al cliente, hanno pochissime possibilità di essere selezionate in una iterazione. Convincere il Product Owner è un'opzione per alleviare questo, ma c'è un altro strumento che può essere usato qui: slack.

Slack è una piccola parte del tempo di iterazione dedicato a tali attività di miglioramento. Se tutto è andato bene durante l'iterazione, allora sarai in grado di usare quel tempo per quei miglioramenti. D'altra parte, avrai un'altra possibilità di rispettare i tuoi impegni nel caso in cui il team si sia impegnato troppo per l'iterazione (o se un'attività fosse sottovalutata, più difficile del previsto ...)

Un altro vantaggio dell'utilizzo di slack è che ciò ridurrà la variazione della velocità poiché probabilmente si adempiranno i propri impegni più spesso, senza ricorrere agli straordinari.

Fai riferimento a Tom DeMarco Slack: superare il burnout, il lavoro intenso e il mito del totale Efficienza (link Amazon) - ISBN 0767907698.