Come ottenere un buon design quando si usano metodi agili?

Uso una metodologia agile (SCRUM) da circa tre anni e ne vedo alcuni vantaggi, in particolare nel feedback a breve termine a molti livelli (dai clienti che hanno accesso anticipato alle funzionalità implementate, dai tester che possono testare funzionalità come non appena vengono implementati, da altri sviluppatori che possono fornire feedback molto precoci sul nuovo codice tramite revisione, ecc.).

D'altra parte, ho due problemi aperti, il primo dei quali cercherò di spiegare in questa domanda.

Problema: difficoltà a ottenere un buon design

Provo a fare il refactoring non appena il codice diventa confuso, scrivo unit test quanto più possibile (il che aiuta a prevenire i bug in generale e quando refactoring in particolare). D'altra parte, sviluppare alcune funzionalità complesse in piccoli incrementi, con impegni quotidiani e ripensare continuamente il codice quando non è strutturato, non mi consente di produrre un design davvero buono.

L'unico modulo ben progettato che ho potuto produrre di recente ho ottenuto adottando un approccio diverso: ho analizzato il problema per alcuni giorni (in realtà avevo avuto il problema che mi passava per la testa per un paio di mesi prima di iniziare a lavorarci seriamente ), ha abbozzato un disegno piuttosto dettagliato di tutte le classi coinvolte e le loro relazioni per un altro paio di giorni, poi mi ha rinchiuso nel mio ufficio e ha scritto l'intero codice lavorando senza interruzioni per circa tre settimane. Il risultato è stato la cosa migliore che ho prodotto da un po 'di tempo, con pochissimi bug che sono stati piuttosto facili da individuare e correggere e con un design molto chiaro, che da allora non ha richiesto alcuna modifica rilevante.

Quindi fino ad ora ho trovato molto più efficace ottenere un quadro generale di ciò che voglio fare in anticipo rispetto a iniziare a scrivere codice con piccoli incrementi nella speranza che il quadro generale emerga magicamente nel processo. Con il mio massimo sforzo, l'approccio di sviluppo a piccoli incrementi mi ha sempre portato a progettare peggio.

Domanda : qualcuno ha avuto un'esperienza simile? Sto applicando SCRUM nel modo sbagliato o a cosa dovrei prestare attenzione se voglio svilupparmi in piccoli incrementi e finire ancora con un software ben progettato? O dovrei pianificare una storia utente di progettazione prima di iniziare la codifica effettiva? È considerata una buona pratica, almeno per le funzionalità più complesse della media?

MODIFICA - NOTA

Sono consapevole del fatto che un buon design non è qualcosa di assoluto e non ha un valore in sé, ma dipende dal contesto e che si dovrebbe mirare a un design che sia abbastanza buono per il problema in questione.

Ad esempio, non mi interessa (troppo) una buona progettazione se devo implementare un componente semplice che (1) deve essere pronto il prima possibile, (2) verrà utilizzato solo una volta, (3) non è utilizzato da altre parti del sistema (YAGNI).

Mi interessa la buona progettazione quando un componente (1) verrà utilizzato più volte e in diverse versioni di un prodotto, (2) deve essere mantenuto ed esteso nel tempo, (3) ha molti altri componenti a seconda di esso .

D'altra parte, sviluppare alcune funzionalità complesse in piccoli incrementi, con impegni quotidiani e ripensare continuamente il codice quando non è strutturato, non mi consente di produrre un design davvero buono.

Quindi non farlo.

Non tutto si adatta alla bella scatola agile. Spesso un prodotto avrà alcune cose complesse che non possono essere coltivate agli individui e non possono essere completate in alcun modo sano durante uno sprint. Costringerli in quella casella causerà solo problemi. Ma questi dovrebbero essere pochi e rari. Se scopri che molti dei tuoi componenti sono così, il proprietario del tuo prodotto deve lavorare per rompere meglio le cose (con il tuo team). Sto bene facendo quello che hai fatto: prendi la storia, disegnala, poi mettila al più presto con l'aspettativa che ci vorranno alcune settimane.

Nel caso più generale, ci sono 3 cose che ho visto fare per ottenere un buon design in Agile:

• Realmente progettare - Molti posti che ho visto iniziano il loro sprint e iniziano a fare il cow-boy fuori dal codice. Otterrai un cattivo design in questo modo. Agile non cambia il processo di sviluppo del piano - codice - test - rilascio, ma lo accorcia semplicemente a pezzi più granulari. All'inizio dello sprint, siediti secondo necessità e progetta effettivamente la tua soluzione.

• Avere un architetto / lead - Una volta che il progetto è abbastanza grande, finirai con più team di scrum che lavorano su diversi pezzi dell'applicazione. È molto utile avere qualcuno (o più persone a seconda delle dimensioni dell'applicazione) il cui compito principale è sapere cosa stanno facendo tutti i team dal punto di vista del design. Possono rispondere alle domande e guidare i team verso un design più armonioso e arcuato. Avere ogni team di Scrum ha un vantaggio che conosce la maggior parte di ciò che fanno gli altri team che ho visto ed è stato molto efficace.

• Sii un pragmatico - ho trattato questo sopra. Agile è uno strumento e come qualsiasi strumento; non si applica a tutti i problemi. Se non ha senso applicare alcuni componenti, non applicarli lì. Il tuo obiettivo è spedire un buon software; non dimenticarlo.

