Come gestisco un problema che verrà visualizzato in una successiva iterazione

Se sei veramente agile, allora il tuo team dovrebbe avere piena consapevolezza dei dettagli di implementazione e il tuo PM non dovrebbe avere voce in capitolo.

Da un lato, l'agilità consiste nel fornire rapidamente un valore, piuttosto che aspettare che tutte le funzionalità desiderate siano perfettamente a posto. Questo a volte significa ridurre lo sforzo a breve termine a scapito di ulteriori lavori a lungo termine. Questa è una delle abitudini più difficili da rompere. So che è stato per il nostro team.

D'altro canto, è un mito che essere agili richiede di rinunciare a qualsiasi pianificazione a lungo termine. Va benissimo, anche incoraggiato, pensare alla "fase 3", purché si riconosca che le priorità aziendali possono cambiare per non implementarla mai. Ciò significa che se due settimane di lavoro extra ora potrebbero impedire due settimane di lavoro extra nella fase 3, nessuna domanda lo farai nella fase 3. Se una settimana di lavoro extra impedisce ora due mesi di lavoro nella fase 3, c'è una piccola domanda sul fare adesso

Tra questi estremi, la tua squadra deve usare il loro miglior giudizio, ma mi piacerebbe posticipare il lavoro quando potresti andare in entrambi i modi. Il motivo è che quando arriverai alla fase 3, saprai molto di più di quello che ti serve. Forse avrai comunque bisogno di un grande refactoring per incorporare alcune funzionalità a cui non hai nemmeno pensato oggi, e tutto il tuo lavoro ora è essenzialmente sprecato.

Stai praticando Scrumerfall. Il riferimento a fasi, PM, ecc. Mi porta a credere che il team abbia abbracciato Agile dove sembra adattarsi, contro il cambiare le nozioni e le concezioni precedenti su come funziona il processo.

In entrambi i casi, fai ciò che devi fare per completare l'elemento del backlog. Stai teorizzando che le priorità non cambieranno in N mesi. Questo è uno dei concetti concreti di Agile; fornire valore in modo iterativo con la possibilità di cambiare direzione in un dato momento.

Puoi e dovresti certamente adottare un approccio intelligente alla tua base di codice, mantenerlo modulare, accoppiamento lento, ecc ... per aiutare nello sforzo di ri-factoring ma lo sforzo di ri-factoring è qualcosa che dovrebbe esistere durante tutto il processo . È in corso. È iterativo. Si tratta di migliorare le cose. Non preoccuparti di fare theorizing , guarda l'elemento del backlog e permetti a it di definire fatto.

Non puoi sempre costruire Roma in un giorno, ma puoi sicuramente gettare le basi per il futuro.

Riesco a capire questo sentimento in cui sai che una grande quantità di refactoring dovrà accadere in una iterazione successiva basata sulle storie utente dell'attuale iterazione. È una sensazione dura e mi fa impazzire a volte anche.

Generalmente vorrei fare un quadro più ampio della situazione. Se non è una grande quantità di lavoro extra nello sprint successivo, allora fai assolutamente quello che devi fare per fornire esattamente ciò che è pianificato per l'attuale iterazione. È possibile pianificare di conseguenza per lo sforzo di refactoring in seguito.

Se sarà probabilmente una straordinaria quantità di lavoro più tardi, inizierò a chiedere in giro quanto sia importante questo particolare sprint per gli stakeholder. I clienti e le altre parti interessate a volte non si preoccupano necessariamente di ogni singolo sprint. Che ci crediate o no, la metodologia Agile tende ad essere una ricerca politica in MOLTE organizzazioni che fanno scattare una scadenza artificiale superficiale, ad es. Volendo attirare clienti e buoni talenti con parole come Agile.

Se gli stakeholder non hanno un interesse acquisito nello sprint attuale, allora potrebbe essere possibile convincerli a ridefinire alcune delle storie degli utenti laddove ha più senso. Prego strongmente di estendere gli sprint se possibile. Ciò crea un precedente pericoloso.