Sviluppo agile: come progettare il codice per un'iterazione / Sprint?

Il problema che descrivi è relativo a YAGNI .

In pura mentalità agile puoi seguire YAGNI e codificare esattamente ciò che la storia attuale degli utenti richiede senza prendere decisioni preventive su ulteriori esigenze del tuo codice. Può davvero finire con il problema che descrivi.

In modo pragmatico puoi esaminare il tuo arretrato e le priorità di altre storie di utenti noti e in qualche modo riflettere ulteriori esigenze nella tua attuale implementazione. Ciò non significa che codifichi le tue storie attuali con le funzionalità richieste per le storie future, ma definirai il progetto dell'attuale implementazione per essere estensibile alle esigenze previste.

Al contrario, YAGNI è ancora in gioco in caso di futuri requisiti sconosciuti. Se il tuo backlog non contiene una storia con priorità elevata che richiede alcuni cambiamenti significativi nella tua attuale implementazione, codifichi semplicemente la tua implementazione corrente nel modo più semplice possibile per soddisfare solo la storia attuale. Il motivo è evitare placcatura in oro del tuo codice = fornire qualcosa che nessuno voleva davvero.

Conclusione: se puoi prevedere cosa succederà dopo (gli elementi nel tuo backlog sono per lo più stabili) puoi aggiungere tali decisioni all'attuale implementazione. Se non puoi prevedere cosa sarà necessario in futuro, segui semplicemente YAGNI.

Dato che sembra esserci un po 'di dibattito su dove si sta dirigendo esattamente la domanda, proverò a dare alcuni suggerimenti:

• Nei modelli di processo non agili in genere si apportano modifiche ai requisiti, che corrispondono grosso modo al proprio scenario. In tal caso, gli effetti sono particolarmente facili da vedere quando consideri il modello a cascata : devi passare attraverso l'intero prodotto e tutte le precedenti fasi del processo per adeguarsi al requisito nuovo o modificato.

• Nello sviluppo Agile, prima di iniziare lo sprint dovresti tenere una riunione per discutere quali user story / epics / features / .. hai intenzione di realizzare nel prossimo sprint insieme a una stima del necessario sforzi . È quest'ultima che ha enfatizzato la parte, in cui tu come membro del team dovresti alzare la barra in modo significativo se vedi che sarà necessario un importante cambiamento di progettazione e un sacco di refactoring.

Tutto diventa più problematico, meno la squadra è competente. Quindi, se ti viene raccontata una storia utente e dici di poterla implementare in 2 settimane, ma solo in un secondo momento ti rendi conto che è necessario riprogettarla e ci vorranno almeno 4 settimane, è troppo tardi. Sarai già a metà strada nello sprint e lo sprint fallirà. A questo punto, l'unica opzione è praticamente annullare lo sprint subito. Riavvia a quel punto con un nuovo incontro e guarda le storie degli utenti che desideri realizzare nella successiva sprint includendo la tua nuova conoscenza dei problemi di progettazione, che porterà a tempi più precisi stime.

Per finire con una dichiarazione più positiva di quella: aiuta enormemente a fare affidamento sui metodi di stima del buon tempo (ad esempio pianificazione poker ) al fine di ridurre il rischio di estinzione delle stime.

Per estendere la risposta per quanto riguarda il tuo commento: la garanzia della qualità del codice rimane sostanzialmente invariata. Assicurati la qualità del codice testando, e lo fai non importa se devi riprogettare o no. Naturalmente, una sedia non può essere gettata in un tavolo. Ma questo significa semplicemente che hai casi di test che cercano di farlo, ma falliscono. Questo è in realtà il caso più semplice (perché l'errore si apre facilmente quando si eseguono i test), in cui il test non corrisponde più al design aggiornato. Non dimenticare che il processo di riprogettazione comporta l'aggiornamento dei test esistenti. Se i requisiti cambiano, i tuoi vecchi test non possono più essere considerati attendibili!

Qui sono alcuni indicatori di articoli specifici sui test in un contesto Agile.

Lo sto gestendo in questo modo *:

1. Crea il tuo codice in piccoli moduli . Se i moduli sono indipendenti, non avrai mai bisogno di modificare il codice esistente. Nuova attività = nuovo modulo.
2. Evita l'intersezione del vecchio codice e del nuovo codice.
3. Sostituisci righe vuote di codice con nuovo codice.
4. (non rifattore)
5. (scrivi solo codice perfetto - non sono necessarie modifiche successive)
6. (aggiungi nuovi moduli il più facilmente possibile. Se impiega più di 1 minuto per aggiungere un nuovo modulo, è rotto)