È molto possibile implementare in piccoli incrementi e finire con un codice gestibile ben strutturato. In teoria, è molto semplice: se ti assicuri che il codice sia ben strutturato dopo ogni modifica, sarà sempre ben strutturato. Il tuo codice sta diventando scarsamente strutturato perché stai continuando ad aggiungere codice quando dovresti effettuare il refactoring.

Indipendentemente da quanto tempo dedichi alla progettazione, alla fine i requisiti cambieranno in modo imprevisto e dovrai scrivere codice che non si adatta al design originale. Quindi dovrai apportare una modifica incrementale. Se hai una buona serie di unit test e sei abile nel refactoring, sarai in grado di mantenere il codice ben strutturato man mano che soddisfi i nuovi requisiti.

"Ben progettato" è soggettivo

Cosa significa "ben progettato" per te? al proprietario del prodotto? al cliente?

È "ben progettato " un obiettivo del proprietario del prodotto? un obiettivo del cliente? o solo tu?

Ciò che consideri "non ben progettato" soddisfa ancora le aspettative dei proprietari dei prodotti e rende felice il cliente? Quindi è piuttosto "ben progettato" .

Abbastanza buono e YAGNI

Nulla nella maggior parte delle metodologie Agili parla di "ben progettato", perché qualsiasi sistema in cui il Product Owner accetta le storie come complete e i clienti credono che soddisfi i loro requisiti è "ben progettato" .

Si prevede che gli sviluppatori siano professionisti e utilizzeranno pragmaticamente le migliori pratiche, i design appropriati e i modi di dire per implementare le funzionalità e le storie.

Se non stai valutando il tempo per fare le cose correttamente che è un problema per gli sviluppatori, se il Product Owner richiede cose in meno tempo che queste possono essere fatte, è loro prerogativa farlo, e la tua responsabilità istruirle sul conseguenze sotto forma di storie di debito tecnico .

MISCHIA

_{La metodologia agile che può essere scritta, non è la metodologia agile. "- Jarrod Roberson}

SCRUM dovrebbe essere un framework di strumenti per gestire l'intero ciclo di vita di un prodotto software. Non dovrebbe essere un insieme rigido di cose, solo un buon punto di partenza e, si spera, di migliorare.

La maggior parte dei negozi in cui ho lavorato hanno quelli che sono chiamati Sprint ZERO, Sprint per i membri senior del team per delineare un'architettura generale o un tema del prodotto.

Le storie più grandi di 20 dicono di solito essere scomposte fino a quando in realtà non sono poche storie di 3-5 punti. Una di queste storie è: "Come squadra dobbiamo incontrarci per discutere di come progetteremo questa funzione, in modo che avremo il minor debito tecnico possibile dato il tempo assegnato".

Generalmente

In generale un sistema "ben progettato" , è abbastanza buono e segue YAGNI.

Agile e SCRUM, in particolare come implementazione di Agile, sono più su come produrre un prodotto nel modo più trasparente possibile per il Proprietario / Sponsor del Prodotto.

Non si tratta di niente di design tecnico / architettura saggio. È più una filosofia su come affrontare la fornitura di software che soddisfi le esigenze e le aspettative dei clienti. Se non c'è ciò che chiamate parti "ben progettate" , questo non è di per sé un difetto, in quanto non è una parte fondamentale della filosofia.

Lavoriamo con Scrum da diversi mesi e voglio condividere la mia esperienza riguardo al tuo problema.

Qualche mese fa mi è stato dato un grosso pezzo da implementare. Avevo tutte le specifiche pronte, quindi ho dovuto implementare nuove funzionalità di conseguenza. Il compito era di circa 5-6 settimane (come ho stimato). Ho trascorso la prima settimana a lavorare solo sul design. Il compito era un po 'complicato: c'era un oggetto principale che, come ho concluso dalle specifiche, aveva 15 stati diversi e l'interfaccia utente doveva avere comportamenti diversi per ogni stato.

Successivamente ho progettato l'intero flusso di lavoro, la struttura e le classi del DB.

Non vedo nessun altro approccio nel mio caso. Se mi immergessi subito nella programmazione, alla fine avrei avuto un grosso disastro, quasi impossibile da mantenere ed estremamente difficile apportare ulteriori modifiche. Ma le modifiche sono arrivate nelle prossime 2 settimane, quindi ho dovuto rielaborare il codice. Ora è stato facile, con il progetto iniziale pensato. Ciò ha permesso di risparmiare tempo, denaro e nervi.

Dopo questa esperienza sono assolutamente sicuro che valga la pena realizzare un design accettabile all'inizio, quindi spero che con qualche miracolo lo avrai alla fine.

La vista posteriore è 20-20. Se hai avuto le informazioni a tua disposizione all'inizio del progetto per capire tutto e poi scrivere il codice tra qualche settimana, ti suggerisco di farlo.

Non stai dando abbastanza credito a tutte le intuizioni acquisite, gli approcci che sono stati provati e falliti / hanno dovuto essere modificati e la maggiore capacità del cliente / degli utenti di fornire credito sufficiente ai requisiti.

Perché qualcuno con una storia di progetti di successo sulle cascate d'acqua dovrebbe passare a una metodologia agile?

Hai sempre bisogno di un quadro più ampio di ciò che l'obiettivo finale dovrebbe essere, e quali funzionalità sono destinate ad essere implementate e quando, prima di iniziare un progetto. Lavorare su storie come compiti atomici richiede problemi. Devi tenere a mente i requisiti futuri il più possibile.