Come gestire i grandi cicli di feedback in Agile

1

La nostra metodologia di progetto è migrata di recente da Waterfall Model a Agile e lo sviluppo e il team di QA hanno ricevuto una formazione adeguata su questo. Ora, una delle strategie agili è "Piccoli cicli di feedback" . Ma il nostro proprietario del prodotto sta ancora dando feedback dopo 2-3 sprint. Ciò a sua volta porta a importanti cambiamenti funzionali nell'applicazione ea volte dobbiamo lavorare su un particolare modulo da zero.

C'è un modo per affrontare questo? Come fare una corretta analisi di impatto prima di suggerire importanti cambiamenti funzionali? O con ampi cicli di feedback, è meglio usare solo Waterfall Model?

È necessario addestrare il cliente sulla metodologia Agile tanto quanto è necessario per addestrare lo sviluppo e il team di QA su Agile?

    
posta Senjuti Mahapatra 22.12.2016 - 10:01
fonte

2 risposte

6

Is it required to train the customer about Agile methodology as much as it required to train the development and QA team about Agile?

Risposta semplice: sì. Agile funziona bene solo se tutti gli interessati partecipano. E poiché agile riguarda principalmente communication e che coinvolgono il cliente , non funzionerà se non parteciperanno. Il proprietario del prodotto fa parte del team.

È possibile assegnare un proprietario del prodotto proxy che assuma il ruolo del cliente, se i responsabili delle decisioni sono troppo occupati o si preoccupano troppo di meno per essere coinvolti. Ma lei deve assumersi la responsabilità e dovrebbe capire il cliente e le sue esigenze abbastanza bene da prendere decisioni per loro.

Quindi dovresti prima provare tutto per far capire al cliente il processo e l'importanza del feedback. Quindi coinvolgeteli attivamente. Per i principianti, invitali alle recensioni sprint invece di utilizzare la comunicazione asincrona come la posta elettronica.

    
risposta data 22.12.2016 - 10:38
fonte
3

Il cliente ritiene che funzioni? Come cliente vorrei lavorare su un sistema migliore, quindi non sto pagando per farti apportare correzioni e ripetere cose che avrebbero potuto essere segnalate prima.

Potresti provare a fare i tuoi sprint un po 'più a lungo, a patto che non diventino troppo lunghi. Inoltre, non esiste una legge che dice che uno sprint deve seguire immediatamente il prossimo. Se si termina uno sprint e il client non può incontrarsi per 2 settimane, mettere lo sviluppo in attesa.

Si rendono disponibili o vivono con i ritardi. Altrimenti pagano di più per cose che potrebbero essere state catturate in cicli di feedback più brevi. Finché capiscono e sono disposti a pagare i soldi in più, a un certo punto non è un tuo problema.

    
risposta data 22.12.2016 - 18:35
fonte

Leggi altre domande sui tag